From bburke at redhat.com  Mon Feb  1 00:24:10 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 1 Feb 2016 00:24:10 -0500
Subject: [keycloak-user] Is it possible to use Keycloak just as a
	library?
In-Reply-To: <CAEBys6KobhZkaWX4Hc2f-EVzCxoxADw+WEMLoXk0ihCLB81wZw@mail.gmail.com>
References: <CAEBys6KobhZkaWX4Hc2f-EVzCxoxADw+WEMLoXk0ihCLB81wZw@mail.gmail.com>
Message-ID: <56AEEBFA.1040805@redhat.com>

We do have a SAML client adapter which can be used as a library...But 
no, sorry, the keycloak IDP is a server.  What do you want to use "as a 
library" which features?

On 1/31/2016 9:57 PM, Renann Prado wrote:
> Hello
>
> At least for now, I would like to use Keycloak as a library so I don't 
> have to configure a "Keycloak server".
> Is it possible?
>
> Renann Prado
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/7e8c614c/attachment.html 

From hr.stoyanov at peruncs.com  Mon Feb  1 01:47:24 2016
From: hr.stoyanov at peruncs.com (Hristo Stoyanov)
Date: Mon, 1 Feb 2016 06:47:24 +0000
Subject: [keycloak-user] KC1.8 failing realm merge/upgrade ?
Message-ID: <CAHiHDeRmDvwT1cY6j5znOVAoiSrwdNVqSGGVoHdmUyR1AJxgZQ@mail.gmail.com>

Hi all,
I ma trying to install KC1.8.Final over a previous KC1.7 installation
backed by Postgres. I use template files to bootstrap my realm:

36 -rw-r--r-- 1 root root 36806 Feb  1 05:50 FinancialApps-realm.json
40 -rw-r--r-- 1 root root 39545 Feb  1 05:50 master-realm.json
 4 -rw-r--r-- 1 root root   709 Feb  1 05:50 master-users-0.json
 4 -rw-r--r-- 1 root root    77 Feb  1 05:50 version.json

and I use the import facility:

            -Dkeycloak.migration.action=import \
            -Dkeycloak.migration.provider=dir \
            -Dkeycloak.migration.dir={{wildfly_home}}/keycloak \
            -Dkeycloak.migration.strategy=IGNORE_EXISTING

Below is the exception I get. I understand that I can wipe out my Postgress
database and have a clean import, but I thought the import was careful
enough to check for duplicate keys???
=================================================================
Caused by: org.keycloak.models.ModelDuplicateException:
javax.persistence.PersistenceException:
org.hibernate.exception.ConstraintViolationException: could not execute
statement
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:40)
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
at com.sun.proxy.$Proxy83.flush(Unknown Source)
at org.keycloak.models.jpa.JpaUserProvider.addUser(JpaUserProvider.java:61)
at
org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.addUser(DefaultCacheUserProvider.java:267)
at
org.keycloak.models.utils.RepresentationToModel.createUser(RepresentationToModel.java:1168)
at
org.keycloak.exportimport.util.ImportUtils.importUsers(ImportUtils.java:191)
at
org.keycloak.exportimport.util.ImportUtils.importUsersFromStream(ImportUtils.java:175)
at
org.keycloak.exportimport.dir.DirImportProvider$4.runExportImportTask(DirImportProvider.java:121)
at
org.keycloak.exportimport.util.ExportImportSessionTask.run(ExportImportSessionTask.java:18)
at
org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:267)
at
org.keycloak.exportimport.dir.DirImportProvider.importRealm(DirImportProvider.java:117)
at
org.keycloak.exportimport.dir.DirImportProvider.importModel(DirImportProvider.java:55)
at
org.keycloak.exportimport.ExportImportManager.runImport(ExportImportManager.java:69)
at
org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:107)
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:150)
... 19 more
Caused by: javax.persistence.PersistenceException:
org.hibernate.exception.ConstraintViolationException: could not execute
statement
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1608)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1303)
at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
... 37 more
Caused by: org.hibernate.exception.ConstraintViolationException: could not
execute statement
at
org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:112)
at
org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)
at
org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
at
org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:95)
at
org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:207)
at
org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:45)
at
org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2886)
at
org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3386)
at
org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:89)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:560)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:434)
at
org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337)
at
org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1282)
at
org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1300)
... 41 more
*Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value
violates unique constraint "uk_ru8tt6t700s9v50bu18ws5ha6"*
*  Detail: Key (realm_id, username)=(master, admin) already exists.*
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2182)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1911)
at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:173)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:645)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:495)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:441)
at sun.reflect.GeneratedMethodAccessor295.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:453)
at com.sun.proxy.$Proxy84.executeUpdate(Unknown Source)
at
org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
at
org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/f261d931/attachment.html 

From mposolda at redhat.com  Mon Feb  1 02:55:11 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 1 Feb 2016 08:55:11 +0100
Subject: [keycloak-user] KC1.8 failing realm merge/upgrade ?
In-Reply-To: <CAHiHDeRmDvwT1cY6j5znOVAoiSrwdNVqSGGVoHdmUyR1AJxgZQ@mail.gmail.com>
References: <CAHiHDeRmDvwT1cY6j5znOVAoiSrwdNVqSGGVoHdmUyR1AJxgZQ@mail.gmail.com>
Message-ID: <56AF0F5F.6070600@redhat.com>

Hi,

could you please create JIRA? Until it's fixed, I suggest to backup your 
DB and instead use strategy OVERWRITE_EXISTING (or just remove strategy 
property as OVERWRITE_EXISTING is the default)

Marek

On 01/02/16 07:47, Hristo Stoyanov wrote:
> Hi all,
> I ma trying to install KC1.8.Final over a previous KC1.7 installation 
> backed by Postgres. I use template files to bootstrap my realm:
>
> 36 -rw-r--r-- 1 root root 36806 Feb  1 05:50 FinancialApps-realm.json
> 40 -rw-r--r-- 1 root root 39545 Feb  1 05:50 master-realm.json
>  4 -rw-r--r-- 1 root root   709 Feb  1 05:50 master-users-0.json
>  4 -rw-r--r-- 1 root root    77 Feb  1 05:50 version.json
>
> and I use the import facility:
>
>             -Dkeycloak.migration.action=import \
>             -Dkeycloak.migration.provider=dir \
> -Dkeycloak.migration.dir={{wildfly_home}}/keycloak \
>             -Dkeycloak.migration.strategy=IGNORE_EXISTING
>
> Below is the exception I get. I understand that I can wipe out my 
> Postgress database and have a clean import, but I thought the import 
> was careful enough to check for duplicate keys???
> =================================================================
> Caused by: org.keycloak.models.ModelDuplicateException: 
> javax.persistence.PersistenceException: 
> org.hibernate.exception.ConstraintViolationException: could not 
> execute statement
> at 
> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:40)
> at 
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
> at com.sun.proxy.$Proxy83.flush(Unknown Source)
> at 
> org.keycloak.models.jpa.JpaUserProvider.addUser(JpaUserProvider.java:61)
> at 
> org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.addUser(DefaultCacheUserProvider.java:267)
> at 
> org.keycloak.models.utils.RepresentationToModel.createUser(RepresentationToModel.java:1168)
> at 
> org.keycloak.exportimport.util.ImportUtils.importUsers(ImportUtils.java:191)
> at 
> org.keycloak.exportimport.util.ImportUtils.importUsersFromStream(ImportUtils.java:175)
> at 
> org.keycloak.exportimport.dir.DirImportProvider$4.runExportImportTask(DirImportProvider.java:121)
> at 
> org.keycloak.exportimport.util.ExportImportSessionTask.run(ExportImportSessionTask.java:18)
> at 
> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:267)
> at 
> org.keycloak.exportimport.dir.DirImportProvider.importRealm(DirImportProvider.java:117)
> at 
> org.keycloak.exportimport.dir.DirImportProvider.importModel(DirImportProvider.java:55)
> at 
> org.keycloak.exportimport.ExportImportManager.runImport(ExportImportManager.java:69)
> at 
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:107)
> 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:150)
> ... 19 more
> Caused by: javax.persistence.PersistenceException: 
> org.hibernate.exception.ConstraintViolationException: could not 
> execute statement
> at 
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692)
> at 
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602)
> at 
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1608)
> at 
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1303)
> at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
> ... 37 more
> Caused by: org.hibernate.exception.ConstraintViolationException: could 
> not execute statement
> at 
> org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:112)
> at 
> org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)
> at 
> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
> at 
> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:95)
> at 
> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:207)
> at 
> org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:45)
> at 
> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2886)
> at 
> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3386)
> at 
> org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:89)
> at 
> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:560)
> at 
> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:434)
> at 
> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337)
> at 
> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1282)
> at 
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1300)
> ... 41 more
> *Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key 
> value violates unique constraint "uk_ru8tt6t700s9v50bu18ws5ha6"*
> *  Detail: Key (realm_id, username)=(master, admin) already exists.*
> at 
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2182)
> at 
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1911)
> at 
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:173)
> at 
> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:645)
> at 
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:495)
> at 
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:441)
> at sun.reflect.GeneratedMethodAccessor295.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:453)
> at com.sun.proxy.$Proxy84.executeUpdate(Unknown Source)
> at 
> org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
> at 
> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
>
>
>
> _______________________________________________
> 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/20160201/213bcdb6/attachment-0001.html 

From mposolda at redhat.com  Mon Feb  1 03:00:46 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 1 Feb 2016 09:00:46 +0100
Subject: [keycloak-user] Social login error message
In-Reply-To: <CAKUZDO70xSn2PTkKqOHqkWqNH2eYNtA6LHSVNxp24zV+1s_pqg@mail.gmail.com>
References: <CAKUZDO70xSn2PTkKqOHqkWqNH2eYNtA6LHSVNxp24zV+1s_pqg@mail.gmail.com>
Message-ID: <56AF10AE.7050006@redhat.com>

I suggest to upgrade to 1.8 where this is fixed. Or you can workaround 
in 1.7 by edit file 
$KEYCLOAK_HOME/modules/system/layers/base/org/keycloak/keycloak-login-freemarker/main/module.xml 
and add the line:

<module name="org.keycloak.keycloak-broker-core"/>

into dependencies section. Same for module 
$KEYCLOAK_HOME/modules/system/layers/base/org/keycloak/keycloak-email-freemarker/main/module.xml

Marek

On 29/01/16 23:49, Martin Min wrote:
> Hello, I am configuring the social login with google, twitter and 
> github. Everything else works fine until this point, namely, after 
> it's authorized, at the "update account information" page, after I 
> fill out the fields on this page, clicked the "submitted" and I 
> received this error message.
>
> What could cause this? I followed the instruction carefully, but not 
> sure what caused this.
>
> Context Path:
> /auth
>
> Servlet Path:
>
> Path Info:
> /realms/myproject/login-actions/first-broker-login
>
> Query String:
> code=Rp6yjxlbY0_IIjk8_-IpyOy_x8m_hC0d8zz4t-hp7vI.9ea99589-bf8d-4a13-930a-c58661dfb925
>
> *Stack Trace*
> java.lang.RuntimeException: request path: 
> /auth/realms/myproject/login-actions/first-broker-login
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:75)
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
>
> Caused by: org.jboss.resteasy.spi.UnhandledException: 
> java.lang.NoClassDefFoundError: 
> org/keycloak/broker/provider/BrokeredIdentityContext
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20160201/7b0239cc/attachment.html 

From mposolda at redhat.com  Mon Feb  1 03:04:39 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 1 Feb 2016 09:04:39 +0100
Subject: [keycloak-user] Google social login in
In-Reply-To: <CAKUZDO5Ljw90XKTPr56z_16yKxvXZ8Fcsggty0fmkKPOsKtKrA@mail.gmail.com>
References: <CAKUZDO5iTFi0oVzaEGFdy24i=coyjo435SpCU93Po9zfTTfXLg@mail.gmail.com>
	<CA+1OW+iv4nRL3dwNSth9432KtRaQ6i8+pbt94dieydwfHnHAbA@mail.gmail.com>
	<CAKUZDO5Ljw90XKTPr56z_16yKxvXZ8Fcsggty0fmkKPOsKtKrA@mail.gmail.com>
Message-ID: <56AF1197.6060601@redhat.com>

By default, keycloak uses H2 database with data stored on filesystem 
inside $KEYCLOAK_HOME/standalone/data directory. You can switch to other 
database by configure datasource in standalone.xml or by switch to Mongo 
model (see our documentation for more details).

So unless you delete $KEYCLOAK_HOME/standalone/data directory, the data 
should be persistent among restarts.

Marek

On 29/01/16 21:57, Martin Min wrote:
> After I restarted my KeyCloak server, all my realm and applications 
> created are gone. Is that because the built-in database H2 doesn't 
> persist the data on disk? How to keep the database after I restart the 
> keycloak server?
>
> Thanks.
>
> On Fri, Jan 29, 2016 at 1:48 AM, Marko Strukelj <mstrukel at redhat.com 
> <mailto:mstrukel at redhat.com>> wrote:
>
>     No, localhost should work fine.
>     It's not Google's servers, but your browser that connects to this url
>     after being redirected from Google. So as long as your browser can see
>     it it should work.
>
>
>
>
> _______________________________________________
> 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/20160201/88483425/attachment.html 

From bystrik.horvath at gmail.com  Mon Feb  1 04:08:41 2016
From: bystrik.horvath at gmail.com (Bystrik Horvath)
Date: Mon, 1 Feb 2016 10:08:41 +0100
Subject: [keycloak-user] KeycloakConfigResolver vs. unprotected resources
Message-ID: <CADjGaaeb25u274-jLg==Z8TS55Svacz+EMeVwY8qRkuPABJ7DQ@mail.gmail.com>

Hello,

I have an application that is part of several realms. That's why I
implemented the KeycloakConfigResolver and it works fine.
I observed that the KeycloakConfigResolver implementation gets called even
when unprotected resources of the application are requested. Is there a
(recommended) way how to avoid it? Or do I do something wrong?

Thank you for the answer.

Best regards,
Bystrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/dab1c726/attachment.html 

From sthorger at redhat.com  Mon Feb  1 05:23:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 11:23:25 +0100
Subject: [keycloak-user] Is there a REST Admin API to initiate the Reset
 Password flow?
In-Reply-To: <CAPj1eSzAba_K03QG_gb3ynFyfeVPnKHBZLaz3X=Qq31FNQGRyw@mail.gmail.com>
References: <CAPj1eSx=RVncaaiGGNT7ohCb0qDyHZ8e0hqAk=GSUdwqv7imLg@mail.gmail.com>
	<CAJgngAdHVPFgFVptNGikngi9cw+fEaGV6WeWigLuEWtpR1m95g@mail.gmail.com>
	<CAOjtoUPYiLLryDvYOH7LLw0W1Cvgkw0hbCAqd5gALSaRX9vs1g@mail.gmail.com>
	<CAPj1eSzAba_K03QG_gb3ynFyfeVPnKHBZLaz3X=Qq31FNQGRyw@mail.gmail.com>
Message-ID: <CAJgngAeW=-Z-P=pyxRWV0OGyXG=2-AH52KZ1ocTdicV9_MUhGg@mail.gmail.com>

On 28 January 2016 at 08:41, Lohitha Chiranjeewa <kalc04 at gmail.com> wrote:

> Thanks Fabricio, will check on how we can proceed with such an
> implementation.
>
> Since there is an already existing registration-email API, I thought it's
> consistent from Keycloak's perspective to expose a reset-password API as
> well...
>

Not sure what you refer to, but there are no APIs for these actions outside
of the admin endpoints.


>
>
> Regards,
> Lohitha.
>
> On Thu, Jan 28, 2016 at 2:31 AM, Fabricio Milone <
> fabricio.milone at shinetech.com> wrote:
>
>> Hi Lohitha,
>>
>> I had the same requirements (Direct grant + forgotten password) and ended
>> up implementing a SPI using some piece of code made by Pedro Igor.
>>
>> An extract of the DEV Mailing list called: "*Add custom REST paths? New
>> SPI?*"
>>
>> *It is part of a working in progress around fine-grained authorization
>>> [1].*
>>> *The new SPI changes [2] specific to Keycloak are located in a specific
>>> branch [3] in my Keycloak fork.*
>>
>>
>>> *I need to discuss these changes with Bill and see what he thinks about
>>> it. Depending on his feedback, I can prepare a PR and send these changes to
>>> upstream.*
>>
>>
>>>
>>> *[1] https://github.com/pedroigor/keycloak-authz
>>> <https://github.com/pedroigor/keycloak-authz>*
>>> *[2]
>>> https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54
>>> <https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54>**[3]
>>> https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified
>>> <https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified>*
>>
>>
>>
>> Not sure if Keycloak will ever adopt those changes as official or
>> something similar though.
>>
>> That's a good starting point.
>>
>> Regards
>>
>> On 27 January 2016 at 21:19, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> There is in the admin endpoints, but nothing that's available to
>>> end-users.
>>>
>>> On 22 January 2016 at 06:45, Lohitha Chiranjeewa <kalc04 at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> There are a few clients of ours who use the Direct Grants API to
>>>> authenticate their users. A requirement has come up to provide the Reset
>>>> Password flow to those clients. From what I've checked and gathered,
>>>> there's no REST API to initiate this flow (sending the Keycloak password
>>>> reset email + resetting the password through the UI); only way to do is
>>>> through the browser.
>>>>
>>>> If it's actually there somewhere, can someone point me to it?
>>>>
>>>>
>>>> Regards,
>>>> Lohitha.
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>>
>> --
>> *Fabricio Milone*
>> Developer
>>
>> *Shine Consulting *
>>
>> 30/600 Bourke Street
>>
>> Melbourne VIC 3000
>>
>> T: 03 8488 9939
>>
>> M: 04 3200 4006
>>
>>
>> www.shinetech.com  *a* passion for excellence
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/42795a4b/attachment-0001.html 

From sthorger at redhat.com  Mon Feb  1 05:32:23 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 11:32:23 +0100
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
Message-ID: <CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>

This could be related to https://issues.jboss.org/browse/KEYCLOAK-2327.

It's already fixed in master, so if you can try it out that would be great.
We should also have a 1.8.1.Final release this week with the fix in as well.

On 30 January 2016 at 05:16, Malmi Samarasinghe <malmi.suh at gmail.com> wrote:

> Hi Bill,
>
> We are using keycloak 1.7.0 and rdbms (mysql)
>
> Regards,
> Malmi Samarasinghe
> On Jan 29, 2016 7:41 PM, "Bill Burke" <bburke at redhat.com> wrote:
>
>> Which version of keycloak?  RDBMS or Mongo?
>>
>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>
>> Hi Everyone,
>>
>> In my application we create retrieve and assign role subsequently and it
>> seems that even for a small load (2-3 threads) with realm cache enabled
>> option, assign realm role call fails due to role not exist error and 404 is
>> returned from keycloak.
>>
>> With the realm cache disabled option the load works fine.
>>
>> Please get back to me if you have any information on any other option we
>> can follow to get this issue sorted or on what action the realm cache will
>> be persisted to DB.
>>
>> Regards,
>> Malmi
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://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/20160201/acc04ae2/attachment.html 

From sthorger at redhat.com  Mon Feb  1 05:35:17 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 11:35:17 +0100
Subject: [keycloak-user] KC1.8 failing realm merge/upgrade ?
In-Reply-To: <56AF0F5F.6070600@redhat.com>
References: <CAHiHDeRmDvwT1cY6j5znOVAoiSrwdNVqSGGVoHdmUyR1AJxgZQ@mail.gmail.com>
	<56AF0F5F.6070600@redhat.com>
Message-ID: <CAJgngAcDJWJn8Xv5ZJ_LG3Bc+sYFwYD9u1xLg=7cjYNTv7zX8w@mail.gmail.com>

The import is really meant for a clean database. Or at least to import
non-existing realms.

Why are you doing an import during upgrade if you are not starting with a
clean database?

On 1 February 2016 at 08:55, Marek Posolda <mposolda at redhat.com> wrote:

> Hi,
>
> could you please create JIRA? Until it's fixed, I suggest to backup your
> DB and instead use strategy OVERWRITE_EXISTING (or just remove strategy
> property as OVERWRITE_EXISTING is the default)
>
> Marek
>
>
> On 01/02/16 07:47, Hristo Stoyanov wrote:
>
> Hi all,
> I ma trying to install KC1.8.Final over a previous KC1.7 installation
> backed by Postgres. I use template files to bootstrap my realm:
>
> 36 -rw-r--r-- 1 root root 36806 Feb  1 05:50 FinancialApps-realm.json
> 40 -rw-r--r-- 1 root root 39545 Feb  1 05:50 master-realm.json
>  4 -rw-r--r-- 1 root root   709 Feb  1 05:50 master-users-0.json
>  4 -rw-r--r-- 1 root root    77 Feb  1 05:50 version.json
>
> and I use the import facility:
>
>             -Dkeycloak.migration.action=import \
>             -Dkeycloak.migration.provider=dir \
>             -Dkeycloak.migration.dir={{wildfly_home}}/keycloak \
>             -Dkeycloak.migration.strategy=IGNORE_EXISTING
>
> Below is the exception I get. I understand that I can wipe out my
> Postgress database and have a clean import, but I thought the import was
> careful enough to check for duplicate keys???
> =================================================================
> Caused by: org.keycloak.models.ModelDuplicateException:
> javax.persistence.PersistenceException:
> org.hibernate.exception.ConstraintViolationException: could not execute
> statement
> at
> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:40)
> at
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
> at com.sun.proxy.$Proxy83.flush(Unknown Source)
> at org.keycloak.models.jpa.JpaUserProvider.addUser(JpaUserProvider.java:61)
> at
> org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.addUser(DefaultCacheUserProvider.java:267)
> at
> org.keycloak.models.utils.RepresentationToModel.createUser(RepresentationToModel.java:1168)
> at
> org.keycloak.exportimport.util.ImportUtils.importUsers(ImportUtils.java:191)
> at
> org.keycloak.exportimport.util.ImportUtils.importUsersFromStream(ImportUtils.java:175)
> at
> org.keycloak.exportimport.dir.DirImportProvider$4.runExportImportTask(DirImportProvider.java:121)
> at
> org.keycloak.exportimport.util.ExportImportSessionTask.run(ExportImportSessionTask.java:18)
> at
> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:267)
> at
> org.keycloak.exportimport.dir.DirImportProvider.importRealm(DirImportProvider.java:117)
> at
> org.keycloak.exportimport.dir.DirImportProvider.importModel(DirImportProvider.java:55)
> at
> org.keycloak.exportimport.ExportImportManager.runImport(ExportImportManager.java:69)
> at
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:107)
> 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:150)
> ... 19 more
> Caused by: javax.persistence.PersistenceException:
> org.hibernate.exception.ConstraintViolationException: could not execute
> statement
> at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692)
> at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602)
> at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1608)
> at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1303)
> at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
> ... 37 more
> Caused by: org.hibernate.exception.ConstraintViolationException: could not
> execute statement
> at
> org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:112)
> at
> org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)
> at
> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
> at
> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:95)
> at
> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:207)
> at
> org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:45)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2886)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3386)
> at
> org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:89)
> at
> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:560)
> at
> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:434)
> at
> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337)
> at
> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1282)
> at
> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1300)
> ... 41 more
> *Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value
> violates unique constraint "uk_ru8tt6t700s9v50bu18ws5ha6"*
> *  Detail: Key (realm_id, username)=(master, admin) already exists.*
> at
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2182)
> at
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1911)
> at
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:173)
> at
> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:645)
> at
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:495)
> at
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:441)
> at sun.reflect.GeneratedMethodAccessor295.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:453)
> at com.sun.proxy.$Proxy84.executeUpdate(Unknown Source)
> at
> org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
> at
> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
>
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160201/d1fe8190/attachment-0001.html 

From prado.renann at gmail.com  Mon Feb  1 06:02:44 2016
From: prado.renann at gmail.com (Renann Prado)
Date: Mon, 1 Feb 2016 09:02:44 -0200
Subject: [keycloak-user] Is it possible to use Keycloak just as a
	library?
In-Reply-To: <56AEEBFA.1040805@redhat.com>
References: <CAEBys6KobhZkaWX4Hc2f-EVzCxoxADw+WEMLoXk0ihCLB81wZw@mail.gmail.com>
	<56AEEBFA.1040805@redhat.com>
Message-ID: <CAEBys6JZn+3y5yUnNTVausuBMViasT-M53Dbcv0VHzDUuf81YA@mail.gmail.com>

I'd like  to use oauth 2.
On Feb 1, 2016 03:25, "Bill Burke" <bburke at redhat.com> wrote:

> We do have a SAML client adapter which can be used as a library...But no,
> sorry, the keycloak IDP is a server.  What do you want to use "as a
> library" which features?
>
> On 1/31/2016 9:57 PM, Renann Prado wrote:
>
> Hello
>
> At least for now, I would like to use Keycloak as a library so I don't
> have to configure a "Keycloak server".
> Is it possible?
>
> Renann Prado
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160201/34295ea0/attachment.html 

From prabhalar at yahoo.com  Mon Feb  1 07:37:10 2016
From: prabhalar at yahoo.com (Raghuram Prabhala)
Date: Mon, 1 Feb 2016 12:37:10 +0000 (UTC)
Subject: [keycloak-user] Realm Certificate from commercial Vendors
In-Reply-To: <56A8D18B.7040306@redhat.com>
References: <56A8D18B.7040306@redhat.com>
Message-ID: <888753579.2668620.1454330230993.JavaMail.yahoo@mail.yahoo.com>

Thanks Bill and Stian. Will look at the admin endpoints to handle the upload of certificates. Really surprised that this feature wasn't requested yet - created a jira kc2422
      From: Bill Burke <bburke at redhat.com>
 To: keycloak-user at lists.jboss.org 
 Sent: Wednesday, January 27, 2016 9:17 AM
 Subject: Re: [keycloak-user] Realm Certificate from commercial Vendors
   
 You can upload client certs for saml clients, but I think we have a attribute size problem for large cert chains.
 
 On 1/27/2016 5:17 AM, Stian Thorgersen wrote:
  
 We don't support uploading the realm keys through the admin console at the moment. However, you should be able to use the admin endpoints to manually set it. Should be relatively easy to add though, so you can create a JIRA to request it, but you're actually the first to request it.
 
  With regards to clients we don't have an elegant way to deal with this. What we have is if the public key is not specified in the client config it will download it from Keycloak at startup, so if you restart your clients after creating new keys it should work. Ideally Keycloak should send a message to the clients to notify them that the keys have changed so they can re-fetch from Keycloak, but that hasn't been implemented yet. Again, feel free to request that.  
 On 25 January 2016 at 11:50, Raghuram Prabhala <prabhalar at yahoo.com> wrote:
 
   Dev team - any comments on the commercial certificates instead of the ones created by Keycloak? 
  Raghu 
             From: Raghuram Prabhala <prabhalar at yahoo.com>
 To: Keycloak-user <keycloak-user at lists.jboss.org> 
 Sent: Thursday, January 21, 2016 2:23 PM
 Subject: Realm Certificate from commercial Vendors
    
    
  I have a question about the Certificate/private key which is generated today by Keycloak. But  rather than use that certificate ,is there any way we can use a commercial Certificate from Vendors like Verisign? When that certificate expires, how do we generate/upload a new certificate (lifecycle) and handle the switch over to a new certificate with minimal impact to any of the  client who will have to download the new certificate and use it when KC starts using the new one? 
  
     
 
       
 _______________________________________________
 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/20160201/a2f641ac/attachment.html 

From Edgar at info.nl  Mon Feb  1 07:46:55 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Mon, 1 Feb 2016 12:46:55 +0000
Subject: [keycloak-user] Back to application link is not shown on the
 success screen after a reset password action
Message-ID: <F08473E5-C026-482F-BACA-1278BE697679@info.nl>

Hi,

Considering the following scenario:
1/ Admin performs a ?Reset Action? on the user from the admin console (Manage - Users - Credentials). In our case an ?Update password? action and send the ?Reset Actions Email?.
2/ User receives the reset action email with a link back to Keycloak.
3/ User follows the link, sets his/her password.
4/ User is now shown a success screen stating "Your account has been updated.? only. There is no link to the application or anything. The user is left on his/her own.

This happens because in AuthenticationManager#nextActionAfterAuthentication the ?skipLink? attribute is set to true. This results in the info.ftl template not showing the ?back to application? link.

I think in this case the link should be shown however. Otherwise the user has no idea where to go to next. In fact I think the ?back to application? link should nearly always be shown. So for now we have simply removed the {{<#if skipLink??>}} check in the info.ftl in our custom email theme. I do wonder why this ?skipLink? functionality was built in the first place? Does it not make sense to remove it altogether maybe?

cheers



From sthorger at redhat.com  Mon Feb  1 08:58:57 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 14:58:57 +0100
Subject: [keycloak-user] Back to application link is not shown on the
 success screen after a reset password action
In-Reply-To: <F08473E5-C026-482F-BACA-1278BE697679@info.nl>
References: <F08473E5-C026-482F-BACA-1278BE697679@info.nl>
Message-ID: <CAJgngAdgtv6TjVPLO_YV2wkov2epbF3NaCZSkZGQenL55kYaCQ@mail.gmail.com>

If you initiate the action through the admin console there's no application
to go back to. Unless we add an option in the admin console to specify the
client that is.

On 1 February 2016 at 13:46, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:

> Hi,
>
> Considering the following scenario:
> 1/ Admin performs a ?Reset Action? on the user from the admin console
> (Manage - Users - Credentials). In our case an ?Update password? action and
> send the ?Reset Actions Email?.
> 2/ User receives the reset action email with a link back to Keycloak.
> 3/ User follows the link, sets his/her password.
> 4/ User is now shown a success screen stating "Your account has been
> updated.? only. There is no link to the application or anything. The user
> is left on his/her own.
>
> This happens because in
> AuthenticationManager#nextActionAfterAuthentication the ?skipLink?
> attribute is set to true. This results in the info.ftl template not showing
> the ?back to application? link.
>
> I think in this case the link should be shown however. Otherwise the user
> has no idea where to go to next. In fact I think the ?back to application?
> link should nearly always be shown. So for now we have simply removed the
> {{<#if skipLink??>}} check in the info.ftl in our custom email theme. I do
> wonder why this ?skipLink? functionality was built in the first place? Does
> it not make sense to remove it altogether maybe?
>
> cheers
>
>
> _______________________________________________
> 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/20160201/55272c9a/attachment-0001.html 

From bburke at redhat.com  Mon Feb  1 09:26:16 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 1 Feb 2016 09:26:16 -0500
Subject: [keycloak-user] KeycloakConfigResolver vs. unprotected resources
In-Reply-To: <CADjGaaeb25u274-jLg==Z8TS55Svacz+EMeVwY8qRkuPABJ7DQ@mail.gmail.com>
References: <CADjGaaeb25u274-jLg==Z8TS55Svacz+EMeVwY8qRkuPABJ7DQ@mail.gmail.com>
Message-ID: <56AF6B08.90103@redhat.com>

Depends on the adapter.  Some/most platforms, the authenticator gets 
executed irregardless.

On 2/1/2016 4:08 AM, Bystrik Horvath wrote:
> Hello,
>
> I have an application that is part of several realms. That's why I 
> implemented the KeycloakConfigResolver and it works fine.
> I observed that the KeycloakConfigResolver implementation gets called 
> even when unprotected resources of the application are requested. Is 
> there a (recommended) way how to avoid it? Or do I do something wrong?
>
> Thank you for the answer.
>
> Best regards,
> Bystrik
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/e457b41a/attachment.html 

From Edgar at info.nl  Mon Feb  1 10:01:22 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Mon, 1 Feb 2016 15:01:22 +0000
Subject: [keycloak-user] Back to application link is not shown on the
 success screen after a reset password action
In-Reply-To: <CAJgngAdgtv6TjVPLO_YV2wkov2epbF3NaCZSkZGQenL55kYaCQ@mail.gmail.com>
References: <F08473E5-C026-482F-BACA-1278BE697679@info.nl>
	<CAJgngAdgtv6TjVPLO_YV2wkov2epbF3NaCZSkZGQenL55kYaCQ@mail.gmail.com>
Message-ID: <19E1475B-2D35-4DDF-9B77-B49D7BD7BAFA@info.nl>

Ah yes, clear. Adding the option to specify the client would be nice indeed. :-) For now we will simply ?hard code? the link into our theme since we only use a single client in this context at this stage. I do realise that you really should not make the theme client-specific.


On 01 Feb 2016, at 14:58, Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>> wrote:

If you initiate the action through the admin console there's no application to go back to. Unless we add an option in the admin console to specify the client that is.

On 1 February 2016 at 13:46, Edgar Vonk - Info.nl<http://info.nl> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:
Hi,

Considering the following scenario:
1/ Admin performs a ?Reset Action? on the user from the admin console (Manage - Users - Credentials). In our case an ?Update password? action and send the ?Reset Actions Email?.
2/ User receives the reset action email with a link back to Keycloak.
3/ User follows the link, sets his/her password.
4/ User is now shown a success screen stating "Your account has been updated.? only. There is no link to the application or anything. The user is left on his/her own.

This happens because in AuthenticationManager#nextActionAfterAuthentication the ?skipLink? attribute is set to true. This results in the info.ftl template not showing the ?back to application? link.

I think in this case the link should be shown however. Otherwise the user has no idea where to go to next. In fact I think the ?back to application? link should nearly always be shown. So for now we have simply removed the {{<#if skipLink??>}} check in the info.ftl in our custom email theme. I do wonder why this ?skipLink? functionality was built in the first place? Does it not make sense to remove it altogether maybe?

cheers


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/4f7c1048/attachment.html 

From bystrik.horvath at gmail.com  Mon Feb  1 10:06:45 2016
From: bystrik.horvath at gmail.com (Bystrik Horvath)
Date: Mon, 1 Feb 2016 16:06:45 +0100
Subject: [keycloak-user] KeycloakConfigResolver vs. unprotected resources
In-Reply-To: <56AF6B08.90103@redhat.com>
References: <CADjGaaeb25u274-jLg==Z8TS55Svacz+EMeVwY8qRkuPABJ7DQ@mail.gmail.com>
	<56AF6B08.90103@redhat.com>
Message-ID: <CADjGaafDcicR+0NHfKhtdBfbyThndk8SdH8po3TNeOCxEUGBAg@mail.gmail.com>

Hi Bill,
thank you for response. I use Adapter deployed in Keycloak 1.7.0. So I need
then somehow propagate the list of unprotected (or protected) resources to
the KeycloakConfigResolver implementation by my own and return from
resolve(...) method when unprotected URIs is accessed.

Best regards,
Bystrik

On Mon, Feb 1, 2016 at 3:26 PM, Bill Burke <bburke at redhat.com> wrote:

> Depends on the adapter.  Some/most platforms, the authenticator gets
> executed irregardless.
>
> On 2/1/2016 4:08 AM, Bystrik Horvath wrote:
>
> Hello,
>
> I have an application that is part of several realms. That's why I
> implemented the KeycloakConfigResolver and it works fine.
> I observed that the KeycloakConfigResolver implementation gets called even
> when unprotected resources of the application are requested. Is there a
> (recommended) way how to avoid it? Or do I do something wrong?
>
> Thank you for the answer.
>
> Best regards,
> Bystrik
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160201/ac592cbb/attachment.html 

From darkness.renann at gmail.com  Mon Feb  1 10:07:53 2016
From: darkness.renann at gmail.com (Renann Prado)
Date: Mon, 1 Feb 2016 13:07:53 -0200
Subject: [keycloak-user] Is it possible to use Keycloak just as a
	library?
In-Reply-To: <CAEBys6JZn+3y5yUnNTVausuBMViasT-M53Dbcv0VHzDUuf81YA@mail.gmail.com>
References: <CAEBys6KobhZkaWX4Hc2f-EVzCxoxADw+WEMLoXk0ihCLB81wZw@mail.gmail.com>
	<56AEEBFA.1040805@redhat.com>
	<CAEBys6JZn+3y5yUnNTVausuBMViasT-M53Dbcv0VHzDUuf81YA@mail.gmail.com>
Message-ID: <CAEBys6J5+L=EP0CDt=caoEbidjMit2mKfjNcG2isV9jvfKmCJA@mail.gmail.com>

Basically I have an application that I'll deploy in Wildfly, but I'd like
to use OAuth2, just like it was with Resteasy Skeleton Key (or something
like that).

Renann Prado

On Mon, Feb 1, 2016 at 9:02 AM, Renann Prado <prado.renann at gmail.com> wrote:

> I'd like  to use oauth 2.
> On Feb 1, 2016 03:25, "Bill Burke" <bburke at redhat.com> wrote:
>
>> We do have a SAML client adapter which can be used as a library...But no,
>> sorry, the keycloak IDP is a server.  What do you want to use "as a
>> library" which features?
>>
>> On 1/31/2016 9:57 PM, Renann Prado wrote:
>>
>> Hello
>>
>> At least for now, I would like to use Keycloak as a library so I don't
>> have to configure a "Keycloak server".
>> Is it possible?
>>
>> Renann Prado
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://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/20160201/9ab48944/attachment-0001.html 

From bburke at redhat.com  Mon Feb  1 10:17:13 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 1 Feb 2016 10:17:13 -0500
Subject: [keycloak-user] Is it possible to use Keycloak just as a
	library?
In-Reply-To: <CAEBys6J5+L=EP0CDt=caoEbidjMit2mKfjNcG2isV9jvfKmCJA@mail.gmail.com>
References: <CAEBys6KobhZkaWX4Hc2f-EVzCxoxADw+WEMLoXk0ihCLB81wZw@mail.gmail.com>
	<56AEEBFA.1040805@redhat.com>
	<CAEBys6JZn+3y5yUnNTVausuBMViasT-M53Dbcv0VHzDUuf81YA@mail.gmail.com>
	<CAEBys6J5+L=EP0CDt=caoEbidjMit2mKfjNcG2isV9jvfKmCJA@mail.gmail.com>
Message-ID: <56AF76F9.2060702@redhat.com>

We don't have that option in Keycloak.  You can install the server 
overlay on an existing app server and run keycloak and your app in the 
same JVM.  That's it.

On 2/1/2016 10:07 AM, Renann Prado wrote:
> Basically I have an application that I'll deploy in Wildfly, but I'd 
> like to use OAuth2, just like it was with Resteasy Skeleton Key (or 
> something like that).
>
> Renann Prado
>
> On Mon, Feb 1, 2016 at 9:02 AM, Renann Prado <prado.renann at gmail.com 
> <mailto:prado.renann at gmail.com>> wrote:
>
>     I'd like  to use oauth 2.
>
>     On Feb 1, 2016 03:25, "Bill Burke" <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>
>         We do have a SAML client adapter which can be used as a
>         library...But no, sorry, the keycloak IDP is a server.  What
>         do you want to use "as a library" which features?
>
>         On 1/31/2016 9:57 PM, Renann Prado wrote:
>>         Hello
>>
>>         At least for now, I would like to use Keycloak as a library
>>         so I don't have to configure a "Keycloak server".
>>         Is it possible?
>>
>>         Renann Prado
>>
>>
>>         _______________________________________________
>>         keycloak-user mailing list
>>         keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>         -- 
>         Bill Burke
>         JBoss, a division of Red Hat
>         http://bill.burkecentral.com
>
>
>         _______________________________________________
>         keycloak-user mailing list
>         keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/6b95c058/attachment.html 

From prado.renann at gmail.com  Mon Feb  1 10:18:07 2016
From: prado.renann at gmail.com (Renann Prado)
Date: Mon, 1 Feb 2016 13:18:07 -0200
Subject: [keycloak-user] Is it possible to use Keycloak just as a
	library?
In-Reply-To: <56AF76F9.2060702@redhat.com>
References: <CAEBys6KobhZkaWX4Hc2f-EVzCxoxADw+WEMLoXk0ihCLB81wZw@mail.gmail.com>
	<56AEEBFA.1040805@redhat.com>
	<CAEBys6JZn+3y5yUnNTVausuBMViasT-M53Dbcv0VHzDUuf81YA@mail.gmail.com>
	<CAEBys6J5+L=EP0CDt=caoEbidjMit2mKfjNcG2isV9jvfKmCJA@mail.gmail.com>
	<56AF76F9.2060702@redhat.com>
Message-ID: <CAEBys6KYe7Xkh0fQTYC0w1Qw4qxEFvV1=C9xMJG73puzXaTUwA@mail.gmail.com>

Ok. Thanks!
On Feb 1, 2016 13:17, "Bill Burke" <bburke at redhat.com> wrote:

> We don't have that option in Keycloak.  You can install the server overlay
> on an existing app server and run keycloak and your app in the same JVM.
> That's it.
>
> On 2/1/2016 10:07 AM, Renann Prado wrote:
>
> Basically I have an application that I'll deploy in Wildfly, but I'd like
> to use OAuth2, just like it was with Resteasy Skeleton Key (or something
> like that).
>
> Renann Prado
>
> On Mon, Feb 1, 2016 at 9:02 AM, Renann Prado <prado.renann at gmail.com>
> wrote:
>
>> I'd like  to use oauth 2.
>> On Feb 1, 2016 03:25, "Bill Burke" <bburke at redhat.com> wrote:
>>
>>> We do have a SAML client adapter which can be used as a library...But
>>> no, sorry, the keycloak IDP is a server.  What do you want to use "as a
>>> library" which features?
>>>
>>> On 1/31/2016 9:57 PM, Renann Prado wrote:
>>>
>>> Hello
>>>
>>> At least for now, I would like to use Keycloak as a library so I don't
>>> have to configure a "Keycloak server".
>>> Is it possible?
>>>
>>> Renann Prado
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://bill.burkecentral.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 Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/6fbcbc08/attachment.html 

From pblair at clearme.com  Mon Feb  1 11:15:41 2016
From: pblair at clearme.com (Paul Blair)
Date: Mon, 1 Feb 2016 16:15:41 +0000
Subject: [keycloak-user] keycloak-server.json settings in 1.8.0.Final
Message-ID: <D2D4EEDC.1163F%pblair@clearme.com>

I'm upgrading from 1.7.0.Final to 1.8.0.Final and when comparing my keycloak-server.json settings I see the following are not there in the newer version:

    "userSessions": {
        "provider" : "infinispan"
    },

    "realmCache": {
        "provider": "infinispan"
    },

    "userCache": {
        "provider": "infinispan"
    },

These may be configurations I added in 1.7.0, but I can't find a reference to them in the 1.8.0.Final reference guide. Are they now obsolete?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/23a68d11/attachment.html 

From pblair at clearme.com  Mon Feb  1 11:19:01 2016
From: pblair at clearme.com (Paul Blair)
Date: Mon, 1 Feb 2016 16:19:01 +0000
Subject: [keycloak-user] add-user-keycloak.sh in 1.8.0.Final
Message-ID: <D2D4EFA0.11646%pblair@clearme.com>

I'm noticing the 1.8.0.Final overlay contains a script named add-user-keycloak.sh but the reference guide only mentions add-user.sh. Should this script be used instead of add-user.sh?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/64ea3ee1/attachment.html 

From adrianmatei at gmail.com  Mon Feb  1 11:25:34 2016
From: adrianmatei at gmail.com (Adrian Matei)
Date: Mon, 1 Feb 2016 17:25:34 +0100
Subject: [keycloak-user] password forgotten - override UpdatePasswd required
	action (v 1.7.0)
Message-ID: <CAG=THF1+TpQvyi3-bvwmwHTawLYBVpsci-10WVOzKTQ6ZXJ0Tg@mail.gmail.com>

Hi guys,

in the UpdatePassword class we need to modify the string values that come
from formData
so that there are not "password-new" but "passwordNew" (JS conform as we've
build the GUI with AngularJS on top of Freemarker actions):
https://github.com/keycloak/keycloak/blob/de472dbd43dd2767afb3436835f77924a78e9f82/services/src/main/java/org/keycloak/authentication/requiredactions/UpdatePassword.java#L67


We've created our own CustomUpdatePassword (similar with the class above
except the two lines and own id -UPDATE_PASSWORD_CUSTOM) and tried to hook
it in our own custom ResetPassword class:
    @Override
    public void authenticate(AuthenticationFlowContext context) {
        if (context.getExecution().isRequired() ||
                (context.getExecution().isOptional() &&
                        configuredFor(context))) {

context.getClientSession().addRequiredAction(CustomUpdatePassword.UPDATE_PASSWORD_CUSTOM);
        }
        context.success();
    }

The custom classes are registered in META-INF services and everything, and
we can add the custom reset password execution in the Reset Credentials
workflow...

The result is a NPE in AuthenticationManager by trying to get the
providerId from the model
RequiredActionProviderModel model =
realm.getRequiredActionProviderByAlias(action);
RequiredActionFactory factory =
(RequiredActionFactory)session.getKeycloakSessionFactory().getProviderFactory(RequiredActionProvider.class,
model.getProviderId());

I am tired and cannot look through anymore, so your advice is more than
welcomed...

Thanks,
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/6e306a09/attachment-0001.html 

From RLewis at carbonite.com  Mon Feb  1 11:27:11 2016
From: RLewis at carbonite.com (Reed Lewis)
Date: Mon, 1 Feb 2016 16:27:11 +0000
Subject: [keycloak-user] Key cloak Direct Access Grants.   How?
Message-ID: <0E8BAB17-3699-45CB-8610-4A4DB73D82D3@carbonite.com>

I have Keycloak working very well now where it can validate users in its own database, against a legacy database in our company, and from Google and Microsoft.   Right now I have been testing with this module for Apache:

https://github.com/pingidentity/mod_auth_openidc

And it works as it should.   I can go to a webpage on my webserver, and the complete flow works well.  The user is redirected to the login page, then it returns, and my webserver requests a token as it should.  :)

What I plan on doing though is securing a mobile App.   I cannot find a raw HTTP(s) example of how to make a direct access grant where keycloak well ask the user for credentials, and directly return an jwt?   Is this possible, or should I use the two step method (keyclock with redirect => to URL in APP => makes request with code to get the tokens?

Also, does anyone have good standalone python, node.js or even C code to validate a token?  I see there are libraries, but I would like to use just openssl if possible.

Thank you,

Reed Lewis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/99408f1b/attachment.html 

From bburke at redhat.com  Mon Feb  1 11:46:13 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 1 Feb 2016 11:46:13 -0500
Subject: [keycloak-user] Key cloak Direct Access Grants. How?
In-Reply-To: <0E8BAB17-3699-45CB-8610-4A4DB73D82D3@carbonite.com>
References: <0E8BAB17-3699-45CB-8610-4A4DB73D82D3@carbonite.com>
Message-ID: <56AF8BD5.7050703@redhat.com>

Take a look at the admin-access-app example.

So, mod-auth-openidc works with Keycloak?  Would you be interested in 
contributing a ClientInstaller that generates config for it? Similar to 
the mod-auth-mellon one?

https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/saml/installation/ModAuthMellonClientInstallation.java

Here's one that generates keycloak client adapter config for OIDC too:

https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/installation/KeycloakOIDCClientInstallation.java


On 2/1/2016 11:27 AM, Reed Lewis wrote:
> I have Keycloak working very well now where it can validate users in 
> its own database, against a legacy database in our company, and from 
> Google and Microsoft.   Right now I have been testing with this module 
> for Apache:
>
> https://github.com/pingidentity/mod_auth_openidc
>
> And it works as it should.   I can go to a webpage on my webserver, 
> and the complete flow works well.  The user is redirected to the login 
> page, then it returns, and my webserver requests a token as it should.  :)
>
> What I plan on doing though is securing a mobile App.   I cannot find 
> a raw HTTP(s) example of how to make a direct access grant where 
> keycloak well ask the user for credentials, and directly return an 
> jwt?   Is this possible, or should I use the two step method (keyclock 
> with redirect => to URL in APP => makes request with code to get the 
> tokens?
>
> Also, does anyone have good standalone python, node.js or even C code 
> to validate a token?  I see there are libraries, but I would like to 
> use just openssl if possible.
>
> Thank you,
>
> Reed Lewis
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/1096cb4b/attachment.html 

From kalc04 at gmail.com  Mon Feb  1 13:00:28 2016
From: kalc04 at gmail.com (Lohitha Chiranjeewa)
Date: Mon, 1 Feb 2016 23:30:28 +0530
Subject: [keycloak-user] Is there a REST Admin API to initiate the Reset
 Password flow?
In-Reply-To: <CAJgngAeW=-Z-P=pyxRWV0OGyXG=2-AH52KZ1ocTdicV9_MUhGg@mail.gmail.com>
References: <CAPj1eSx=RVncaaiGGNT7ohCb0qDyHZ8e0hqAk=GSUdwqv7imLg@mail.gmail.com>
	<CAJgngAdHVPFgFVptNGikngi9cw+fEaGV6WeWigLuEWtpR1m95g@mail.gmail.com>
	<CAOjtoUPYiLLryDvYOH7LLw0W1Cvgkw0hbCAqd5gALSaRX9vs1g@mail.gmail.com>
	<CAPj1eSzAba_K03QG_gb3ynFyfeVPnKHBZLaz3X=Qq31FNQGRyw@mail.gmail.com>
	<CAJgngAeW=-Z-P=pyxRWV0OGyXG=2-AH52KZ1ocTdicV9_MUhGg@mail.gmail.com>
Message-ID: <CAPj1eSwLt5qGv3hOJr7WZy37YeCxsjT3h8_Pu5-t2Mpx7BHvaA@mail.gmail.com>

Hi Stian,

I was referring to a potential API endpoint which actually sends out the
password reset email (there's a similar API which sends out the
registration email), not the existing one which just resets the password.


Regards,
Lohitha.

On Mon, Feb 1, 2016 at 3:53 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

>
>
> On 28 January 2016 at 08:41, Lohitha Chiranjeewa <kalc04 at gmail.com> wrote:
>
>> Thanks Fabricio, will check on how we can proceed with such an
>> implementation.
>>
>> Since there is an already existing registration-email API, I thought it's
>> consistent from Keycloak's perspective to expose a reset-password API as
>> well...
>>
>
> Not sure what you refer to, but there are no APIs for these actions
> outside of the admin endpoints.
>
>
>>
>>
>> Regards,
>> Lohitha.
>>
>> On Thu, Jan 28, 2016 at 2:31 AM, Fabricio Milone <
>> fabricio.milone at shinetech.com> wrote:
>>
>>> Hi Lohitha,
>>>
>>> I had the same requirements (Direct grant + forgotten password) and
>>> ended up implementing a SPI using some piece of code made by Pedro Igor.
>>>
>>> An extract of the DEV Mailing list called: "*Add custom REST paths? New
>>> SPI?*"
>>>
>>> *It is part of a working in progress around fine-grained authorization
>>>> [1].*
>>>> *The new SPI changes [2] specific to Keycloak are located in a specific
>>>> branch [3] in my Keycloak fork.*
>>>
>>>
>>>> *I need to discuss these changes with Bill and see what he thinks about
>>>> it. Depending on his feedback, I can prepare a PR and send these changes to
>>>> upstream.*
>>>
>>>
>>>>
>>>> *[1] https://github.com/pedroigor/keycloak-authz
>>>> <https://github.com/pedroigor/keycloak-authz>*
>>>> *[2]
>>>> https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54
>>>> <https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54>**[3]
>>>> https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified
>>>> <https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified>*
>>>
>>>
>>>
>>> Not sure if Keycloak will ever adopt those changes as official or
>>> something similar though.
>>>
>>> That's a good starting point.
>>>
>>> Regards
>>>
>>> On 27 January 2016 at 21:19, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> There is in the admin endpoints, but nothing that's available to
>>>> end-users.
>>>>
>>>> On 22 January 2016 at 06:45, Lohitha Chiranjeewa <kalc04 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> There are a few clients of ours who use the Direct Grants API to
>>>>> authenticate their users. A requirement has come up to provide the Reset
>>>>> Password flow to those clients. From what I've checked and gathered,
>>>>> there's no REST API to initiate this flow (sending the Keycloak password
>>>>> reset email + resetting the password through the UI); only way to do is
>>>>> through the browser.
>>>>>
>>>>> If it's actually there somewhere, can someone point me to it?
>>>>>
>>>>>
>>>>> Regards,
>>>>> Lohitha.
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> *Fabricio Milone*
>>> Developer
>>>
>>> *Shine Consulting *
>>>
>>> 30/600 Bourke Street
>>>
>>> Melbourne VIC 3000
>>>
>>> T: 03 8488 9939
>>>
>>> M: 04 3200 4006
>>>
>>>
>>> www.shinetech.com  *a* passion for excellence
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/7ec0844f/attachment-0001.html 

From hr.stoyanov at peruncs.com  Mon Feb  1 15:34:54 2016
From: hr.stoyanov at peruncs.com (Hristo Stoyanov)
Date: Mon, 1 Feb 2016 20:34:54 +0000
Subject: [keycloak-user] KC1.8 failing realm merge/upgrade ?
In-Reply-To: <CAJgngAcDJWJn8Xv5ZJ_LG3Bc+sYFwYD9u1xLg=7cjYNTv7zX8w@mail.gmail.com>
References: <CAHiHDeRmDvwT1cY6j5znOVAoiSrwdNVqSGGVoHdmUyR1AJxgZQ@mail.gmail.com>
	<56AF0F5F.6070600@redhat.com>
	<CAJgngAcDJWJn8Xv5ZJ_LG3Bc+sYFwYD9u1xLg=7cjYNTv7zX8w@mail.gmail.com>
Message-ID: <CAHiHDeScYOhrEKYmSU28AaHDvBGcxnyqjakCe5N=QgHuksa4WQ@mail.gmail.com>

Stian,
What you explained seem to contradict the documented purpose for the
IGNORE_EXISTING import option.

/Hristo Stoyanov
On Feb 1, 2016 2:35 AM, "Stian Thorgersen" <sthorger at redhat.com> wrote:

> The import is really meant for a clean database. Or at least to import
> non-existing realms.
>
> Why are you doing an import during upgrade if you are not starting with a
> clean database?
>
> On 1 February 2016 at 08:55, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Hi,
>>
>> could you please create JIRA? Until it's fixed, I suggest to backup your
>> DB and instead use strategy OVERWRITE_EXISTING (or just remove strategy
>> property as OVERWRITE_EXISTING is the default)
>>
>> Marek
>>
>>
>> On 01/02/16 07:47, Hristo Stoyanov wrote:
>>
>> Hi all,
>> I ma trying to install KC1.8.Final over a previous KC1.7 installation
>> backed by Postgres. I use template files to bootstrap my realm:
>>
>> 36 -rw-r--r-- 1 root root 36806 Feb  1 05:50 FinancialApps-realm.json
>> 40 -rw-r--r-- 1 root root 39545 Feb  1 05:50 master-realm.json
>>  4 -rw-r--r-- 1 root root   709 Feb  1 05:50 master-users-0.json
>>  4 -rw-r--r-- 1 root root    77 Feb  1 05:50 version.json
>>
>> and I use the import facility:
>>
>>             -Dkeycloak.migration.action=import \
>>             -Dkeycloak.migration.provider=dir \
>>             -Dkeycloak.migration.dir={{wildfly_home}}/keycloak \
>>             -Dkeycloak.migration.strategy=IGNORE_EXISTING
>>
>> Below is the exception I get. I understand that I can wipe out my
>> Postgress database and have a clean import, but I thought the import was
>> careful enough to check for duplicate keys???
>> =================================================================
>> Caused by: org.keycloak.models.ModelDuplicateException:
>> javax.persistence.PersistenceException:
>> org.hibernate.exception.ConstraintViolationException: could not execute
>> statement
>> at
>> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:40)
>> at
>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
>> at com.sun.proxy.$Proxy83.flush(Unknown Source)
>> at
>> org.keycloak.models.jpa.JpaUserProvider.addUser(JpaUserProvider.java:61)
>> at
>> org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.addUser(DefaultCacheUserProvider.java:267)
>> at
>> org.keycloak.models.utils.RepresentationToModel.createUser(RepresentationToModel.java:1168)
>> at
>> org.keycloak.exportimport.util.ImportUtils.importUsers(ImportUtils.java:191)
>> at
>> org.keycloak.exportimport.util.ImportUtils.importUsersFromStream(ImportUtils.java:175)
>> at
>> org.keycloak.exportimport.dir.DirImportProvider$4.runExportImportTask(DirImportProvider.java:121)
>> at
>> org.keycloak.exportimport.util.ExportImportSessionTask.run(ExportImportSessionTask.java:18)
>> at
>> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:267)
>> at
>> org.keycloak.exportimport.dir.DirImportProvider.importRealm(DirImportProvider.java:117)
>> at
>> org.keycloak.exportimport.dir.DirImportProvider.importModel(DirImportProvider.java:55)
>> at
>> org.keycloak.exportimport.ExportImportManager.runImport(ExportImportManager.java:69)
>> at
>> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:107)
>> 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:150)
>> ... 19 more
>> Caused by: javax.persistence.PersistenceException:
>> org.hibernate.exception.ConstraintViolationException: could not execute
>> statement
>> at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692)
>> at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602)
>> at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1608)
>> at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1303)
>> at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:497)
>> at
>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
>> ... 37 more
>> Caused by: org.hibernate.exception.ConstraintViolationException: could
>> not execute statement
>> at
>> org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:112)
>> at
>> org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)
>> at
>> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
>> at
>> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:95)
>> at
>> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:207)
>> at
>> org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:45)
>> at
>> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2886)
>> at
>> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3386)
>> at
>> org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:89)
>> at
>> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:560)
>> at
>> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:434)
>> at
>> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337)
>> at
>> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
>> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1282)
>> at
>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1300)
>> ... 41 more
>> *Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value
>> violates unique constraint "uk_ru8tt6t700s9v50bu18ws5ha6"*
>> *  Detail: Key (realm_id, username)=(master, admin) already exists.*
>> at
>> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2182)
>> at
>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1911)
>> at
>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:173)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:645)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:495)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:441)
>> at sun.reflect.GeneratedMethodAccessor295.invoke(Unknown Source)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:497)
>> at
>> org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:453)
>> at com.sun.proxy.$Proxy84.executeUpdate(Unknown Source)
>> at
>> org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
>> at
>> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160201/4f4d51c5/attachment.html 

From beny.moser at gmail.com  Mon Feb  1 15:37:14 2016
From: beny.moser at gmail.com (Benjamin Moser)
Date: Mon, 1 Feb 2016 21:37:14 +0100
Subject: [keycloak-user] spring-security-adapter on wildfly: How?
Message-ID: <CAEt_YbeMkUXM-Jq2tBtOskVL+_tcEvX-KG4TLh3TuWGQi=3n_Q@mail.gmail.com>

Hello

I've been trying to get to work spring security with keycloak on widlfly
for hours.

I follow the instructions as described here:
http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#spring-security-adapter
.

This is my environment:
- Wildfly 9 (not spring-boot)
- Keycloak 1.7
- keycloak-spring-security-adapter in webapplication
- keycloak.json in WEB-INF
- spring-security-xml configuration as described in 8.10.2.2.
- No security config in web.xml
- No keycloak adapter in wildfly

Application starts up fine, spring security configuration seems to be
loaded. But when I directly access a protected resources, the resource is
not protected and I can access it directly. I am not redirected to login on
keycloak. So it seems spring security is not picking up the security
rules...

When I do not use the keycloak-spring-security-adapter and do the security
configuration in web.xml, it works. But then I'm missing the integration
with spring security, and thats what I need...

Any advice is more than welcomed...

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/dbbe907a/attachment-0001.html 

From lingvisa at gmail.com  Mon Feb  1 15:43:53 2016
From: lingvisa at gmail.com (Martin Min)
Date: Mon, 1 Feb 2016 12:43:53 -0800
Subject: [keycloak-user] Social login error message
In-Reply-To: <56AF10AE.7050006@redhat.com>
References: <CAKUZDO70xSn2PTkKqOHqkWqNH2eYNtA6LHSVNxp24zV+1s_pqg@mail.gmail.com>
	<56AF10AE.7050006@redhat.com>
Message-ID: <CAKUZDO5aSEBNnHrObpKp+vKhjSNvaPjCFGcSU9AD8pf5kNwXAA@mail.gmail.com>

Hi, Marek and all:

I received this message for Google and github now. I followed the
instruction in the doc and created the identity broker:

12:40:39,607 WARN  [org.keycloak.events] (default task-63)
type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=bword, clientId=null,
userId=null, ipAddress=127.0.0.1,
error=couldNotSendAuthenticationRequestMessage, identity_provider=github
12:40:39,608 ERROR [org.keycloak.services.resources.IdentityBrokerService]
(default task-63) couldNotSendAuthenticationRequestMessage:
org.keycloak.broker.provider.IdentityBrokerException: Invalid code, please
login again through your client.

 at
org.keycloak.services.resources.IdentityBrokerService.parseClientSessionCode(IdentityBrokerService.java:551)
        at
org.keycloak.services.resources.IdentityBrokerService.performLogin(IdentityBrokerService.java:149)
        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:483)
        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:103)
        at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
        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:61)
        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(ThreadPoolExecutor.java:1142)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:744)

Thank you.

On Mon, Feb 1, 2016 at 12:00 AM, Marek Posolda <mposolda at redhat.com> wrote:

> I suggest to upgrade to 1.8 where this is fixed. Or you can workaround in
> 1.7 by edit file
> $KEYCLOAK_HOME/modules/system/layers/base/org/keycloak/keycloak-login-freemarker/main/module.xml
> and add the line:
>
> <module name="org.keycloak.keycloak-broker-core"/>
>
> into dependencies section. Same for module
> $KEYCLOAK_HOME/modules/system/layers/base/org/keycloak/keycloak-email-freemarker/main/module.xml
>
> Marek
>
>
> On 29/01/16 23:49, Martin Min wrote:
>
> Hello, I am configuring the social login with google, twitter and github.
> Everything else works fine until this point, namely, after it's authorized,
> at the "update account information" page, after I fill out the fields on
> this page, clicked the "submitted" and I received this error message.
>
> What could cause this? I followed the instruction carefully, but not sure
> what caused this.
>
> Context Path:
> /auth
>
> Servlet Path:
>
> Path Info:
> /realms/myproject/login-actions/first-broker-login
>
> Query String:
>
> code=Rp6yjxlbY0_IIjk8_-IpyOy_x8m_hC0d8zz4t-hp7vI.9ea99589-bf8d-4a13-930a-c58661dfb925
>
> *Stack Trace*
> java.lang.RuntimeException: request path:
> /auth/realms/myproject/login-actions/first-broker-login
>
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:75)
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
>
> Caused by: org.jboss.resteasy.spi.UnhandledException:
> java.lang.NoClassDefFoundError:
> org/keycloak/broker/provider/BrokeredIdentityContext
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20160201/328de297/attachment.html 

From bburke at redhat.com  Mon Feb  1 16:02:10 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 1 Feb 2016 16:02:10 -0500
Subject: [keycloak-user] Social login error message
In-Reply-To: <CAKUZDO5aSEBNnHrObpKp+vKhjSNvaPjCFGcSU9AD8pf5kNwXAA@mail.gmail.com>
References: <CAKUZDO70xSn2PTkKqOHqkWqNH2eYNtA6LHSVNxp24zV+1s_pqg@mail.gmail.com>
	<56AF10AE.7050006@redhat.com>
	<CAKUZDO5aSEBNnHrObpKp+vKhjSNvaPjCFGcSU9AD8pf5kNwXAA@mail.gmail.com>
Message-ID: <56AFC7D2.4090709@redhat.com>

version?

On 2/1/2016 3:43 PM, Martin Min wrote:
> Hi, Marek and all:
>
> I received this message for Google and github now. I followed the 
> instruction in the doc and created the identity broker:
>
> 12:40:39,607 WARN  [org.keycloak.events] (default task-63) 
> type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=bword, clientId=null, 
> userId=null, ipAddress=127.0.0.1, 
> error=couldNotSendAuthenticationRequestMessage, identity_provider=github
> 12:40:39,608 ERROR 
> [org.keycloak.services.resources.IdentityBrokerService] (default 
> task-63) couldNotSendAuthenticationRequestMessage: 
> org.keycloak.broker.provider.IdentityBrokerException: Invalid code, 
> please login again through your client.
>
>  at 
> org.keycloak.services.resources.IdentityBrokerService.parseClientSessionCode(IdentityBrokerService.java:551)
>         at 
> org.keycloak.services.resources.IdentityBrokerService.performLogin(IdentityBrokerService.java:149)
>         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:483)
>         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:103)
>         at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>         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:61)
>         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(ThreadPoolExecutor.java:1142)
>         at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:744)
>
> Thank you.
>
> On Mon, Feb 1, 2016 at 12:00 AM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     I suggest to upgrade to 1.8 where this is fixed. Or you can
>     workaround in 1.7 by edit file
>     $KEYCLOAK_HOME/modules/system/layers/base/org/keycloak/keycloak-login-freemarker/main/module.xml
>     and add the line:
>
>     <module name="org.keycloak.keycloak-broker-core"/>
>
>     into dependencies section. Same for module
>     $KEYCLOAK_HOME/modules/system/layers/base/org/keycloak/keycloak-email-freemarker/main/module.xml
>
>     Marek
>
>
>     On 29/01/16 23:49, Martin Min wrote:
>>     Hello, I am configuring the social login with google, twitter and
>>     github. Everything else works fine until this point, namely,
>>     after it's authorized, at the "update account information" page,
>>     after I fill out the fields on this page, clicked the "submitted"
>>     and I received this error message.
>>
>>     What could cause this? I followed the instruction carefully, but
>>     not sure what caused this.
>>
>>     Context Path:
>>     /auth
>>
>>     Servlet Path:
>>
>>     Path Info:
>>     /realms/myproject/login-actions/first-broker-login
>>
>>     Query String:
>>     code=Rp6yjxlbY0_IIjk8_-IpyOy_x8m_hC0d8zz4t-hp7vI.9ea99589-bf8d-4a13-930a-c58661dfb925
>>
>>     *Stack Trace*
>>     java.lang.RuntimeException: request path:
>>     /auth/realms/myproject/login-actions/first-broker-login
>>     org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:75)
>>     io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>     io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>>     io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>>     io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>     io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>     org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>     io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>     io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>     io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>     io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>     io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>     io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>     io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>     io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>>     io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>     io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>     io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>     org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>     io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>     io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>     io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>>     io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>>     io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>>     io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>>     io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>>     io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>>     java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>     java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>     java.lang.Thread.run(Thread.java:745)
>>
>>     Caused by: org.jboss.resteasy.spi.UnhandledException:
>>     java.lang.NoClassDefFoundError:
>>     org/keycloak/broker/provider/BrokeredIdentityContext
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160201/c71b158d/attachment-0001.html 

From lingvisa at gmail.com  Mon Feb  1 16:05:47 2016
From: lingvisa at gmail.com (Martin Min)
Date: Mon, 1 Feb 2016 13:05:47 -0800
Subject: [keycloak-user] Social login error message
In-Reply-To: <CAKUZDO5aSEBNnHrObpKp+vKhjSNvaPjCFGcSU9AD8pf5kNwXAA@mail.gmail.com>
References: <CAKUZDO70xSn2PTkKqOHqkWqNH2eYNtA6LHSVNxp24zV+1s_pqg@mail.gmail.com>
	<56AF10AE.7050006@redhat.com>
	<CAKUZDO5aSEBNnHrObpKp+vKhjSNvaPjCFGcSU9AD8pf5kNwXAA@mail.gmail.com>
Message-ID: <CAKUZDO6UZGWJQ7nRKMTtoFJ6HuOhGrgaJyGPBBYGHoJzY+YW7Q@mail.gmail.com>

I restarted my keycloak server and my application,and clicked "Twitter" to
log in, and I received a different error message. When it redirects to my
log in page from twitter, I got a single "Forbidden" message on the login
page. It looks like the authentication through the identity broker is
right, but somehow the login page is now not allowed to be accessed from my
client (browser). I tried github and got the same problem.

What may cause this? Thank you.

On Mon, Feb 1, 2016 at 12:43 PM, Martin Min <lingvisa at gmail.com> wrote:

> Hi, Marek and all:
>
> I received this message for Google and github now. I followed the
> instruction in the doc and created the identity broker:
>
> 12:40:39,607 WARN  [org.keycloak.events] (default task-63)
> type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=bword, clientId=null,
> userId=null, ipAddress=127.0.0.1,
> error=couldNotSendAuthenticationRequestMessage, identity_provider=github
> 12:40:39,608 ERROR [org.keycloak.services.resources.IdentityBrokerService]
> (default task-63) couldNotSendAuthenticationRequestMessage:
> org.keycloak.broker.provider.IdentityBrokerException: Invalid code, please
> login again through your client.
>
>  at
> org.keycloak.services.resources.IdentityBrokerService.parseClientSessionCode(IdentityBrokerService.java:551)
>         at
> org.keycloak.services.resources.IdentityBrokerService.performLogin(IdentityBrokerService.java:149)
>         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:483)
>         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:103)
>         at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>         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:61)
>         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(ThreadPoolExecutor.java:1142)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:744)
>
> Thank you.
>
> On Mon, Feb 1, 2016 at 12:00 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
>
>> I suggest to upgrade to 1.8 where this is fixed. Or you can workaround in
>> 1.7 by edit file
>> $KEYCLOAK_HOME/modules/system/layers/base/org/keycloak/keycloak-login-freemarker/main/module.xml
>> and add the line:
>>
>> <module name="org.keycloak.keycloak-broker-core"/>
>>
>> into dependencies section. Same for module
>> $KEYCLOAK_HOME/modules/system/layers/base/org/keycloak/keycloak-email-freemarker/main/module.xml
>>
>> Marek
>>
>>
>> On 29/01/16 23:49, Martin Min wrote:
>>
>> Hello, I am configuring the social login with google, twitter and github.
>> Everything else works fine until this point, namely, after it's authorized,
>> at the "update account information" page, after I fill out the fields on
>> this page, clicked the "submitted" and I received this error message.
>>
>> What could cause this? I followed the instruction carefully, but not sure
>> what caused this.
>>
>> Context Path:
>> /auth
>>
>> Servlet Path:
>>
>> Path Info:
>> /realms/myproject/login-actions/first-broker-login
>>
>> Query String:
>>
>> code=Rp6yjxlbY0_IIjk8_-IpyOy_x8m_hC0d8zz4t-hp7vI.9ea99589-bf8d-4a13-930a-c58661dfb925
>>
>> *Stack Trace*
>> java.lang.RuntimeException: request path:
>> /auth/realms/myproject/login-actions/first-broker-login
>>
>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:75)
>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>
>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>>
>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>>
>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>
>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>
>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>
>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>
>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>
>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>
>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>>
>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>
>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>>
>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>>
>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>>
>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> java.lang.Thread.run(Thread.java:745)
>>
>> Caused by: org.jboss.resteasy.spi.UnhandledException:
>> java.lang.NoClassDefFoundError:
>> org/keycloak/broker/provider/BrokeredIdentityContext
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20160201/5243f595/attachment.html 

From sthorger at redhat.com  Tue Feb  2 03:45:01 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 2 Feb 2016 09:45:01 +0100
Subject: [keycloak-user] keycloak-server.json settings in 1.8.0.Final
In-Reply-To: <D2D4EEDC.1163F%pblair@clearme.com>
References: <D2D4EEDC.1163F%pblair@clearme.com>
Message-ID: <CAJgngAeCPqPz9YEQzpK3FfrRiwndKazVgVo5_rW7FsG3BH_sHQ@mail.gmail.com>

If you look at the migration guide you'll notice that they are no longer
needed. As Infinispan is the only built-in provider for these it's no
longer any need to configure which one to use.

On 1 February 2016 at 17:15, Paul Blair <pblair at clearme.com> wrote:

> I'm upgrading from 1.7.0.Final to 1.8.0.Final and when comparing my
> keycloak-server.json settings I see the following are not there in the
> newer version:
>
>     "userSessions": {
>         "provider" : "infinispan"
>     },
>
>     "realmCache": {
>         "provider": "infinispan"
>     },
>
>     "userCache": {
>         "provider": "infinispan"
>     },
>
> These may be configurations I added in 1.7.0, but I can't find a reference
> to them in the 1.8.0.Final reference guide. Are they now obsolete?
>
> _______________________________________________
> 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/20160202/9afb51e2/attachment-0001.html 

From sthorger at redhat.com  Tue Feb  2 03:45:44 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 2 Feb 2016 09:45:44 +0100
Subject: [keycloak-user] add-user-keycloak.sh in 1.8.0.Final
In-Reply-To: <D2D4EFA0.11646%pblair@clearme.com>
References: <D2D4EFA0.11646%pblair@clearme.com>
Message-ID: <CAJgngAeQQyBuATSvqP2kBGa0cL0L2=DM_qUowVzoO9z5iwdt5Q@mail.gmail.com>

Yes, as the overlay is to be added on to an existing WildFly installation
we don't override the add-user script from WildFly and instead rename it.
Same as we do for the standalone-keycloak.xml

On 1 February 2016 at 17:19, Paul Blair <pblair at clearme.com> wrote:

> I'm noticing the 1.8.0.Final overlay contains a script
> named add-user-keycloak.sh but the reference guide only mentions
> add-user.sh. Should this script be used instead of add-user.sh?
>
> _______________________________________________
> 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/20160202/d6f37bbd/attachment.html 

From sthorger at redhat.com  Tue Feb  2 03:48:18 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 2 Feb 2016 09:48:18 +0100
Subject: [keycloak-user] KC1.8 failing realm merge/upgrade ?
In-Reply-To: <CAHiHDeScYOhrEKYmSU28AaHDvBGcxnyqjakCe5N=QgHuksa4WQ@mail.gmail.com>
References: <CAHiHDeRmDvwT1cY6j5znOVAoiSrwdNVqSGGVoHdmUyR1AJxgZQ@mail.gmail.com>
	<56AF0F5F.6070600@redhat.com>
	<CAJgngAcDJWJn8Xv5ZJ_LG3Bc+sYFwYD9u1xLg=7cjYNTv7zX8w@mail.gmail.com>
	<CAHiHDeScYOhrEKYmSU28AaHDvBGcxnyqjakCe5N=QgHuksa4WQ@mail.gmail.com>
Message-ID: <CAJgngAe_LQ8pS-iqFST02Y-=wDikZHfW2oroR2WGh6KUqBK5PA@mail.gmail.com>

It looks like you've found a bug for the import. However, are you doing a
migration as the same time as you are importing existing realms from a json
import?

My point was just the fact that it seems you are mixing two strategies for
migrating.

On 1 February 2016 at 21:34, Hristo Stoyanov <hr.stoyanov at peruncs.com>
wrote:

> Stian,
> What you explained seem to contradict the documented purpose for the
> IGNORE_EXISTING import option.
>
> /Hristo Stoyanov
> On Feb 1, 2016 2:35 AM, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>
>> The import is really meant for a clean database. Or at least to import
>> non-existing realms.
>>
>> Why are you doing an import during upgrade if you are not starting with a
>> clean database?
>>
>> On 1 February 2016 at 08:55, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> could you please create JIRA? Until it's fixed, I suggest to backup your
>>> DB and instead use strategy OVERWRITE_EXISTING (or just remove strategy
>>> property as OVERWRITE_EXISTING is the default)
>>>
>>> Marek
>>>
>>>
>>> On 01/02/16 07:47, Hristo Stoyanov wrote:
>>>
>>> Hi all,
>>> I ma trying to install KC1.8.Final over a previous KC1.7 installation
>>> backed by Postgres. I use template files to bootstrap my realm:
>>>
>>> 36 -rw-r--r-- 1 root root 36806 Feb  1 05:50 FinancialApps-realm.json
>>> 40 -rw-r--r-- 1 root root 39545 Feb  1 05:50 master-realm.json
>>>  4 -rw-r--r-- 1 root root   709 Feb  1 05:50 master-users-0.json
>>>  4 -rw-r--r-- 1 root root    77 Feb  1 05:50 version.json
>>>
>>> and I use the import facility:
>>>
>>>             -Dkeycloak.migration.action=import \
>>>             -Dkeycloak.migration.provider=dir \
>>>             -Dkeycloak.migration.dir={{wildfly_home}}/keycloak \
>>>             -Dkeycloak.migration.strategy=IGNORE_EXISTING
>>>
>>> Below is the exception I get. I understand that I can wipe out my
>>> Postgress database and have a clean import, but I thought the import was
>>> careful enough to check for duplicate keys???
>>> =================================================================
>>> Caused by: org.keycloak.models.ModelDuplicateException:
>>> javax.persistence.PersistenceException:
>>> org.hibernate.exception.ConstraintViolationException: could not execute
>>> statement
>>> at
>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:40)
>>> at
>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
>>> at com.sun.proxy.$Proxy83.flush(Unknown Source)
>>> at
>>> org.keycloak.models.jpa.JpaUserProvider.addUser(JpaUserProvider.java:61)
>>> at
>>> org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.addUser(DefaultCacheUserProvider.java:267)
>>> at
>>> org.keycloak.models.utils.RepresentationToModel.createUser(RepresentationToModel.java:1168)
>>> at
>>> org.keycloak.exportimport.util.ImportUtils.importUsers(ImportUtils.java:191)
>>> at
>>> org.keycloak.exportimport.util.ImportUtils.importUsersFromStream(ImportUtils.java:175)
>>> at
>>> org.keycloak.exportimport.dir.DirImportProvider$4.runExportImportTask(DirImportProvider.java:121)
>>> at
>>> org.keycloak.exportimport.util.ExportImportSessionTask.run(ExportImportSessionTask.java:18)
>>> at
>>> org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:267)
>>> at
>>> org.keycloak.exportimport.dir.DirImportProvider.importRealm(DirImportProvider.java:117)
>>> at
>>> org.keycloak.exportimport.dir.DirImportProvider.importModel(DirImportProvider.java:55)
>>> at
>>> org.keycloak.exportimport.ExportImportManager.runImport(ExportImportManager.java:69)
>>> at
>>> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:107)
>>> 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:150)
>>> ... 19 more
>>> Caused by: javax.persistence.PersistenceException:
>>> org.hibernate.exception.ConstraintViolationException: could not execute
>>> statement
>>> at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1692)
>>> at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1602)
>>> at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1608)
>>> at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1303)
>>> at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:497)
>>> at
>>> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
>>> ... 37 more
>>> Caused by: org.hibernate.exception.ConstraintViolationException: could
>>> not execute statement
>>> at
>>> org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:112)
>>> at
>>> org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:42)
>>> at
>>> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
>>> at
>>> org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:95)
>>> at
>>> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:207)
>>> at
>>> org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:45)
>>> at
>>> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2886)
>>> at
>>> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3386)
>>> at
>>> org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:89)
>>> at
>>> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:560)
>>> at
>>> org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:434)
>>> at
>>> org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337)
>>> at
>>> org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39)
>>> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1282)
>>> at
>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:1300)
>>> ... 41 more
>>> *Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key
>>> value violates unique constraint "uk_ru8tt6t700s9v50bu18ws5ha6"*
>>> *  Detail: Key (realm_id, username)=(master, admin) already exists.*
>>> at
>>> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2182)
>>> at
>>> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1911)
>>> at
>>> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:173)
>>> at
>>> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:645)
>>> at
>>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:495)
>>> at
>>> org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:441)
>>> at sun.reflect.GeneratedMethodAccessor295.invoke(Unknown Source)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:497)
>>> at
>>> org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:453)
>>> at com.sun.proxy.$Proxy84.executeUpdate(Unknown Source)
>>> at
>>> org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:537)
>>> at
>>> org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:204)
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160202/a493d4c1/attachment-0001.html 

From sthorger at redhat.com  Tue Feb  2 03:49:26 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 2 Feb 2016 09:49:26 +0100
Subject: [keycloak-user] Is there a REST Admin API to initiate the Reset
 Password flow?
In-Reply-To: <CAPj1eSwLt5qGv3hOJr7WZy37YeCxsjT3h8_Pu5-t2Mpx7BHvaA@mail.gmail.com>
References: <CAPj1eSx=RVncaaiGGNT7ohCb0qDyHZ8e0hqAk=GSUdwqv7imLg@mail.gmail.com>
	<CAJgngAdHVPFgFVptNGikngi9cw+fEaGV6WeWigLuEWtpR1m95g@mail.gmail.com>
	<CAOjtoUPYiLLryDvYOH7LLw0W1Cvgkw0hbCAqd5gALSaRX9vs1g@mail.gmail.com>
	<CAPj1eSzAba_K03QG_gb3ynFyfeVPnKHBZLaz3X=Qq31FNQGRyw@mail.gmail.com>
	<CAJgngAeW=-Z-P=pyxRWV0OGyXG=2-AH52KZ1ocTdicV9_MUhGg@mail.gmail.com>
	<CAPj1eSwLt5qGv3hOJr7WZy37YeCxsjT3h8_Pu5-t2Mpx7BHvaA@mail.gmail.com>
Message-ID: <CAJgngAdaxL4+dtp3tOAoN_Y=xReh8iDCzXAA+EYviBbWtg=uAg@mail.gmail.com>

Have no idea what you are saying.

We don't have any API outside of the admin endpoints that do password
reset, register email or anything else like that. For the admin endpoints
we have a very flexibly endpoint that lets you send exactly what actions
you want.

On 1 February 2016 at 19:00, Lohitha Chiranjeewa <kalc04 at gmail.com> wrote:

> Hi Stian,
>
> I was referring to a potential API endpoint which actually sends out the
> password reset email (there's a similar API which sends out the
> registration email), not the existing one which just resets the password.
>
>
> Regards,
> Lohitha.
>
> On Mon, Feb 1, 2016 at 3:53 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On 28 January 2016 at 08:41, Lohitha Chiranjeewa <kalc04 at gmail.com>
>> wrote:
>>
>>> Thanks Fabricio, will check on how we can proceed with such an
>>> implementation.
>>>
>>> Since there is an already existing registration-email API, I thought
>>> it's consistent from Keycloak's perspective to expose a reset-password API
>>> as well...
>>>
>>
>> Not sure what you refer to, but there are no APIs for these actions
>> outside of the admin endpoints.
>>
>>
>>>
>>>
>>> Regards,
>>> Lohitha.
>>>
>>> On Thu, Jan 28, 2016 at 2:31 AM, Fabricio Milone <
>>> fabricio.milone at shinetech.com> wrote:
>>>
>>>> Hi Lohitha,
>>>>
>>>> I had the same requirements (Direct grant + forgotten password) and
>>>> ended up implementing a SPI using some piece of code made by Pedro Igor.
>>>>
>>>> An extract of the DEV Mailing list called: "*Add custom REST paths?
>>>> New SPI?*"
>>>>
>>>> *It is part of a working in progress around fine-grained authorization
>>>>> [1].*
>>>>> *The new SPI changes [2] specific to Keycloak are located in a
>>>>> specific branch [3] in my Keycloak fork.*
>>>>
>>>>
>>>>> *I need to discuss these changes with Bill and see what he thinks
>>>>> about it. Depending on his feedback, I can prepare a PR and send these
>>>>> changes to upstream.*
>>>>
>>>>
>>>>>
>>>>> *[1] https://github.com/pedroigor/keycloak-authz
>>>>> <https://github.com/pedroigor/keycloak-authz>*
>>>>> *[2]
>>>>> https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54
>>>>> <https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54>**[3]
>>>>> https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified
>>>>> <https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified>*
>>>>
>>>>
>>>>
>>>> Not sure if Keycloak will ever adopt those changes as official or
>>>> something similar though.
>>>>
>>>> That's a good starting point.
>>>>
>>>> Regards
>>>>
>>>> On 27 January 2016 at 21:19, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> There is in the admin endpoints, but nothing that's available to
>>>>> end-users.
>>>>>
>>>>> On 22 January 2016 at 06:45, Lohitha Chiranjeewa <kalc04 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> There are a few clients of ours who use the Direct Grants API to
>>>>>> authenticate their users. A requirement has come up to provide the Reset
>>>>>> Password flow to those clients. From what I've checked and gathered,
>>>>>> there's no REST API to initiate this flow (sending the Keycloak password
>>>>>> reset email + resetting the password through the UI); only way to do is
>>>>>> through the browser.
>>>>>>
>>>>>> If it's actually there somewhere, can someone point me to it?
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Lohitha.
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Fabricio Milone*
>>>> Developer
>>>>
>>>> *Shine Consulting *
>>>>
>>>> 30/600 Bourke Street
>>>>
>>>> Melbourne VIC 3000
>>>>
>>>> T: 03 8488 9939
>>>>
>>>> M: 04 3200 4006
>>>>
>>>>
>>>> www.shinetech.com  *a* passion for excellence
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160202/548ec609/attachment.html 

From mposolda at redhat.com  Tue Feb  2 04:04:08 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 2 Feb 2016 10:04:08 +0100
Subject: [keycloak-user] Social login error message
In-Reply-To: <CAKUZDO6UZGWJQ7nRKMTtoFJ6HuOhGrgaJyGPBBYGHoJzY+YW7Q@mail.gmail.com>
References: <CAKUZDO70xSn2PTkKqOHqkWqNH2eYNtA6LHSVNxp24zV+1s_pqg@mail.gmail.com>
	<56AF10AE.7050006@redhat.com>
	<CAKUZDO5aSEBNnHrObpKp+vKhjSNvaPjCFGcSU9AD8pf5kNwXAA@mail.gmail.com>
	<CAKUZDO6UZGWJQ7nRKMTtoFJ6HuOhGrgaJyGPBBYGHoJzY+YW7Q@mail.gmail.com>
Message-ID: <56B07108.4020605@redhat.com>

You can check in admin console if user authenticated from Twitter (or 
github) was successfully registered and can be seen in keycloak admin 
console. If yes, it's likely an authorization issue and you need to 
assign some roles to thpse newly created users, so they have access to 
your application. You can use default roles to assign some roles "by 
default" at the time when user is registered. See docs for more details.

Marek

On 01/02/16 22:05, Martin Min wrote:
> I restarted my keycloak server and my application,and clicked 
> "Twitter" to log in, and I received a different error message. When it 
> redirects to my log in page from twitter, I got a single "Forbidden" 
> message on the login page. It looks like the authentication through 
> the identity broker is right, but somehow the login page is now not 
> allowed to be accessed from my client (browser). I tried github and 
> got the same problem.
>
> What may cause this? Thank you.
>
> On Mon, Feb 1, 2016 at 12:43 PM, Martin Min <lingvisa at gmail.com 
> <mailto:lingvisa at gmail.com>> wrote:
>
>     Hi, Marek and all:
>
>     I received this message for Google and github now. I followed the
>     instruction in the doc and created the identity broker:
>
>     12:40:39,607 WARN  [org.keycloak.events] (default task-63)
>     type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=bword, clientId=null,
>     userId=null, ipAddress=127.0.0.1,
>     error=couldNotSendAuthenticationRequestMessage,
>     identity_provider=github
>     12:40:39,608 ERROR
>     [org.keycloak.services.resources.IdentityBrokerService] (default
>     task-63) couldNotSendAuthenticationRequestMessage:
>     org.keycloak.broker.provider.IdentityBrokerException: Invalid
>     code, please login again through your client.
>
>      at
>     org.keycloak.services.resources.IdentityBrokerService.parseClientSessionCode(IdentityBrokerService.java:551)
>             at
>     org.keycloak.services.resources.IdentityBrokerService.performLogin(IdentityBrokerService.java:149)
>             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:483)
>             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:103)
>             at
>     org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>             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:61)
>             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(ThreadPoolExecutor.java:1142)
>             at
>     java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>             at java.lang.Thread.run(Thread.java:744)
>
>     Thank you.
>
>     On Mon, Feb 1, 2016 at 12:00 AM, Marek Posolda
>     <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>
>         I suggest to upgrade to 1.8 where this is fixed. Or you can
>         workaround in 1.7 by edit file
>         $KEYCLOAK_HOME/modules/system/layers/base/org/keycloak/keycloak-login-freemarker/main/module.xml
>         and add the line:
>
>         <module name="org.keycloak.keycloak-broker-core"/>
>
>         into dependencies section. Same for module
>         $KEYCLOAK_HOME/modules/system/layers/base/org/keycloak/keycloak-email-freemarker/main/module.xml
>
>         Marek
>
>
>         On 29/01/16 23:49, Martin Min wrote:
>>         Hello, I am configuring the social login with google, twitter
>>         and github. Everything else works fine until this point,
>>         namely, after it's authorized, at the "update account
>>         information" page, after I fill out the fields on this page,
>>         clicked the "submitted" and I received this error message.
>>
>>         What could cause this? I followed the instruction carefully,
>>         but not sure what caused this.
>>
>>         Context Path:
>>         /auth
>>
>>         Servlet Path:
>>
>>         Path Info:
>>         /realms/myproject/login-actions/first-broker-login
>>
>>         Query String:
>>         code=Rp6yjxlbY0_IIjk8_-IpyOy_x8m_hC0d8zz4t-hp7vI.9ea99589-bf8d-4a13-930a-c58661dfb925
>>
>>         *Stack Trace*
>>         java.lang.RuntimeException: request path:
>>         /auth/realms/myproject/login-actions/first-broker-login
>>         org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:75)
>>         io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>         io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>>         io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>>         io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>         io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>         org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>         io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>         io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>         io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>         io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>         io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>         io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>         io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>         io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>>         io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>         io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>         io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>         org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>         io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>         io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>         io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>>         io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>>         io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>>         io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>>         io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>>         io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>>         java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>         java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>         java.lang.Thread.run(Thread.java:745)
>>
>>         Caused by: org.jboss.resteasy.spi.UnhandledException:
>>         java.lang.NoClassDefFoundError:
>>         org/keycloak/broker/provider/BrokeredIdentityContext
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>         _______________________________________________
>>         keycloak-user mailing list
>>         keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160202/a5d93d44/attachment-0001.html 

From andrey.saroul at gmail.com  Tue Feb  2 06:06:16 2016
From: andrey.saroul at gmail.com (Andrey Saroul)
Date: Tue, 2 Feb 2016 14:06:16 +0300
Subject: [keycloak-user] Keycloak logout flow
Message-ID: <CAFZbuCMQwkS-2nwQmSscqv6JYO_vrHF1PFx=pmRn5rV_L1_k0A@mail.gmail.com>

I'm using keycloak 1.7.0 with WildFly 9.0.2
I have rest service and Keycloak deployed on one the same machine.
Consider this scenario:
1) In browser i try to test my rest service (e.g.
http://my-ip-address:8080/rest/test) secured under Keycloak
2) I got redirect to login page.
3) I enter my login and password.
4) I got some response from my rest service. That's Ok!
5) Then I go to Keycloak admin console, find my user and force session
logout.
6) Then I try to access my rest service again by the same url, and NO
redirect happens. Browser caches jsessionid cookie and don't know anything
about user beeing logout.
It seems to my that during step #6 server should invalidate expired session
cookie due to admin logout.
I considere that user after beeing logout will get redirect to login page
again, and will not be able to access service with old jsessionid cookie.
Is this a bug, or could you help me explain what am i doing wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160202/e38f6bbf/attachment.html 

From andrey.saroul at gmail.com  Tue Feb  2 06:17:04 2016
From: andrey.saroul at gmail.com (Andrey Saroul)
Date: Tue, 2 Feb 2016 14:17:04 +0300
Subject: [keycloak-user] spring-security-adapter on wildfly: How?
Message-ID: <CAFZbuCMBOjWcpEwFhSS=fS3srUZPOT3tert0qrRJRx1Oczn5Zg@mail.gmail.com>

I had the same issue.
I missed the spring security initializer and so springSecurityFilterChain
was not registered.
I added this class in my app, and then all security worked just fine

public class SecurityWebApplicationInitializer
        extends AbstractSecurityWebApplicationInitializer {
}

And by the way, no web.xml required at all if you use annotation config.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160202/5bc64ca9/attachment.html 

From sthorger at redhat.com  Tue Feb  2 07:55:33 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 2 Feb 2016 13:55:33 +0100
Subject: [keycloak-user] Keycloak logout flow
In-Reply-To: <CAFZbuCMQwkS-2nwQmSscqv6JYO_vrHF1PFx=pmRn5rV_L1_k0A@mail.gmail.com>
References: <CAFZbuCMQwkS-2nwQmSscqv6JYO_vrHF1PFx=pmRn5rV_L1_k0A@mail.gmail.com>
Message-ID: <CAJgngAccWZtbRBYjLhtOxBjS8iWY+hN+wxFiE6cdd6j9=kzq7w@mail.gmail.com>

You probably haven't configured admin url for your client so the Keycloak
server can't send backchannel logout to your service

On 2 February 2016 at 12:06, Andrey Saroul <andrey.saroul at gmail.com> wrote:

> I'm using keycloak 1.7.0 with WildFly 9.0.2
> I have rest service and Keycloak deployed on one the same machine.
> Consider this scenario:
> 1) In browser i try to test my rest service (e.g.
> http://my-ip-address:8080/rest/test) secured under Keycloak
> 2) I got redirect to login page.
> 3) I enter my login and password.
> 4) I got some response from my rest service. That's Ok!
> 5) Then I go to Keycloak admin console, find my user and force session
> logout.
> 6) Then I try to access my rest service again by the same url, and NO
> redirect happens. Browser caches jsessionid cookie and don't know anything
> about user beeing logout.
> It seems to my that during step #6 server should invalidate expired
> session cookie due to admin logout.
> I considere that user after beeing logout will get redirect to login page
> again, and will not be able to access service with old jsessionid cookie.
> Is this a bug, or could you help me explain what am i doing wrong?
>
> _______________________________________________
> 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/20160202/02607c6b/attachment.html 

From Edgar at info.nl  Tue Feb  2 11:45:52 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Tue, 2 Feb 2016 16:45:52 +0000
Subject: [keycloak-user] No LDAP Group Attribute mapper in Keycloak?
Message-ID: <68E5BD0C-F36F-4476-A69E-F8200572A474@info.nl>

Hi,

If I am correct there is no LDAP Group Attribute mapper in Keycloak right? There is a User Attribute mapper and there is a Group Mapper but group attributes in LDAP cannot be synched to and from Keycloak at the moment? 

I guess it should not be too hard to write an LDAP Group Attribute mapper should we want to?

cheers

From adrianmatei at gmail.com  Tue Feb  2 14:43:22 2016
From: adrianmatei at gmail.com (Adrian Matei)
Date: Tue, 2 Feb 2016 20:43:22 +0100
Subject: [keycloak-user] password forgotten - override UpdatePasswd
	required action (v 1.7.0)
In-Reply-To: <CAG=THF1+TpQvyi3-bvwmwHTawLYBVpsci-10WVOzKTQ6ZXJ0Tg@mail.gmail.com>
References: <CAG=THF1+TpQvyi3-bvwmwHTawLYBVpsci-10WVOzKTQ6ZXJ0Tg@mail.gmail.com>
Message-ID: <CAG=THF1ojLbhYJwk5k+=4CVa+XFFG+9tJvXNUZMWW=mx9D0-qw@mail.gmail.com>

Solution: I had to register the CustomRequiredAction via the Register
button that appears under Realm > Authentication > Required Actions ...

On Mon, Feb 1, 2016 at 5:25 PM, Adrian Matei <adrianmatei at gmail.com> wrote:

> Hi guys,
>
> in the UpdatePassword class we need to modify the string values that come
> from formData
> so that there are not "password-new" but "passwordNew" (JS conform as
> we've build the GUI with AngularJS on top of Freemarker actions):
>
> https://github.com/keycloak/keycloak/blob/de472dbd43dd2767afb3436835f77924a78e9f82/services/src/main/java/org/keycloak/authentication/requiredactions/UpdatePassword.java#L67
>
>
> We've created our own CustomUpdatePassword (similar with the class above
> except the two lines and own id -UPDATE_PASSWORD_CUSTOM) and tried to hook
> it in our own custom ResetPassword class:
>     @Override
>     public void authenticate(AuthenticationFlowContext context) {
>         if (context.getExecution().isRequired() ||
>                 (context.getExecution().isOptional() &&
>                         configuredFor(context))) {
>
> context.getClientSession().addRequiredAction(CustomUpdatePassword.UPDATE_PASSWORD_CUSTOM);
>         }
>         context.success();
>     }
>
> The custom classes are registered in META-INF services and everything, and
> we can add the custom reset password execution in the Reset Credentials
> workflow...
>
> The result is a NPE in AuthenticationManager by trying to get the
> providerId from the model
> RequiredActionProviderModel model =
> realm.getRequiredActionProviderByAlias(action);
> RequiredActionFactory factory =
> (RequiredActionFactory)session.getKeycloakSessionFactory().getProviderFactory(RequiredActionProvider.class,
> model.getProviderId());
>
> I am tired and cannot look through anymore, so your advice is more than
> welcomed...
>
> Thanks,
> Adrian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160202/8a8571cb/attachment.html 

From lars.noldan at drillinginfo.com  Tue Feb  2 21:29:07 2016
From: lars.noldan at drillinginfo.com (Lars Noldan)
Date: Tue, 2 Feb 2016 20:29:07 -0600
Subject: [keycloak-user] Course and Fine Grained Entitlements
Message-ID: <CAMu7Tor_E5_9k2jQBdYscHtX1FeHb7Jo0YdU1Yz-CsGt0DBaoA@mail.gmail.com>

We're in the investigation stage on moving from a $BigExpensiveVendor
solution toward keycloak, and we're looking for a solution to help manage
both Course and Fine grained entitlements.  Keycloak appears to be a
fantastic authentication solution, but I'm wondering what are you, the
keycloak community using to handle Authorization?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160202/41619ea3/attachment-0001.html 

From kalc04 at gmail.com  Wed Feb  3 01:10:28 2016
From: kalc04 at gmail.com (Lohitha Chiranjeewa)
Date: Wed, 3 Feb 2016 11:40:28 +0530
Subject: [keycloak-user] Is there a REST Admin API to initiate the Reset
 Password flow?
In-Reply-To: <CAJgngAdaxL4+dtp3tOAoN_Y=xReh8iDCzXAA+EYviBbWtg=uAg@mail.gmail.com>
References: <CAPj1eSx=RVncaaiGGNT7ohCb0qDyHZ8e0hqAk=GSUdwqv7imLg@mail.gmail.com>
	<CAJgngAdHVPFgFVptNGikngi9cw+fEaGV6WeWigLuEWtpR1m95g@mail.gmail.com>
	<CAOjtoUPYiLLryDvYOH7LLw0W1Cvgkw0hbCAqd5gALSaRX9vs1g@mail.gmail.com>
	<CAPj1eSzAba_K03QG_gb3ynFyfeVPnKHBZLaz3X=Qq31FNQGRyw@mail.gmail.com>
	<CAJgngAeW=-Z-P=pyxRWV0OGyXG=2-AH52KZ1ocTdicV9_MUhGg@mail.gmail.com>
	<CAPj1eSwLt5qGv3hOJr7WZy37YeCxsjT3h8_Pu5-t2Mpx7BHvaA@mail.gmail.com>
	<CAJgngAdaxL4+dtp3tOAoN_Y=xReh8iDCzXAA+EYviBbWtg=uAg@mail.gmail.com>
Message-ID: <CAPj1eSxzULj6eTXQGX2SGKAD-MujUJ7yL-nCNEmaNCGkBsZD9Q@mail.gmail.com>

Hey Stian, let me re-track what I've been trying to say here....

My first query was to check with you guys if there was an admin API to
trigger the reset-password email. Seems there is no such API. However,
there is an admin API to just reset the password without email verification
(
http://keycloak.github.io/docs/rest-api/index.html#_set_up_a_temporary_password_for_the_user
).

My follow-up concern was that since there is an admin API to trigger the
verification email (
http://keycloak.github.io/docs/rest-api/index.html#_send_an_email_verification_email_to_the_user),
it would have been consistent if there was an admin API to send the
reset-password email as well.

Hope this clarifies the misunderstanding.


Regards,
Lohitha.

On Tue, Feb 2, 2016 at 2:19 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Have no idea what you are saying.
>
> We don't have any API outside of the admin endpoints that do password
> reset, register email or anything else like that. For the admin endpoints
> we have a very flexibly endpoint that lets you send exactly what actions
> you want.
>
> On 1 February 2016 at 19:00, Lohitha Chiranjeewa <kalc04 at gmail.com> wrote:
>
>> Hi Stian,
>>
>> I was referring to a potential API endpoint which actually sends out the
>> password reset email (there's a similar API which sends out the
>> registration email), not the existing one which just resets the password.
>>
>>
>> Regards,
>> Lohitha.
>>
>> On Mon, Feb 1, 2016 at 3:53 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On 28 January 2016 at 08:41, Lohitha Chiranjeewa <kalc04 at gmail.com>
>>> wrote:
>>>
>>>> Thanks Fabricio, will check on how we can proceed with such an
>>>> implementation.
>>>>
>>>> Since there is an already existing registration-email API, I thought
>>>> it's consistent from Keycloak's perspective to expose a reset-password API
>>>> as well...
>>>>
>>>
>>> Not sure what you refer to, but there are no APIs for these actions
>>> outside of the admin endpoints.
>>>
>>>
>>>>
>>>>
>>>> Regards,
>>>> Lohitha.
>>>>
>>>> On Thu, Jan 28, 2016 at 2:31 AM, Fabricio Milone <
>>>> fabricio.milone at shinetech.com> wrote:
>>>>
>>>>> Hi Lohitha,
>>>>>
>>>>> I had the same requirements (Direct grant + forgotten password) and
>>>>> ended up implementing a SPI using some piece of code made by Pedro Igor.
>>>>>
>>>>> An extract of the DEV Mailing list called: "*Add custom REST paths?
>>>>> New SPI?*"
>>>>>
>>>>> *It is part of a working in progress around fine-grained authorization
>>>>>> [1].*
>>>>>> *The new SPI changes [2] specific to Keycloak are located in a
>>>>>> specific branch [3] in my Keycloak fork.*
>>>>>
>>>>>
>>>>>> *I need to discuss these changes with Bill and see what he thinks
>>>>>> about it. Depending on his feedback, I can prepare a PR and send these
>>>>>> changes to upstream.*
>>>>>
>>>>>
>>>>>>
>>>>>> *[1] https://github.com/pedroigor/keycloak-authz
>>>>>> <https://github.com/pedroigor/keycloak-authz>*
>>>>>> *[2]
>>>>>> https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54
>>>>>> <https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54>**[3]
>>>>>> https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified
>>>>>> <https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified>*
>>>>>
>>>>>
>>>>>
>>>>> Not sure if Keycloak will ever adopt those changes as official or
>>>>> something similar though.
>>>>>
>>>>> That's a good starting point.
>>>>>
>>>>> Regards
>>>>>
>>>>> On 27 January 2016 at 21:19, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> There is in the admin endpoints, but nothing that's available to
>>>>>> end-users.
>>>>>>
>>>>>> On 22 January 2016 at 06:45, Lohitha Chiranjeewa <kalc04 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> There are a few clients of ours who use the Direct Grants API to
>>>>>>> authenticate their users. A requirement has come up to provide the Reset
>>>>>>> Password flow to those clients. From what I've checked and gathered,
>>>>>>> there's no REST API to initiate this flow (sending the Keycloak password
>>>>>>> reset email + resetting the password through the UI); only way to do is
>>>>>>> through the browser.
>>>>>>>
>>>>>>> If it's actually there somewhere, can someone point me to it?
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Lohitha.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Fabricio Milone*
>>>>> Developer
>>>>>
>>>>> *Shine Consulting *
>>>>>
>>>>> 30/600 Bourke Street
>>>>>
>>>>> Melbourne VIC 3000
>>>>>
>>>>> T: 03 8488 9939
>>>>>
>>>>> M: 04 3200 4006
>>>>>
>>>>>
>>>>> www.shinetech.com  *a* passion for excellence
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160203/d3d6f8c5/attachment.html 

From stuart.jacobs at symbiotics.co.za  Wed Feb  3 02:40:15 2016
From: stuart.jacobs at symbiotics.co.za (Stuart Jacobs)
Date: Wed, 3 Feb 2016 09:40:15 +0200
Subject: [keycloak-user] User-Federation
Message-ID: <CADW1CM8kNr=WkTSm4jp_BZm4Bdm6JSJhSLgPvhLQxDSmrC653A@mail.gmail.com>

Hi Everyone,

I have an application that runs on a postgresql database, keycloak has been
configured and has created all the required tables/columns in my schema
using liquibase on start up of the keycloak server.

I need to authenticate users using the projects existing user table
obtaining the username and password from this table.

I have had a look at the federation provider project under the example
projects but this still eludes me as to how I change the keycloak mapping
to use my own tables in postgress?

Can someone please point me in the right direction or if someone has
implemented such a solution please share how you have done it?

Thanks everyone.

  Regards,
  Stuart Jacobs

-- 


www.symbiotics.co.za
********************************************************************************
This email and any accompanying attachments may contain confidential and 
proprietary information. This information is private and protected by law 
and, accordingly, if you are not the intended recipient, you are requested 
to delete this entire communication immediately and are notified that any 
disclosure, copying or distribution of or taking any action based on this 
information is prohibited. 

Emails cannot be guaranteed to be secure or free of errors or viruses. The 
sender does not accept any liability or responsibility for any 
interception, corruption, destruction, loss, late arrival or incompleteness 
of or tampering or interference with any of the information contained in 
this email or for its incorrect delivery or non-delivery for whatsoever 
reason or for its effect on any electronic device of the recipient. 

********************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160203/99e15dda/attachment.html 

From sthorger at redhat.com  Wed Feb  3 03:07:01 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 3 Feb 2016 09:07:01 +0100
Subject: [keycloak-user] Is there a REST Admin API to initiate the Reset
 Password flow?
In-Reply-To: <CAPj1eSxzULj6eTXQGX2SGKAD-MujUJ7yL-nCNEmaNCGkBsZD9Q@mail.gmail.com>
References: <CAPj1eSx=RVncaaiGGNT7ohCb0qDyHZ8e0hqAk=GSUdwqv7imLg@mail.gmail.com>
	<CAJgngAdHVPFgFVptNGikngi9cw+fEaGV6WeWigLuEWtpR1m95g@mail.gmail.com>
	<CAOjtoUPYiLLryDvYOH7LLw0W1Cvgkw0hbCAqd5gALSaRX9vs1g@mail.gmail.com>
	<CAPj1eSzAba_K03QG_gb3ynFyfeVPnKHBZLaz3X=Qq31FNQGRyw@mail.gmail.com>
	<CAJgngAeW=-Z-P=pyxRWV0OGyXG=2-AH52KZ1ocTdicV9_MUhGg@mail.gmail.com>
	<CAPj1eSwLt5qGv3hOJr7WZy37YeCxsjT3h8_Pu5-t2Mpx7BHvaA@mail.gmail.com>
	<CAJgngAdaxL4+dtp3tOAoN_Y=xReh8iDCzXAA+EYviBbWtg=uAg@mail.gmail.com>
	<CAPj1eSxzULj6eTXQGX2SGKAD-MujUJ7yL-nCNEmaNCGkBsZD9Q@mail.gmail.com>
Message-ID: <CAJgngAeFdvgW4+mNcgDpDQ=K11MJKj8XwL57rJFH4AsNnjjDbA@mail.gmail.com>

There is an admin api to set password reset email, verify email and other
required actions, including custom actions, can be triggered with this api
as well.

On 3 February 2016 at 07:10, Lohitha Chiranjeewa <kalc04 at gmail.com> wrote:

> Hey Stian, let me re-track what I've been trying to say here....
>
> My first query was to check with you guys if there was an admin API to
> trigger the reset-password email. Seems there is no such API. However,
> there is an admin API to just reset the password without email verification
> (
> http://keycloak.github.io/docs/rest-api/index.html#_set_up_a_temporary_password_for_the_user
> ).
>
> My follow-up concern was that since there is an admin API to trigger the
> verification email (
> http://keycloak.github.io/docs/rest-api/index.html#_send_an_email_verification_email_to_the_user),
> it would have been consistent if there was an admin API to send the
> reset-password email as well.
>
> Hope this clarifies the misunderstanding.
>
>
> Regards,
> Lohitha.
>
> On Tue, Feb 2, 2016 at 2:19 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Have no idea what you are saying.
>>
>> We don't have any API outside of the admin endpoints that do password
>> reset, register email or anything else like that. For the admin endpoints
>> we have a very flexibly endpoint that lets you send exactly what actions
>> you want.
>>
>> On 1 February 2016 at 19:00, Lohitha Chiranjeewa <kalc04 at gmail.com>
>> wrote:
>>
>>> Hi Stian,
>>>
>>> I was referring to a potential API endpoint which actually sends out the
>>> password reset email (there's a similar API which sends out the
>>> registration email), not the existing one which just resets the password.
>>>
>>>
>>> Regards,
>>> Lohitha.
>>>
>>> On Mon, Feb 1, 2016 at 3:53 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 28 January 2016 at 08:41, Lohitha Chiranjeewa <kalc04 at gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks Fabricio, will check on how we can proceed with such an
>>>>> implementation.
>>>>>
>>>>> Since there is an already existing registration-email API, I thought
>>>>> it's consistent from Keycloak's perspective to expose a reset-password API
>>>>> as well...
>>>>>
>>>>
>>>> Not sure what you refer to, but there are no APIs for these actions
>>>> outside of the admin endpoints.
>>>>
>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Lohitha.
>>>>>
>>>>> On Thu, Jan 28, 2016 at 2:31 AM, Fabricio Milone <
>>>>> fabricio.milone at shinetech.com> wrote:
>>>>>
>>>>>> Hi Lohitha,
>>>>>>
>>>>>> I had the same requirements (Direct grant + forgotten password) and
>>>>>> ended up implementing a SPI using some piece of code made by Pedro Igor.
>>>>>>
>>>>>> An extract of the DEV Mailing list called: "*Add custom REST paths?
>>>>>> New SPI?*"
>>>>>>
>>>>>> *It is part of a working in progress around fine-grained
>>>>>>> authorization [1].*
>>>>>>> *The new SPI changes [2] specific to Keycloak are located in a
>>>>>>> specific branch [3] in my Keycloak fork.*
>>>>>>
>>>>>>
>>>>>>> *I need to discuss these changes with Bill and see what he thinks
>>>>>>> about it. Depending on his feedback, I can prepare a PR and send these
>>>>>>> changes to upstream.*
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> *[1] https://github.com/pedroigor/keycloak-authz
>>>>>>> <https://github.com/pedroigor/keycloak-authz>*
>>>>>>> *[2]
>>>>>>> https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54
>>>>>>> <https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54>**[3]
>>>>>>> https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified
>>>>>>> <https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified>*
>>>>>>
>>>>>>
>>>>>>
>>>>>> Not sure if Keycloak will ever adopt those changes as official or
>>>>>> something similar though.
>>>>>>
>>>>>> That's a good starting point.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> On 27 January 2016 at 21:19, Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> There is in the admin endpoints, but nothing that's available to
>>>>>>> end-users.
>>>>>>>
>>>>>>> On 22 January 2016 at 06:45, Lohitha Chiranjeewa <kalc04 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> There are a few clients of ours who use the Direct Grants API to
>>>>>>>> authenticate their users. A requirement has come up to provide the Reset
>>>>>>>> Password flow to those clients. From what I've checked and gathered,
>>>>>>>> there's no REST API to initiate this flow (sending the Keycloak password
>>>>>>>> reset email + resetting the password through the UI); only way to do is
>>>>>>>> through the browser.
>>>>>>>>
>>>>>>>> If it's actually there somewhere, can someone point me to it?
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Lohitha.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Fabricio Milone*
>>>>>> Developer
>>>>>>
>>>>>> *Shine Consulting *
>>>>>>
>>>>>> 30/600 Bourke Street
>>>>>>
>>>>>> Melbourne VIC 3000
>>>>>>
>>>>>> T: 03 8488 9939
>>>>>>
>>>>>> M: 04 3200 4006
>>>>>>
>>>>>>
>>>>>> www.shinetech.com  *a* passion for excellence
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160203/08c3dce9/attachment-0001.html 

From pkkamos at gmail.com  Wed Feb  3 07:35:18 2016
From: pkkamos at gmail.com (PAA KOJO KONDUAH AMOS)
Date: Wed, 3 Feb 2016 12:35:18 +0000
Subject: [keycloak-user] KeyCloak Admin Client :
Message-ID: <56b1f3e1.8e811c0a.ca774.63f6@mx.google.com>

Hello, I have tried out KeyCloak Admin Client. In fact, I have done a standalone application which works nicely with KeyCloak Server.

What I don?t get is, when I port a similar thing into a web application context and deploy same on wildfly fly I keep getting the Exception below:

Caused by: javax.ws.rs.ProcessingException: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "access_token" (class org.keycloak.representations.AccessTokenResponse), not marked as ignorable (9 known properties: "notBeforePolicy", "otherClaims", "tokenType", "token", "expiresIn", "sessionState", "refreshExpiresIn", "idToken", "refreshToken"])


Any lead on how to resolve all these maven dependency issues?


Thanks.

Sent from Mail for Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160203/715dceb7/attachment.html 

From sthorger at redhat.com  Wed Feb  3 07:57:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 3 Feb 2016 13:57:41 +0100
Subject: [keycloak-user] KeyCloak Admin Client :
In-Reply-To: <56b1f3e1.8e811c0a.ca774.63f6@mx.google.com>
References: <56b1f3e1.8e811c0a.ca774.63f6@mx.google.com>
Message-ID: <CAJgngAenvjBL58avwONabohE_9oe-FWXqrdE5zwhHmvhi1p-ew@mail.gmail.com>

In the past the admin client required Jackson 1.x and didn't work with
Jackson 2.x. This is being fixed in 1.9.

To make it work you'll need to either wait for 1.9 or make your WAR use
Jackson instead of Jackson 2. Check out the admin client example as it
doesn't exactly that.

On 3 February 2016 at 13:35, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com>
wrote:

> Hello, I have tried out KeyCloak Admin Client. In fact, I have done a
> standalone application which works nicely with KeyCloak Server.
>
>
>
> What I don?t get is, when I port a similar thing into a web application
> context and deploy same on wildfly fly I keep getting the Exception below:
>
>
>
> *Caused by: javax.ws.rs.ProcessingException:
> com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException:
> Unrecognized field "access_token" (class
> org.keycloak.representations.AccessTokenResponse), not marked as ignorable
> (9 known properties: "notBeforePolicy", "otherClaims", "tokenType",
> "token", "expiresIn", "sessionState", "refreshExpiresIn", "idToken",
> "refreshToken"])*
>
>
>
>
>
> Any lead on how to resolve all these maven dependency issues?
>
>
>
>
>
> Thanks.
>
>
>
> Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> _______________________________________________
> 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/20160203/85c83cd1/attachment.html 

From pkkamos at gmail.com  Wed Feb  3 08:04:10 2016
From: pkkamos at gmail.com (pkkamos)
Date: Wed, 3 Feb 2016 13:04:10 +0000
Subject: [keycloak-user] KeyCloak Admin Client :
In-Reply-To: <CAJgngAenvjBL58avwONabohE_9oe-FWXqrdE5zwhHmvhi1p-ew@mail.gmail.com>
References: <56b1f3e1.8e811c0a.ca774.63f6@mx.google.com>
	<CAJgngAenvjBL58avwONabohE_9oe-FWXqrdE5zwhHmvhi1p-ew@mail.gmail.com>
Message-ID: <CAHS6aASufCccs8PXFPQN5A4kupd1yL7ojjnd9O08TCq_9tsCcg@mail.gmail.com>

Thanks a lot Stian. I will give that a try whiles i wait for 1.9.
On 3 Feb 2016 12:57, "Stian Thorgersen" <sthorger at redhat.com> wrote:

> In the past the admin client required Jackson 1.x and didn't work with
> Jackson 2.x. This is being fixed in 1.9.
>
> To make it work you'll need to either wait for 1.9 or make your WAR use
> Jackson instead of Jackson 2. Check out the admin client example as it
> doesn't exactly that.
>
> On 3 February 2016 at 13:35, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com>
> wrote:
>
>> Hello, I have tried out KeyCloak Admin Client. In fact, I have done a
>> standalone application which works nicely with KeyCloak Server.
>>
>>
>>
>> What I don?t get is, when I port a similar thing into a web application
>> context and deploy same on wildfly fly I keep getting the Exception below:
>>
>>
>>
>> *Caused by: javax.ws.rs.ProcessingException:
>> com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException:
>> Unrecognized field "access_token" (class
>> org.keycloak.representations.AccessTokenResponse), not marked as ignorable
>> (9 known properties: "notBeforePolicy", "otherClaims", "tokenType",
>> "token", "expiresIn", "sessionState", "refreshExpiresIn", "idToken",
>> "refreshToken"])*
>>
>>
>>
>>
>>
>> Any lead on how to resolve all these maven dependency issues?
>>
>>
>>
>>
>>
>> Thanks.
>>
>>
>>
>> Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>>
>> _______________________________________________
>> 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/20160203/25fcd67f/attachment.html 

From mposolda at redhat.com  Wed Feb  3 08:06:25 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 3 Feb 2016 14:06:25 +0100
Subject: [keycloak-user] No LDAP Group Attribute mapper in Keycloak?
In-Reply-To: <68E5BD0C-F36F-4476-A69E-F8200572A474@info.nl>
References: <68E5BD0C-F36F-4476-A69E-F8200572A474@info.nl>
Message-ID: <56B1FB51.9070004@redhat.com>

This is actually supported. If you look at LDAP Group mapper, you can 
see field "Mapped Group Attribues" . Here you can specify list of 
attributes, which will be mapped from LDAP group to Keycloak group and 
viceversa.

There is one limitation, that name of attribute needs to be same on both 
places (ie. you can map LDAP attribute "description" to Keycloak 
attribute "description" . But you can't map LDAP attribute "description" 
to Keycloak attribute "foo" ). Feel free to create JIRA if this is 
limiting you. I've actually go simple way, but it can be improved if 
there is additional demand.

Marek

On 02/02/16 17:45, Edgar Vonk - Info.nl wrote:
> Hi,
>
> If I am correct there is no LDAP Group Attribute mapper in Keycloak right? There is a User Attribute mapper and there is a Group Mapper but group attributes in LDAP cannot be synched to and from Keycloak at the moment?
>
> I guess it should not be too hard to write an LDAP Group Attribute mapper should we want to?
>
> cheers
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From RLewis at carbonite.com  Wed Feb  3 08:17:34 2016
From: RLewis at carbonite.com (Reed Lewis)
Date: Wed, 3 Feb 2016 13:17:34 +0000
Subject: [keycloak-user] User-Federation
In-Reply-To: <CADW1CM8kNr=WkTSm4jp_BZm4Bdm6JSJhSLgPvhLQxDSmrC653A@mail.gmail.com>
References: <CADW1CM8kNr=WkTSm4jp_BZm4Bdm6JSJhSLgPvhLQxDSmrC653A@mail.gmail.com>
Message-ID: <E4193CB0-4921-45BD-AA73-8BA39AF8D3C0@carbonite.com>

If you use the federation provider listed here:

[0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
[1]: https://github.com/Smartling/keycloak-user-migration-provider

You can specify a URL that will be called when a user needs to be validated.

There are three requests that need to be implemented in your sever.

GET <baseURL>/api/users/<username>/
If the user exists, it should return a 200 with a json object with the return type ?application/json? with the following fields:
username
email
emailVerified
firstName
lastName
roles [?user?]

If the user does not exist, return a 404

HEAD <baseURL>/api/users/<username>/
Always return 200

POST <baseURL>/api/users/<username>/
The password is posted to you in a json object.
Return 200 if the password is OK, 401 if not.  In both cases return no data.

I wrote a small python module which implements these methods which works quite well.

Reed

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Stuart Jacobs <stuart.jacobs at symbiotics.co.za<mailto:stuart.jacobs at symbiotics.co.za>>
Date: Wednesday, February 3, 2016 at 2:40 AM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: [keycloak-user] User-Federation

Hi Everyone,

I have an application that runs on a postgresql database, keycloak has been configured and has created all the required tables/columns in my schema using liquibase on start up of the keycloak server.

I need to authenticate users using the projects existing user table obtaining the username and password from this table.

I have had a look at the federation provider project under the example projects but this still eludes me as to how I change the keycloak mapping to use my own tables in postgress?

Can someone please point me in the right direction or if someone has implemented such a solution please share how you have done it?

Thanks everyone.

  Regards,
  Stuart Jacobs





[https://ci5.googleusercontent.com/proxy/3YryZCxSi_o_xtypjkc6GCt6zmosqqyhCc2hzF4xME0bLLsxYcQ3ZPjUtXEcbbLjxFi7e5GxX1dgk22OqzBZVxCbKSoTNqpS_Lz-GuFPz5FrTfeHGug2yGqIQdc=s0-d-e1-ft#http://symbiotics.co.za/website/image/ir.attachment/1578_e14aa73/datas]

www.symbiotics.co.za<http://www.symbiotics.co.za>
********************************************************************************
This email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited.

Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient.

********************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160203/cebe27b6/attachment-0001.html 

From leo.nunes at gjccorp.com.br  Wed Feb  3 08:27:09 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Wed, 3 Feb 2016 13:27:09 +0000
Subject: [keycloak-user] Obtain client name inside email-verification.ftl
Message-ID: <D2D7948C.25B10%leo.nunes@ojc.com.br>

Hi, I would like to know if there's a way to get the Client Name at the email-verification.ftl, I tried to use client.name but it didn't work.
How can I find the variables available to use at the email template?

<html>
<body>
${msg("emailVerificationBodyHtml",link, linkExpiration, realmName, client.name)}
</body>
</html>

--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160203/d05f000a/attachment.html 

From thomas.darimont at googlemail.com  Wed Feb  3 08:38:56 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 3 Feb 2016 14:38:56 +0100
Subject: [keycloak-user] Obtain client name inside email-verification.ftl
In-Reply-To: <D2D7948C.25B10%leo.nunes@ojc.com.br>
References: <D2D7948C.25B10%leo.nunes@ojc.com.br>
Message-ID: <CAK-7U1jWeHjSdX_1ULwiWgzTfE5g5xuaqjFrB=30YaKg9XoUhg@mail.gmail.com>

Hello Leonardo,

this was discussed a while ago:
http://lists.jboss.org/pipermail/keycloak-user/2016-January/004513.html
There is an issue for this in JIRA:
https://issues.jboss.org/browse/KEYCLOAK-2359

I created a prototypic fix for this here:
https://github.com/keycloak/keycloak/pull/2061
- but it was rejected after some discussion for the sake of taking another
route which has not been implemented yet.

Cheers,
Thomas


2016-02-03 14:27 GMT+01:00 LEONARDO NUNES <leo.nunes at gjccorp.com.br>:

> Hi, I would like to know if there's a way to get the Client Name at the
> email-verification.ftl, I tried to use client.name but it didn't work.
> How can I find the variables available to use at the email template?
>
> <html>
> <body>
> ${msg("emailVerificationBodyHtml",link, linkExpiration, realmName,
> client.name)}
> </body>
> </html>
>
> --
> Leonardo Nunes
> ------------------------------
>
>
> *Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem,
> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar
> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por
> engano, por favor avise imediatamente o remetente, respondendo o e-mail e
> em seguida apague-o. Agradecemos sua coopera??o. This message may contain
> confidential and/or privileged information. If you are not the addressee or
> authorized to receive this for the addressee, you must not use, copy,
> disclose or take any action based on this message or any information
> herein. If you have received this message in error, please advise the
> sender immediately by reply e-mail and delete this message. Thank you for
> your cooperation*
>
> _______________________________________________
> 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/20160203/0d32616f/attachment.html 

From Edgar at info.nl  Wed Feb  3 08:55:12 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Wed, 3 Feb 2016 13:55:12 +0000
Subject: [keycloak-user] No LDAP Group Attribute mapper in Keycloak?
In-Reply-To: <56B1FB51.9070004@redhat.com>
References: <68E5BD0C-F36F-4476-A69E-F8200572A474@info.nl>
	<56B1FB51.9070004@redhat.com>
Message-ID: <F5828F8C-3FB4-47F1-82FD-5F98781B39F5@info.nl>

Ah, you are right. Sorry, overlooked that completely. Seems fine for us at the moment. Thanks.

> On 03 Feb 2016, at 14:06, Marek Posolda <mposolda at redhat.com> wrote:
> 
> This is actually supported. If you look at LDAP Group mapper, you can see field "Mapped Group Attribues" . Here you can specify list of attributes, which will be mapped from LDAP group to Keycloak group and viceversa.
> 
> There is one limitation, that name of attribute needs to be same on both places (ie. you can map LDAP attribute "description" to Keycloak attribute "description" . But you can't map LDAP attribute "description" to Keycloak attribute "foo" ). Feel free to create JIRA if this is limiting you. I've actually go simple way, but it can be improved if there is additional demand.
> 
> Marek
> 
> On 02/02/16 17:45, Edgar Vonk - Info.nl wrote:
>> Hi,
>> 
>> If I am correct there is no LDAP Group Attribute mapper in Keycloak right? There is a User Attribute mapper and there is a Group Mapper but group attributes in LDAP cannot be synched to and from Keycloak at the moment?
>> 
>> I guess it should not be too hard to write an LDAP Group Attribute mapper should we want to?
>> 
>> cheers
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 



From Edgar at info.nl  Wed Feb  3 09:36:30 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Wed, 3 Feb 2016 14:36:30 +0000
Subject: [keycloak-user] No LDAP Group Attribute mapper in Keycloak?
In-Reply-To: <F5828F8C-3FB4-47F1-82FD-5F98781B39F5@info.nl>
References: <68E5BD0C-F36F-4476-A69E-F8200572A474@info.nl>
	<56B1FB51.9070004@redhat.com>
	<F5828F8C-3FB4-47F1-82FD-5F98781B39F5@info.nl>
Message-ID: <453B409F-828A-4A9A-99FC-074F568079ED@info.nl>

Hi Marek,

Somewhat related: we would like to have certain LDAP group attributes end up in the user?s JWT tokens as well so that we can use this data in our client.

The Group Membership Mapper places the name of the (LDAP) group in the token but what would we need to do to get group attributes in there as well? I guess we would then need to extend the Group Membership Mapper and add a mapping of group attributes there?

Or for now I guess we could use the Keycloak REST API from our client to retrieve all the group information for a user using the 'GET /admin/realms/{realm}/users/{id}/groups? endpoint.

cheers

> On 03 Feb 2016, at 14:55, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:
> 
> Ah, you are right. Sorry, overlooked that completely. Seems fine for us at the moment. Thanks.
> 
>> On 03 Feb 2016, at 14:06, Marek Posolda <mposolda at redhat.com> wrote:
>> 
>> This is actually supported. If you look at LDAP Group mapper, you can see field "Mapped Group Attribues" . Here you can specify list of attributes, which will be mapped from LDAP group to Keycloak group and viceversa.
>> 
>> There is one limitation, that name of attribute needs to be same on both places (ie. you can map LDAP attribute "description" to Keycloak attribute "description" . But you can't map LDAP attribute "description" to Keycloak attribute "foo" ). Feel free to create JIRA if this is limiting you. I've actually go simple way, but it can be improved if there is additional demand.
>> 
>> Marek
>> 
>> On 02/02/16 17:45, Edgar Vonk - Info.nl wrote:
>>> Hi,
>>> 
>>> If I am correct there is no LDAP Group Attribute mapper in Keycloak right? There is a User Attribute mapper and there is a Group Mapper but group attributes in LDAP cannot be synched to and from Keycloak at the moment?
>>> 
>>> I guess it should not be too hard to write an LDAP Group Attribute mapper should we want to?
>>> 
>>> cheers
>>> _______________________________________________
>>> 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 Feb  3 10:28:50 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 3 Feb 2016 16:28:50 +0100
Subject: [keycloak-user] No LDAP Group Attribute mapper in Keycloak?
In-Reply-To: <453B409F-828A-4A9A-99FC-074F568079ED@info.nl>
References: <68E5BD0C-F36F-4476-A69E-F8200572A474@info.nl>
	<56B1FB51.9070004@redhat.com>
	<F5828F8C-3FB4-47F1-82FD-5F98781B39F5@info.nl>
	<453B409F-828A-4A9A-99FC-074F568079ED@info.nl>
Message-ID: <56B21CB2.3070308@redhat.com>

You can do it with builtin Keycloak "User Attribute" protocol mapper. In 
admin console under clients (or client template if you want to reuse 
same mapper in more client applications), you can create this mapper.

If the mapped attribute is found on the user himself, it has precedence. 
Otherwise Keycloak will try to search all groups, which user is member 
of, and look for the attribute inside those groups (or respectively also 
their parent groups).

So if you have both Group LDAP mapper and this UserAttribute protocol 
mapper, you can map attributes of LDAP group to the JWT access token 
issued to user.

Marek


On 03/02/16 15:36, Edgar Vonk - Info.nl wrote:
> Hi Marek,
>
> Somewhat related: we would like to have certain LDAP group attributes end up in the user?s JWT tokens as well so that we can use this data in our client.
>
> The Group Membership Mapper places the name of the (LDAP) group in the token but what would we need to do to get group attributes in there as well? I guess we would then need to extend the Group Membership Mapper and add a mapping of group attributes there?
>
> Or for now I guess we could use the Keycloak REST API from our client to retrieve all the group information for a user using the 'GET /admin/realms/{realm}/users/{id}/groups? endpoint.
>
> cheers
>
>> On 03 Feb 2016, at 14:55, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:
>>
>> Ah, you are right. Sorry, overlooked that completely. Seems fine for us at the moment. Thanks.
>>
>>> On 03 Feb 2016, at 14:06, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>> This is actually supported. If you look at LDAP Group mapper, you can see field "Mapped Group Attribues" . Here you can specify list of attributes, which will be mapped from LDAP group to Keycloak group and viceversa.
>>>
>>> There is one limitation, that name of attribute needs to be same on both places (ie. you can map LDAP attribute "description" to Keycloak attribute "description" . But you can't map LDAP attribute "description" to Keycloak attribute "foo" ). Feel free to create JIRA if this is limiting you. I've actually go simple way, but it can be improved if there is additional demand.
>>>
>>> Marek
>>>
>>> On 02/02/16 17:45, Edgar Vonk - Info.nl wrote:
>>>> Hi,
>>>>
>>>> If I am correct there is no LDAP Group Attribute mapper in Keycloak right? There is a User Attribute mapper and there is a Group Mapper but group attributes in LDAP cannot be synched to and from Keycloak at the moment?
>>>>
>>>> I guess it should not be too hard to write an LDAP Group Attribute mapper should we want to?
>>>>
>>>> cheers
>>>> _______________________________________________
>>>> 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 guydavis.ca at gmail.com  Wed Feb  3 13:47:21 2016
From: guydavis.ca at gmail.com (Guy Davis)
Date: Wed, 3 Feb 2016 12:47:21 -0600
Subject: [keycloak-user] Course and Fine Grained Entitlements
In-Reply-To: <CAMu7Tor_E5_9k2jQBdYscHtX1FeHb7Jo0YdU1Yz-CsGt0DBaoA@mail.gmail.com>
References: <CAMu7Tor_E5_9k2jQBdYscHtX1FeHb7Jo0YdU1Yz-CsGt0DBaoA@mail.gmail.com>
Message-ID: <CAAgmn1oH+BpafB+YL9b=rEz3CeGxp9DLOOJf9_zVJB36F38SZg@mail.gmail.com>

Hi Lars,

Good question.  My organization is also asking similar questions about
adopting Keycloak.  Let me give my understanding as a user, then Keycloak
team can correct my misunderstandings.

Basically, Keycloak offers coarse-grained authorizations (realm-roles
<http://keycloak.github.io/docs/userguide/keycloak-server/html/per-realm-admin-permissions.html>
 and client-app roles
<http://keycloak.github.io/docs/userguide/keycloak-server/html/roles.html>)
assigned to users (or groups
<http://keycloak.github.io/docs/userguide/keycloak-server/html/groups.html>).
  So I understand Keycloak will let you grant user Bob the 'myapp-admin'
role.  However, it falls to the backend service or application to then map
that role to application-specific permissions.  For example, role
'myapp-admins' can access /myapp/project1/admin page.  This resource
security can be done (for Java apps) in declarative fashion using web.xml
security constraints.  Alternatively, your application code could
dynamically obtain the Keycloak user principal, check their roles, and map
into your app's permission scheme.

This understanding implies that your application is responsible for an
admin UI to map fine-grained permissions on your app's resources to
Keycloak roles.   If your app only has 'coarse-grained" resources, then you
can probably just use Keycloak roles, with no need for a permission layer
or the UI it entails.

Also, see this pre-amble about Permission Scopes
<http://keycloak.github.io/docs/userguide/keycloak-server/html/Overview.html#d4e65>.
In
future, it sounds like Keycloak team is considering support for the UMA
portion of the OAuth standard
<https://docs.kantarainitiative.org/uma/draft-uma-core.html>.  This may
help with fine-grained permission management within Keycloak itself?

Hope this helps,
Guy

<sorry, original response was only to Lars, now to list as well>

On Tue, Feb 2, 2016 at 8:29 PM, Lars Noldan <lars.noldan at drillinginfo.com>
wrote:

> We're in the investigation stage on moving from a $BigExpensiveVendor
> solution toward keycloak, and we're looking for a solution to help manage
> both Course and Fine grained entitlements.  Keycloak appears to be a
> fantastic authentication solution, but I'm wondering what are you, the
> keycloak community using to handle Authorization?
>
> Thanks!
>
> _______________________________________________
> 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/20160203/885bba2f/attachment.html 

From bburke at redhat.com  Wed Feb  3 14:03:22 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 3 Feb 2016 14:03:22 -0500
Subject: [keycloak-user] Course and Fine Grained Entitlements
In-Reply-To: <CAAgmn1oH+BpafB+YL9b=rEz3CeGxp9DLOOJf9_zVJB36F38SZg@mail.gmail.com>
References: <CAMu7Tor_E5_9k2jQBdYscHtX1FeHb7Jo0YdU1Yz-CsGt0DBaoA@mail.gmail.com>
	<CAAgmn1oH+BpafB+YL9b=rEz3CeGxp9DLOOJf9_zVJB36F38SZg@mail.gmail.com>
Message-ID: <56B24EFA.7050100@redhat.com>

Pedro is working on that...He has some stuff.  Hope he responds. Not 
going to be part of Keycloak until 2.0 though.  And yes, its around UMA.

On 2/3/2016 1:47 PM, Guy Davis wrote:
> Hi Lars,
>
> Good question.  My organization is also asking similar questions about 
> adopting Keycloak.  Let me give my understanding as a user, then 
> Keycloak team can correct my misunderstandings.
>
> Basically, Keycloak offers coarse-grained authorizations (realm-roles 
> <http://keycloak.github.io/docs/userguide/keycloak-server/html/per-realm-admin-permissions.html> and client-app 
> roles 
> <http://keycloak.github.io/docs/userguide/keycloak-server/html/roles.html>) 
> assigned to users (or groups 
> <http://keycloak.github.io/docs/userguide/keycloak-server/html/groups.html>). 
>   So I understand Keycloak will let you grant user Bob the 
> 'myapp-admin' role.  However, it falls to the backend service or 
> application to then map that role to application-specific 
> permissions.  For example, role 'myapp-admins' can access 
> /myapp/project1/admin page.  This resource security can be done (for 
> Java apps) in declarative fashion using web.xml security constraints.  
> Alternatively, your application code could dynamically obtain the 
> Keycloak user principal, check their roles, and map into your app's 
> permission scheme.
>
> This understanding implies that your application is responsible for an 
> admin UI to map fine-grained permissions on your app's resources to 
> Keycloak roles.   If your app only has 'coarse-grained" resources, 
> then you can probably just use Keycloak roles, with no need for a 
> permission layer or the UI it entails.
>
> Also, see this pre-amble about Permission Scopes 
> <http://keycloak.github.io/docs/userguide/keycloak-server/html/Overview.html#d4e65>. In 
> future, it sounds like Keycloak team is considering support for the 
> UMA portion of the OAuth standard 
> <https://docs.kantarainitiative.org/uma/draft-uma-core.html>.  This 
> may help with fine-grained permission management within Keycloak itself?
>
> Hope this helps,
> Guy
>
> <sorry, original response was only to Lars, now to list as well>
>
> On Tue, Feb 2, 2016 at 8:29 PM, Lars Noldan 
> <lars.noldan at drillinginfo.com <mailto:lars.noldan at drillinginfo.com>> 
> wrote:
>
>     We're in the investigation stage on moving from a
>     $BigExpensiveVendor solution toward keycloak, and we're looking
>     for a solution to help manage both Course and Fine grained
>     entitlements.  Keycloak appears to be a fantastic authentication
>     solution, but I'm wondering what are you, the keycloak community
>     using to handle Authorization?
>
>     Thanks!
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160203/6ccb06bc/attachment.html 

From malmi.suh at gmail.com  Wed Feb  3 21:45:45 2016
From: malmi.suh at gmail.com (Malmi Samarasinghe)
Date: Thu, 4 Feb 2016 08:15:45 +0530
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
Message-ID: <CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>

Hi Bill,

We tried the above fix on top of 1.7.0 by applying the changes from the
commits attached to the https://issues.jboss.org/browse/KEYCLOAK-2327 and
deployed, and it seems to have the same issue. If you have any
further update on this please let us know.

Regards,
Malmi

On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> This could be related to https://issues.jboss.org/browse/KEYCLOAK-2327.
>
> It's already fixed in master, so if you can try it out that would be
> great. We should also have a 1.8.1.Final release this week with the fix in
> as well.
>
> On 30 January 2016 at 05:16, Malmi Samarasinghe <malmi.suh at gmail.com>
> wrote:
>
>> Hi Bill,
>>
>> We are using keycloak 1.7.0 and rdbms (mysql)
>>
>> Regards,
>> Malmi Samarasinghe
>> On Jan 29, 2016 7:41 PM, "Bill Burke" <bburke at redhat.com> wrote:
>>
>>> Which version of keycloak?  RDBMS or Mongo?
>>>
>>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>>
>>> Hi Everyone,
>>>
>>> In my application we create retrieve and assign role subsequently and it
>>> seems that even for a small load (2-3 threads) with realm cache enabled
>>> option, assign realm role call fails due to role not exist error and 404 is
>>> returned from keycloak.
>>>
>>> With the realm cache disabled option the load works fine.
>>>
>>> Please get back to me if you have any information on any other option we
>>> can follow to get this issue sorted or on what action the realm cache will
>>> be persisted to DB.
>>>
>>> Regards,
>>> Malmi
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://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/20160204/ea9652fd/attachment-0001.html 

From bburke at redhat.com  Wed Feb  3 22:27:25 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 3 Feb 2016 22:27:25 -0500
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
Message-ID: <56B2C51D.3010800@redhat.com>

Ok, I can try and reproduce this if you give me an idea of what exactly 
you are doing?  Are you creating a user too? or assigning role to an 
existing user?

1. fetch user
2. create role
3. assign role

Do this in a bunch of threads at same time?

On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
> Hi Bill,
>
> We tried the above fix on top of 1.7.0 by applying the changes from 
> the commits attached to the 
> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and it 
> seems to have the same issue. If you have any further update on this 
> please let us know.
>
> Regards,
> Malmi
>
> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     This could be related to
>     https://issues.jboss.org/browse/KEYCLOAK-2327.
>
>     It's already fixed in master, so if you can try it out that would
>     be great. We should also have a 1.8.1.Final release this week with
>     the fix in as well.
>
>     On 30 January 2016 at 05:16, Malmi Samarasinghe
>     <malmi.suh at gmail.com <mailto:malmi.suh at gmail.com>> wrote:
>
>         Hi Bill,
>
>         We are using keycloak 1.7.0 and rdbms (mysql)
>
>         Regards,
>         Malmi Samarasinghe
>
>         On Jan 29, 2016 7:41 PM, "Bill Burke" <bburke at redhat.com
>         <mailto:bburke at redhat.com>> wrote:
>
>             Which version of keycloak?  RDBMS or Mongo?
>
>             On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>             Hi Everyone,
>>
>>             In my application we create retrieve and assign role
>>             subsequently and it seems that even for a small load (2-3
>>             threads) with realm cache enabled option, assign realm
>>             role call fails due to role not exist error and 404 is
>>             returned from keycloak.
>>
>>             With the realm cache disabled option the load works fine.
>>
>>             Please get back to me if you have any information on any
>>             other option we can follow to get this issue sorted or on
>>             what action the realm cache will be persisted to DB.
>>
>>             Regards,
>>             Malmi
>>
>>
>>             _______________________________________________
>>             keycloak-user mailing list
>>             keycloak-user at lists.jboss.org
>>             <mailto:keycloak-user at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>             -- 
>             Bill Burke
>             JBoss, a division of Red Hat
>             http://bill.burkecentral.com
>
>
>             _______________________________________________
>             keycloak-user mailing list
>             keycloak-user at lists.jboss.org
>             <mailto:keycloak-user at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>         _______________________________________________
>         keycloak-user mailing list
>         keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160203/8d572d3f/attachment.html 

From bburke at redhat.com  Wed Feb  3 22:30:29 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 3 Feb 2016 22:30:29 -0500
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
Message-ID: <56B2C5D5.8050702@redhat.com>

Can you give me what REST invocations you are doing? How do you find the 
role?  How do you create the role? etc...

On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
> Hi Bill,
>
> We tried the above fix on top of 1.7.0 by applying the changes from 
> the commits attached to the 
> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and it 
> seems to have the same issue. If you have any further update on this 
> please let us know.
>
> Regards,
> Malmi
>
> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     This could be related to
>     https://issues.jboss.org/browse/KEYCLOAK-2327.
>
>     It's already fixed in master, so if you can try it out that would
>     be great. We should also have a 1.8.1.Final release this week with
>     the fix in as well.
>
>     On 30 January 2016 at 05:16, Malmi Samarasinghe
>     <malmi.suh at gmail.com <mailto:malmi.suh at gmail.com>> wrote:
>
>         Hi Bill,
>
>         We are using keycloak 1.7.0 and rdbms (mysql)
>
>         Regards,
>         Malmi Samarasinghe
>
>         On Jan 29, 2016 7:41 PM, "Bill Burke" <bburke at redhat.com
>         <mailto:bburke at redhat.com>> wrote:
>
>             Which version of keycloak?  RDBMS or Mongo?
>
>             On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>             Hi Everyone,
>>
>>             In my application we create retrieve and assign role
>>             subsequently and it seems that even for a small load (2-3
>>             threads) with realm cache enabled option, assign realm
>>             role call fails due to role not exist error and 404 is
>>             returned from keycloak.
>>
>>             With the realm cache disabled option the load works fine.
>>
>>             Please get back to me if you have any information on any
>>             other option we can follow to get this issue sorted or on
>>             what action the realm cache will be persisted to DB.
>>
>>             Regards,
>>             Malmi
>>
>>
>>             _______________________________________________
>>             keycloak-user mailing list
>>             keycloak-user at lists.jboss.org
>>             <mailto:keycloak-user at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>             -- 
>             Bill Burke
>             JBoss, a division of Red Hat
>             http://bill.burkecentral.com
>
>
>             _______________________________________________
>             keycloak-user mailing list
>             keycloak-user at lists.jboss.org
>             <mailto:keycloak-user at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>         _______________________________________________
>         keycloak-user mailing list
>         keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160203/65e2d2de/attachment.html 

From beny.moser at gmail.com  Thu Feb  4 05:09:55 2016
From: beny.moser at gmail.com (Benjamin Moser)
Date: Thu, 4 Feb 2016 11:09:55 +0100
Subject: [keycloak-user] spring-security-adapter on wildfly: How?
In-Reply-To: <CAFZbuCMBOjWcpEwFhSS=fS3srUZPOT3tert0qrRJRx1Oczn5Zg@mail.gmail.com>
References: <CAFZbuCMBOjWcpEwFhSS=fS3srUZPOT3tert0qrRJRx1Oczn5Zg@mail.gmail.com>
Message-ID: <CAEt_YbdugdezbDD1Vup=UEHKxQ1w1nF-1G3HRwX0oLLmB8UO+w@mail.gmail.com>

Hi Andrey

Thank you for your response.
This fixed my problem.

Best regards
Ben

2016-02-02 12:17 GMT+01:00 Andrey Saroul <andrey.saroul at gmail.com>:

> I had the same issue.
> I missed the spring security initializer and so springSecurityFilterChain
> was not registered.
> I added this class in my app, and then all security worked just fine
>
> public class SecurityWebApplicationInitializer
>         extends AbstractSecurityWebApplicationInitializer {
> }
>
> And by the way, no web.xml required at all if you use annotation config.
>
> _______________________________________________
> 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/20160204/4089cd42/attachment-0001.html 

From srinivas.nangunoori at hpe.com  Thu Feb  4 05:24:35 2016
From: srinivas.nangunoori at hpe.com (Nangunoori, Srinivas)
Date: Thu, 4 Feb 2016 10:24:35 +0000
Subject: [keycloak-user] Size of keyclaok_access_token
Message-ID: <8FD052C8E2EC9B40B07B148AF2E1E77A3A00CF97@G9W0755.americas.hpqcorp.net>

Hi,

We are seeing some strange behavior with access token size. Some keycloak servers are generating with 1308 character size and some others are generating with 2055 character size.
May I know what would be the correct size?
Environment details,
Server Version : 1.6.1.Final
Current working directory: /opt/jboss
Java Version: 1.7.0_85
Java Vendor: Oracle Corporation
Java Runtime: OpenJDK Runtime Environment
Java VM: OpenJDK 64-Bit Server VM
Java VM Version: 24.85-b03
Java Home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64/jre
System Encoding: ANSI_X3.4-1968
Operating System: Linux 3.10.0-123.9.3.el7.x86_64
OS Architecture: amd64


Regards,
Srinivas N
HPE, Bengaluru

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160204/e9b75d3e/attachment.html 

From sthorger at redhat.com  Thu Feb  4 05:57:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 4 Feb 2016 11:57:21 +0100
Subject: [keycloak-user] Size of keyclaok_access_token
In-Reply-To: <8FD052C8E2EC9B40B07B148AF2E1E77A3A00CF97@G9W0755.americas.hpqcorp.net>
References: <8FD052C8E2EC9B40B07B148AF2E1E77A3A00CF97@G9W0755.americas.hpqcorp.net>
Message-ID: <CAJgngAfGWsRstfQn-1S5tnv_CxVye5tpqwdj3hEvLuty_8Bi7Q@mail.gmail.com>

Size of the token depends on what goes into it. What roles, scope you have
for users/clients as well as what mappers you have.

On 4 February 2016 at 11:24, Nangunoori, Srinivas <
srinivas.nangunoori at hpe.com> wrote:

> Hi,
>
>
>
> We are seeing some strange behavior with access token size. Some keycloak
> servers are generating with 1308 character size and some others are
> generating with 2055 character size.
>
> May I know what would be the correct size?
>
> Environment details,
>
> Server Version : 1.6.1.Final
>
> Current working directory: /opt/jboss
>
> Java Version: 1.7.0_85
>
> Java Vendor: Oracle Corporation
>
> Java Runtime: OpenJDK Runtime Environment
>
> Java VM: OpenJDK 64-Bit Server VM
>
> Java VM Version: 24.85-b03
>
> Java Home:
> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64/jre
>
> System Encoding: ANSI_X3.4-1968
>
> Operating System: Linux 3.10.0-123.9.3.el7.x86_64
>
> OS Architecture: amd64
>
>
>
>
>
> Regards,
>
> Srinivas N
>
> HPE, Bengaluru
>
>
>
> _______________________________________________
> 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/20160204/fc7727af/attachment.html 

From parul.com at gmail.com  Thu Feb  4 06:20:30 2016
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Thu, 4 Feb 2016 16:50:30 +0530
Subject: [keycloak-user] Does keycloak SAML sp support encryption?
Message-ID: <CAFj68vX_q2ynfUnp-xLEtvRB6gfpMBHHjLdsWTAkMJA5fi1JwQ@mail.gmail.com>

I have enabled encryption on keycloak-saml file.. However i dont see any
encryption happened on SAML request.. Similarly. When idp sends encrypted
response, keycloak sp couldn't handle and throwing null pointer exception..
Is it a defect?.. M using HTTP POST binding..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160204/e7ee73a0/attachment.html 

From malmi.suh at gmail.com  Thu Feb  4 06:31:28 2016
From: malmi.suh at gmail.com (Malmi Samarasinghe)
Date: Thu, 4 Feb 2016 17:01:28 +0530
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <56B2C5D5.8050702@redhat.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
	<56B2C5D5.8050702@redhat.com>
Message-ID: <CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>

Hi Bill,

Please find the work flow that we have implemented
create user : POST : admin/realms/{realm}/users

*Method1* wrapps the following API calls
Create Realm role : POST : admin/realms/{realm}/roles
Retrieve Role : GET : admin/realms/{realm}/roles/{roleName}
Assign Role : POST : admin/realms/leapset/users/{0}/role-mappings/realm

Same for the client roles as well.

*Method1 *is executed in multiple threads and assign reams role API starts
failing with 404 (keycloak log states role not found)

Regards,
Malmi

On Thu, Feb 4, 2016 at 9:00 AM, Bill Burke <bburke at redhat.com> wrote:

> Can you give me what REST invocations you are doing? How do you find the
> role?  How do you create the role? etc...
>
> On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
>
> Hi Bill,
>
> We tried the above fix on top of 1.7.0 by applying the changes from the
> commits attached to the  <https://issues.jboss.org/browse/KEYCLOAK-2327>
> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and it seems
> to have the same issue. If you have any further update on this please let
> us know.
>
> Regards,
> Malmi
>
> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> This could be related to  <https://issues.jboss.org/browse/KEYCLOAK-2327>
>> https://issues.jboss.org/browse/KEYCLOAK-2327.
>>
>> It's already fixed in master, so if you can try it out that would be
>> great. We should also have a 1.8.1.Final release this week with the fix in
>> as well.
>>
>> On 30 January 2016 at 05:16, Malmi Samarasinghe < <malmi.suh at gmail.com>
>> malmi.suh at gmail.com> wrote:
>>
>>> Hi Bill,
>>>
>>> We are using keycloak 1.7.0 and rdbms (mysql)
>>>
>>> Regards,
>>> Malmi Samarasinghe
>>> On Jan 29, 2016 7:41 PM, "Bill Burke" < <bburke at redhat.com>
>>> bburke at redhat.com> wrote:
>>>
>>>> Which version of keycloak?  RDBMS or Mongo?
>>>>
>>>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>>>
>>>> Hi Everyone,
>>>>
>>>> In my application we create retrieve and assign role subsequently and
>>>> it seems that even for a small load (2-3 threads) with realm cache enabled
>>>> option, assign realm role call fails due to role not exist error and 404 is
>>>> returned from keycloak.
>>>>
>>>> With the realm cache disabled option the load works fine.
>>>>
>>>> Please get back to me if you have any information on any other option
>>>> we can follow to get this issue sorted or on what action the realm cache
>>>> will be persisted to DB.
>>>>
>>>> Regards,
>>>> Malmi
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hathttp://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
>>>
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160204/6fa8493d/attachment-0001.html 

From sthorger at redhat.com  Thu Feb  4 06:53:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 4 Feb 2016 12:53:41 +0100
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
	<56B2C5D5.8050702@redhat.com>
	<CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>
Message-ID: <CAJgngAd_t-hE3y1itAZ6rBHfT7ZNh+rm7T6zqeJWT5MjZSs87A@mail.gmail.com>

When you say method1 is executed in multiple threads, do you mean one
thread creates the role and another retrieves it? Or do you have multiple
threads creating different roles?

On 4 February 2016 at 12:31, Malmi Samarasinghe <malmi.suh at gmail.com> wrote:

> Hi Bill,
>
> Please find the work flow that we have implemented
> create user : POST : admin/realms/{realm}/users
>
> *Method1* wrapps the following API calls
> Create Realm role : POST : admin/realms/{realm}/roles
> Retrieve Role : GET : admin/realms/{realm}/roles/{roleName}
> Assign Role : POST : admin/realms/leapset/users/{0}/role-mappings/realm
>
> Same for the client roles as well.
>
> *Method1 *is executed in multiple threads and assign reams role API
> starts failing with 404 (keycloak log states role not found)
>
> Regards,
> Malmi
>
> On Thu, Feb 4, 2016 at 9:00 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> Can you give me what REST invocations you are doing? How do you find the
>> role?  How do you create the role? etc...
>>
>> On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
>>
>> Hi Bill,
>>
>> We tried the above fix on top of 1.7.0 by applying the changes from the
>> commits attached to the  <https://issues.jboss.org/browse/KEYCLOAK-2327>
>> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and it seems
>> to have the same issue. If you have any further update on this please let
>> us know.
>>
>> Regards,
>> Malmi
>>
>> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> This could be related to
>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>> https://issues.jboss.org/browse/KEYCLOAK-2327.
>>>
>>> It's already fixed in master, so if you can try it out that would be
>>> great. We should also have a 1.8.1.Final release this week with the fix in
>>> as well.
>>>
>>> On 30 January 2016 at 05:16, Malmi Samarasinghe < <malmi.suh at gmail.com>
>>> malmi.suh at gmail.com> wrote:
>>>
>>>> Hi Bill,
>>>>
>>>> We are using keycloak 1.7.0 and rdbms (mysql)
>>>>
>>>> Regards,
>>>> Malmi Samarasinghe
>>>> On Jan 29, 2016 7:41 PM, "Bill Burke" < <bburke at redhat.com>
>>>> bburke at redhat.com> wrote:
>>>>
>>>>> Which version of keycloak?  RDBMS or Mongo?
>>>>>
>>>>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> In my application we create retrieve and assign role subsequently and
>>>>> it seems that even for a small load (2-3 threads) with realm cache enabled
>>>>> option, assign realm role call fails due to role not exist error and 404 is
>>>>> returned from keycloak.
>>>>>
>>>>> With the realm cache disabled option the load works fine.
>>>>>
>>>>> Please get back to me if you have any information on any other option
>>>>> we can follow to get this issue sorted or on what action the realm cache
>>>>> will be persisted to DB.
>>>>>
>>>>> Regards,
>>>>> Malmi
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hathttp://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
>>>>
>>>
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160204/654be7d0/attachment.html 

From malmi.suh at gmail.com  Thu Feb  4 10:08:49 2016
From: malmi.suh at gmail.com (Malmi Samarasinghe)
Date: Thu, 4 Feb 2016 20:38:49 +0530
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAJgngAd_t-hE3y1itAZ6rBHfT7ZNh+rm7T6zqeJWT5MjZSs87A@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
	<56B2C5D5.8050702@redhat.com>
	<CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>
	<CAJgngAd_t-hE3y1itAZ6rBHfT7ZNh+rm7T6zqeJWT5MjZSs87A@mail.gmail.com>
Message-ID: <CAL_Nbcn46D9b_ttV6jUkSxt5Msc4bMNeXCNmsuBxCA2PRCoDVQ@mail.gmail.com>

Hi Stian

I have multiple threads creating different roles. Basically one thread will
execute all three apis one after another.

Regards,
Malmi

On Thu, Feb 4, 2016 at 5:23 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> When you say method1 is executed in multiple threads, do you mean one
> thread creates the role and another retrieves it? Or do you have multiple
> threads creating different roles?
>
> On 4 February 2016 at 12:31, Malmi Samarasinghe <malmi.suh at gmail.com>
> wrote:
>
>> Hi Bill,
>>
>> Please find the work flow that we have implemented
>> create user : POST : admin/realms/{realm}/users
>>
>> *Method1* wrapps the following API calls
>> Create Realm role : POST : admin/realms/{realm}/roles
>> Retrieve Role : GET : admin/realms/{realm}/roles/{roleName}
>> Assign Role : POST : admin/realms/leapset/users/{0}/role-mappings/realm
>>
>> Same for the client roles as well.
>>
>> *Method1 *is executed in multiple threads and assign reams role API
>> starts failing with 404 (keycloak log states role not found)
>>
>> Regards,
>> Malmi
>>
>> On Thu, Feb 4, 2016 at 9:00 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>>> Can you give me what REST invocations you are doing? How do you find the
>>> role?  How do you create the role? etc...
>>>
>>> On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
>>>
>>> Hi Bill,
>>>
>>> We tried the above fix on top of 1.7.0 by applying the changes from the
>>> commits attached to the  <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and it
>>> seems to have the same issue. If you have any further update on this please
>>> let us know.
>>>
>>> Regards,
>>> Malmi
>>>
>>> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> This could be related to
>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>> https://issues.jboss.org/browse/KEYCLOAK-2327.
>>>>
>>>> It's already fixed in master, so if you can try it out that would be
>>>> great. We should also have a 1.8.1.Final release this week with the fix in
>>>> as well.
>>>>
>>>> On 30 January 2016 at 05:16, Malmi Samarasinghe < <malmi.suh at gmail.com>
>>>> malmi.suh at gmail.com> wrote:
>>>>
>>>>> Hi Bill,
>>>>>
>>>>> We are using keycloak 1.7.0 and rdbms (mysql)
>>>>>
>>>>> Regards,
>>>>> Malmi Samarasinghe
>>>>> On Jan 29, 2016 7:41 PM, "Bill Burke" < <bburke at redhat.com>
>>>>> bburke at redhat.com> wrote:
>>>>>
>>>>>> Which version of keycloak?  RDBMS or Mongo?
>>>>>>
>>>>>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>>>>>
>>>>>> Hi Everyone,
>>>>>>
>>>>>> In my application we create retrieve and assign role subsequently and
>>>>>> it seems that even for a small load (2-3 threads) with realm cache enabled
>>>>>> option, assign realm role call fails due to role not exist error and 404 is
>>>>>> returned from keycloak.
>>>>>>
>>>>>> With the realm cache disabled option the load works fine.
>>>>>>
>>>>>> Please get back to me if you have any information on any other option
>>>>>> we can follow to get this issue sorted or on what action the realm cache
>>>>>> will be persisted to DB.
>>>>>>
>>>>>> Regards,
>>>>>> Malmi
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> JBoss, a division of Red Hathttp://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
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160204/f7f3697c/attachment-0001.html 

From sthorger at redhat.com  Thu Feb  4 10:12:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 4 Feb 2016 16:12:27 +0100
Subject: [keycloak-user] Keycloak 1.8.1.Final and 1.9.0.CR1 released
Message-ID: <CAJgngAf2+_pk70inBAdeasK=qwu05zbbFRa0CWTMZuzfaf8wyg@mail.gmail.com>

Today we have two releases. As 1.8.0.Final was released before WildFly 10
Final was available, we decided to release 1.8.1.Final which is now built
on top of WildFly 10 Final.

The bigger release today is 1.9.0.CR1, this release contains a large number
of bug fixes and improvements, but no major new features.

For the full list of issues resolved check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.0.CR1>
and
to download the release go to the Keycloak homepage
<http://keycloak.org/downloads>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160204/8e2e8f1e/attachment.html 

From m.hayen at first8.nl  Thu Feb  4 10:50:01 2016
From: m.hayen at first8.nl (Mark Hayen)
Date: Thu, 4 Feb 2016 16:50:01 +0100
Subject: [keycloak-user] invalid code errormessage
Message-ID: <56B37329.4060909@first8.nl>

Hi all,

We have a problem with the link in the reset password email.
Sometimes, but not always we get an error saying invalid code.
This is the log entry:

type=RESET_PASSWORD_ERROR, realmId=master, clientId=null, userId=null, 
ipAddress=xxx.xxx.xxx.xxx, error=invalid_code

Has anybody seen this error too?
Is it maybe fixed in a newer version? We are running keycloak 1.4.0.Final.

Thank you

Mark Hayen
First8

From malmi.suh at gmail.com  Fri Feb  5 00:53:55 2016
From: malmi.suh at gmail.com (Malmi Samarasinghe)
Date: Fri, 5 Feb 2016 11:23:55 +0530
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAL_Nbcn46D9b_ttV6jUkSxt5Msc4bMNeXCNmsuBxCA2PRCoDVQ@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
	<56B2C5D5.8050702@redhat.com>
	<CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>
	<CAJgngAd_t-hE3y1itAZ6rBHfT7ZNh+rm7T6zqeJWT5MjZSs87A@mail.gmail.com>
	<CAL_Nbcn46D9b_ttV6jUkSxt5Msc4bMNeXCNmsuBxCA2PRCoDVQ@mail.gmail.com>
Message-ID: <CAL_NbcmKYy7Du=tfMAuMS_pGNySQ=EDrtbdejw41e0_W8E8_YA@mail.gmail.com>

Hi Stian/Bill,

I just wanted to highlight that this issue only occurred when realm cache
enabled option is ON.

Regards,
Malmi

On Thu, Feb 4, 2016 at 8:38 PM, Malmi Samarasinghe <malmi.suh at gmail.com>
wrote:

> Hi Stian
>
> I have multiple threads creating different roles. Basically one thread
> will execute all three apis one after another.
>
> Regards,
> Malmi
>
> On Thu, Feb 4, 2016 at 5:23 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> When you say method1 is executed in multiple threads, do you mean one
>> thread creates the role and another retrieves it? Or do you have multiple
>> threads creating different roles?
>>
>> On 4 February 2016 at 12:31, Malmi Samarasinghe <malmi.suh at gmail.com>
>> wrote:
>>
>>> Hi Bill,
>>>
>>> Please find the work flow that we have implemented
>>> create user : POST : admin/realms/{realm}/users
>>>
>>> *Method1* wrapps the following API calls
>>> Create Realm role : POST : admin/realms/{realm}/roles
>>> Retrieve Role : GET : admin/realms/{realm}/roles/{roleName}
>>> Assign Role : POST : admin/realms/leapset/users/{0}/role-mappings/realm
>>>
>>> Same for the client roles as well.
>>>
>>> *Method1 *is executed in multiple threads and assign reams role API
>>> starts failing with 404 (keycloak log states role not found)
>>>
>>> Regards,
>>> Malmi
>>>
>>> On Thu, Feb 4, 2016 at 9:00 AM, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> Can you give me what REST invocations you are doing? How do you find
>>>> the role?  How do you create the role? etc...
>>>>
>>>> On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
>>>>
>>>> Hi Bill,
>>>>
>>>> We tried the above fix on top of 1.7.0 by applying the changes from the
>>>> commits attached to the
>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and it
>>>> seems to have the same issue. If you have any further update on this please
>>>> let us know.
>>>>
>>>> Regards,
>>>> Malmi
>>>>
>>>> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> This could be related to
>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327.
>>>>>
>>>>> It's already fixed in master, so if you can try it out that would be
>>>>> great. We should also have a 1.8.1.Final release this week with the fix in
>>>>> as well.
>>>>>
>>>>> On 30 January 2016 at 05:16, Malmi Samarasinghe <
>>>>> <malmi.suh at gmail.com>malmi.suh at gmail.com> wrote:
>>>>>
>>>>>> Hi Bill,
>>>>>>
>>>>>> We are using keycloak 1.7.0 and rdbms (mysql)
>>>>>>
>>>>>> Regards,
>>>>>> Malmi Samarasinghe
>>>>>> On Jan 29, 2016 7:41 PM, "Bill Burke" < <bburke at redhat.com>
>>>>>> bburke at redhat.com> wrote:
>>>>>>
>>>>>>> Which version of keycloak?  RDBMS or Mongo?
>>>>>>>
>>>>>>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>>>>>>
>>>>>>> Hi Everyone,
>>>>>>>
>>>>>>> In my application we create retrieve and assign role subsequently
>>>>>>> and it seems that even for a small load (2-3 threads) with realm cache
>>>>>>> enabled option, assign realm role call fails due to role not exist error
>>>>>>> and 404 is returned from keycloak.
>>>>>>>
>>>>>>> With the realm cache disabled option the load works fine.
>>>>>>>
>>>>>>> Please get back to me if you have any information on any other
>>>>>>> option we can follow to get this issue sorted or on what action the realm
>>>>>>> cache will be persisted to DB.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Malmi
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Bill Burke
>>>>>>> JBoss, a division of Red Hathttp://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
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/9ae1882f/attachment.html 

From anujgargcse at gmail.com  Fri Feb  5 01:02:02 2016
From: anujgargcse at gmail.com (Anuj Garg)
Date: Fri, 5 Feb 2016 11:32:02 +0530
Subject: [keycloak-user] turning on Direct Grant API in keycloak 1.8.0.CR1
Message-ID: <CAA2tMp_oW44YqWtruu1ve=vgOD72zv+ya1nZ1FQVe4XENjkqDA@mail.gmail.com>

Can't find where is the option to turn on Direct Grant API  in keycloack
1.8.0.CR

it was written somewhere "switch in the admin console under
Settings->General, specifically the "Direct Grant API" switch."
But cant find this in admin console.

I know It is not good to use it but i need to
Please tell how to turn it on or it have been removed from this release?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/c8b42b0e/attachment-0001.html 

From pkkamos at gmail.com  Fri Feb  5 02:16:26 2016
From: pkkamos at gmail.com (PAA KOJO KONDUAH AMOS)
Date: Fri, 5 Feb 2016 07:16:26 +0000
Subject: [keycloak-user] KeyCloak Admin Client : DEALING WITH [Unrecognized
 field "access_token" (class
 org.keycloak.representations.AccessTokenResponse)] ISSUE.
In-Reply-To: <CAJgngAenvjBL58avwONabohE_9oe-FWXqrdE5zwhHmvhi1p-ew@mail.gmail.com>
References: <56b1f3e1.8e811c0a.ca774.63f6@mx.google.com>
	<CAJgngAenvjBL58avwONabohE_9oe-FWXqrdE5zwhHmvhi1p-ew@mail.gmail.com>
Message-ID: <56b44c26.42711c0a.25efd.4c16@mx.google.com>

Hello Stian, I am very happy to share that, Keycloak admin-client 1.9.0.CR1 is working for me. I will like to share 2 things I have done to get it woking in a web context.

1. Dependency definition:

                <dependency>
			<groupId>org.keycloak</groupId>
			<artifactId>keycloak-admin-client</artifactId>
			<version>1.9.0.CR1</version>
		</dependency>

2. created a jboss-deployment-structure.xml file, placed it in my WEB-INF folder ,with the following content(This ensures Jackson2 is used)[Credit: https://docs.jboss.org/resteasy/docs/3.0.2.Final/userguide/html/json.html, 21.4. Using Jackson 2.2.x Inside of JBoss AS7]:
                 <jboss-deployment-structure>
	                       <deployment>
		                  <exclusions>

			          <module name="org.jboss.resteasy.resteasy-jackson-provider" />
		               </exclusions>
		             <dependencies>
			       <module name="org.jboss.resteasy.resteasy-jackson2-provider"
				    services="import" />
		            </dependencies>
	                  </deployment>
                 </jboss-deployment-structure>                       


Sent from Mail for Windows 10

From: Stian Thorgersen
Sent: Wednesday, February 3, 2016 12:57 PM
To: PAA KOJO KONDUAH AMOS
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] KeyCloak Admin Client :

In the past the admin client required Jackson 1.x and didn't work with Jackson 2.x. This is being fixed in 1.9.

To make it work you'll need to either wait for 1.9 or make your WAR use Jackson instead of Jackson 2. Check out the admin client example as it doesn't exactly that.

On 3 February 2016 at 13:35, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com> wrote:
Hello, I have tried out KeyCloak Admin Client. In fact, I have done a standalone application which works nicely with KeyCloak Server.
?
What I don?t get is, when I port a similar thing into a web application context and deploy same on wildfly fly I keep getting the Exception below:
?
Caused by: javax.ws.rs.ProcessingException: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "access_token" (class org.keycloak.representations.AccessTokenResponse), not marked as ignorable (9 known properties: "notBeforePolicy", "otherClaims", "tokenType", "token", "expiresIn", "sessionState", "refreshExpiresIn", "idToken", "refreshToken"])
?
?
Any lead on how to resolve all these maven dependency issues?
?
?
Thanks.
?
Sent from Mail for Windows 10
?

_______________________________________________
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/20160205/9515de6b/attachment.html 

From sthorger at redhat.com  Fri Feb  5 03:41:22 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 09:41:22 +0100
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAL_NbcmKYy7Du=tfMAuMS_pGNySQ=EDrtbdejw41e0_W8E8_YA@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
	<56B2C5D5.8050702@redhat.com>
	<CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>
	<CAJgngAd_t-hE3y1itAZ6rBHfT7ZNh+rm7T6zqeJWT5MjZSs87A@mail.gmail.com>
	<CAL_Nbcn46D9b_ttV6jUkSxt5Msc4bMNeXCNmsuBxCA2PRCoDVQ@mail.gmail.com>
	<CAL_NbcmKYy7Du=tfMAuMS_pGNySQ=EDrtbdejw41e0_W8E8_YA@mail.gmail.com>
Message-ID: <CAJgngAcf4RtoS__nf4KtpRBQ0DCWnOWhkECiaLhgK7ioWMq01Q@mail.gmail.com>

Confirmed this bug https://issues.jboss.org/browse/KEYCLOAK-2458

On 5 February 2016 at 06:53, Malmi Samarasinghe <malmi.suh at gmail.com> wrote:

> Hi Stian/Bill,
>
> I just wanted to highlight that this issue only occurred when realm cache
> enabled option is ON.
>
> Regards,
> Malmi
>
> On Thu, Feb 4, 2016 at 8:38 PM, Malmi Samarasinghe <malmi.suh at gmail.com>
> wrote:
>
>> Hi Stian
>>
>> I have multiple threads creating different roles. Basically one thread
>> will execute all three apis one after another.
>>
>> Regards,
>> Malmi
>>
>> On Thu, Feb 4, 2016 at 5:23 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> When you say method1 is executed in multiple threads, do you mean one
>>> thread creates the role and another retrieves it? Or do you have multiple
>>> threads creating different roles?
>>>
>>> On 4 February 2016 at 12:31, Malmi Samarasinghe <malmi.suh at gmail.com>
>>> wrote:
>>>
>>>> Hi Bill,
>>>>
>>>> Please find the work flow that we have implemented
>>>> create user : POST : admin/realms/{realm}/users
>>>>
>>>> *Method1* wrapps the following API calls
>>>> Create Realm role : POST : admin/realms/{realm}/roles
>>>> Retrieve Role : GET : admin/realms/{realm}/roles/{roleName}
>>>> Assign Role : POST : admin/realms/leapset/users/{0}/role-mappings/realm
>>>>
>>>> Same for the client roles as well.
>>>>
>>>> *Method1 *is executed in multiple threads and assign reams role API
>>>> starts failing with 404 (keycloak log states role not found)
>>>>
>>>> Regards,
>>>> Malmi
>>>>
>>>> On Thu, Feb 4, 2016 at 9:00 AM, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>>> Can you give me what REST invocations you are doing? How do you find
>>>>> the role?  How do you create the role? etc...
>>>>>
>>>>> On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
>>>>>
>>>>> Hi Bill,
>>>>>
>>>>> We tried the above fix on top of 1.7.0 by applying the changes from
>>>>> the commits attached to the
>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and it
>>>>> seems to have the same issue. If you have any further update on this please
>>>>> let us know.
>>>>>
>>>>> Regards,
>>>>> Malmi
>>>>>
>>>>> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> This could be related to
>>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327.
>>>>>>
>>>>>> It's already fixed in master, so if you can try it out that would be
>>>>>> great. We should also have a 1.8.1.Final release this week with the fix in
>>>>>> as well.
>>>>>>
>>>>>> On 30 January 2016 at 05:16, Malmi Samarasinghe <
>>>>>> <malmi.suh at gmail.com>malmi.suh at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Bill,
>>>>>>>
>>>>>>> We are using keycloak 1.7.0 and rdbms (mysql)
>>>>>>>
>>>>>>> Regards,
>>>>>>> Malmi Samarasinghe
>>>>>>> On Jan 29, 2016 7:41 PM, "Bill Burke" < <bburke at redhat.com>
>>>>>>> bburke at redhat.com> wrote:
>>>>>>>
>>>>>>>> Which version of keycloak?  RDBMS or Mongo?
>>>>>>>>
>>>>>>>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>>>>>>>
>>>>>>>> Hi Everyone,
>>>>>>>>
>>>>>>>> In my application we create retrieve and assign role subsequently
>>>>>>>> and it seems that even for a small load (2-3 threads) with realm cache
>>>>>>>> enabled option, assign realm role call fails due to role not exist error
>>>>>>>> and 404 is returned from keycloak.
>>>>>>>>
>>>>>>>> With the realm cache disabled option the load works fine.
>>>>>>>>
>>>>>>>> Please get back to me if you have any information on any other
>>>>>>>> option we can follow to get this issue sorted or on what action the realm
>>>>>>>> cache will be persisted to DB.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Malmi
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Bill Burke
>>>>>>>> JBoss, a division of Red Hathttp://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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/e42ed525/attachment-0001.html 

From malmi.suh at gmail.com  Fri Feb  5 03:57:20 2016
From: malmi.suh at gmail.com (Malmi Samarasinghe)
Date: Fri, 5 Feb 2016 14:27:20 +0530
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAJgngAcf4RtoS__nf4KtpRBQ0DCWnOWhkECiaLhgK7ioWMq01Q@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
	<56B2C5D5.8050702@redhat.com>
	<CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>
	<CAJgngAd_t-hE3y1itAZ6rBHfT7ZNh+rm7T6zqeJWT5MjZSs87A@mail.gmail.com>
	<CAL_Nbcn46D9b_ttV6jUkSxt5Msc4bMNeXCNmsuBxCA2PRCoDVQ@mail.gmail.com>
	<CAL_NbcmKYy7Du=tfMAuMS_pGNySQ=EDrtbdejw41e0_W8E8_YA@mail.gmail.com>
	<CAJgngAcf4RtoS__nf4KtpRBQ0DCWnOWhkECiaLhgK7ioWMq01Q@mail.gmail.com>
Message-ID: <CAL_Nbcnt8tdruqK3=+RzX+E5RjqJiT_vQfixGgLrVAvQDa2_VQ@mail.gmail.com>

Hi Stian,

We have this in production is there any intermediary fix that we can do or
any workaround?

Regards,
Malmi

On Fri, Feb 5, 2016 at 2:11 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Confirmed this bug https://issues.jboss.org/browse/KEYCLOAK-2458
>
> On 5 February 2016 at 06:53, Malmi Samarasinghe <malmi.suh at gmail.com>
> wrote:
>
>> Hi Stian/Bill,
>>
>> I just wanted to highlight that this issue only occurred when realm cache
>> enabled option is ON.
>>
>> Regards,
>> Malmi
>>
>> On Thu, Feb 4, 2016 at 8:38 PM, Malmi Samarasinghe <malmi.suh at gmail.com>
>> wrote:
>>
>>> Hi Stian
>>>
>>> I have multiple threads creating different roles. Basically one thread
>>> will execute all three apis one after another.
>>>
>>> Regards,
>>> Malmi
>>>
>>> On Thu, Feb 4, 2016 at 5:23 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> When you say method1 is executed in multiple threads, do you mean one
>>>> thread creates the role and another retrieves it? Or do you have multiple
>>>> threads creating different roles?
>>>>
>>>> On 4 February 2016 at 12:31, Malmi Samarasinghe <malmi.suh at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Bill,
>>>>>
>>>>> Please find the work flow that we have implemented
>>>>> create user : POST : admin/realms/{realm}/users
>>>>>
>>>>> *Method1* wrapps the following API calls
>>>>> Create Realm role : POST : admin/realms/{realm}/roles
>>>>> Retrieve Role : GET : admin/realms/{realm}/roles/{roleName}
>>>>> Assign Role : POST : admin/realms/leapset/users/{0}/role-mappings/realm
>>>>>
>>>>> Same for the client roles as well.
>>>>>
>>>>> *Method1 *is executed in multiple threads and assign reams role API
>>>>> starts failing with 404 (keycloak log states role not found)
>>>>>
>>>>> Regards,
>>>>> Malmi
>>>>>
>>>>> On Thu, Feb 4, 2016 at 9:00 AM, Bill Burke <bburke at redhat.com> wrote:
>>>>>
>>>>>> Can you give me what REST invocations you are doing? How do you find
>>>>>> the role?  How do you create the role? etc...
>>>>>>
>>>>>> On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
>>>>>>
>>>>>> Hi Bill,
>>>>>>
>>>>>> We tried the above fix on top of 1.7.0 by applying the changes from
>>>>>> the commits attached to the
>>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and it
>>>>>> seems to have the same issue. If you have any further update on this please
>>>>>> let us know.
>>>>>>
>>>>>> Regards,
>>>>>> Malmi
>>>>>>
>>>>>> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <sthorger at redhat.com
>>>>>> > wrote:
>>>>>>
>>>>>>> This could be related to
>>>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327.
>>>>>>>
>>>>>>> It's already fixed in master, so if you can try it out that would be
>>>>>>> great. We should also have a 1.8.1.Final release this week with the fix in
>>>>>>> as well.
>>>>>>>
>>>>>>> On 30 January 2016 at 05:16, Malmi Samarasinghe <
>>>>>>> <malmi.suh at gmail.com>malmi.suh at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Bill,
>>>>>>>>
>>>>>>>> We are using keycloak 1.7.0 and rdbms (mysql)
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Malmi Samarasinghe
>>>>>>>> On Jan 29, 2016 7:41 PM, "Bill Burke" < <bburke at redhat.com>
>>>>>>>> bburke at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Which version of keycloak?  RDBMS or Mongo?
>>>>>>>>>
>>>>>>>>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>>>>>>>>
>>>>>>>>> Hi Everyone,
>>>>>>>>>
>>>>>>>>> In my application we create retrieve and assign role subsequently
>>>>>>>>> and it seems that even for a small load (2-3 threads) with realm cache
>>>>>>>>> enabled option, assign realm role call fails due to role not exist error
>>>>>>>>> and 404 is returned from keycloak.
>>>>>>>>>
>>>>>>>>> With the realm cache disabled option the load works fine.
>>>>>>>>>
>>>>>>>>> Please get back to me if you have any information on any other
>>>>>>>>> option we can follow to get this issue sorted or on what action the realm
>>>>>>>>> cache will be persisted to DB.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Malmi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Bill Burke
>>>>>>>>> JBoss, a division of Red Hathttp://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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/9c9fe43e/attachment.html 

From srinivas.nangunoori at hpe.com  Fri Feb  5 04:27:03 2016
From: srinivas.nangunoori at hpe.com (Nangunoori, Srinivas)
Date: Fri, 5 Feb 2016 09:27:03 +0000
Subject: [keycloak-user] Size of keyclaok_access_token
In-Reply-To: <CAJgngAfGWsRstfQn-1S5tnv_CxVye5tpqwdj3hEvLuty_8Bi7Q@mail.gmail.com>
References: <8FD052C8E2EC9B40B07B148AF2E1E77A3A00CF97@G9W0755.americas.hpqcorp.net>
	<CAJgngAfGWsRstfQn-1S5tnv_CxVye5tpqwdj3hEvLuty_8Bi7Q@mail.gmail.com>
Message-ID: <8FD052C8E2EC9B40B07B148AF2E1E77A3A00D388@G9W0755.americas.hpqcorp.net>

Thanks for the info. Stian.
Can we configure size of access_token? If yes, how we can do that.


From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: Thursday, February 04, 2016 4:27 PM
To: Nangunoori, Srinivas
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Size of keyclaok_access_token

Size of the token depends on what goes into it. What roles, scope you have for users/clients as well as what mappers you have.

On 4 February 2016 at 11:24, Nangunoori, Srinivas <srinivas.nangunoori at hpe.com<mailto:srinivas.nangunoori at hpe.com>> wrote:
Hi,

We are seeing some strange behavior with access token size. Some keycloak servers are generating with 1308 character size and some others are generating with 2055 character size.
May I know what would be the correct size?
Environment details,
Server Version : 1.6.1.Final
Current working directory: /opt/jboss
Java Version: 1.7.0_85
Java Vendor: Oracle Corporation
Java Runtime: OpenJDK Runtime Environment
Java VM: OpenJDK 64-Bit Server VM
Java VM Version: 24.85-b03
Java Home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64/jre
System Encoding: ANSI_X3.4-1968
Operating System: Linux 3.10.0-123.9.3.el7.x86_64
OS Architecture: amd64


Regards,
Srinivas N
HPE, Bengaluru


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/60189658/attachment-0001.html 

From sthorger at redhat.com  Fri Feb  5 04:31:58 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 10:31:58 +0100
Subject: [keycloak-user] Size of keyclaok_access_token
In-Reply-To: <8FD052C8E2EC9B40B07B148AF2E1E77A3A00D388@G9W0755.americas.hpqcorp.net>
References: <8FD052C8E2EC9B40B07B148AF2E1E77A3A00CF97@G9W0755.americas.hpqcorp.net>
	<CAJgngAfGWsRstfQn-1S5tnv_CxVye5tpqwdj3hEvLuty_8Bi7Q@mail.gmail.com>
	<8FD052C8E2EC9B40B07B148AF2E1E77A3A00D388@G9W0755.americas.hpqcorp.net>
Message-ID: <CAJgngAdQYGmGRiH0zCj5e7noBm_00-qO8pQG_w7q8mnZcVY50Q@mail.gmail.com>

You can configure what goes into the token. There are two things you can do
to reduce the size:

* Set the scope of your client to only include the roles the client requires
* Configure mappers for the client to control what other properties are
included in the token

On 5 February 2016 at 10:27, Nangunoori, Srinivas <
srinivas.nangunoori at hpe.com> wrote:

> Thanks for the info. Stian.
>
> Can we configure size of access_token? If yes, how we can do that.
>
>
>
>
>
> *From:* Stian Thorgersen [mailto:sthorger at redhat.com]
> *Sent:* Thursday, February 04, 2016 4:27 PM
> *To:* Nangunoori, Srinivas
> *Cc:* keycloak-user at lists.jboss.org
> *Subject:* Re: [keycloak-user] Size of keyclaok_access_token
>
>
>
> Size of the token depends on what goes into it. What roles, scope you have
> for users/clients as well as what mappers you have.
>
>
>
> On 4 February 2016 at 11:24, Nangunoori, Srinivas <
> srinivas.nangunoori at hpe.com> wrote:
>
> Hi,
>
>
>
> We are seeing some strange behavior with access token size. Some keycloak
> servers are generating with 1308 character size and some others are
> generating with 2055 character size.
>
> May I know what would be the correct size?
>
> Environment details,
>
> Server Version : 1.6.1.Final
>
> Current working directory: /opt/jboss
>
> Java Version: 1.7.0_85
>
> Java Vendor: Oracle Corporation
>
> Java Runtime: OpenJDK Runtime Environment
>
> Java VM: OpenJDK 64-Bit Server VM
>
> Java VM Version: 24.85-b03
>
> Java Home:
> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64/jre
>
> System Encoding: ANSI_X3.4-1968
>
> Operating System: Linux 3.10.0-123.9.3.el7.x86_64
>
> OS Architecture: amd64
>
>
>
>
>
> Regards,
>
> Srinivas N
>
> HPE, Bengaluru
>
>
>
>
> _______________________________________________
> 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/20160205/a07ee618/attachment.html 

From pkkamos at gmail.com  Fri Feb  5 04:41:57 2016
From: pkkamos at gmail.com (PAA KOJO KONDUAH AMOS)
Date: Fri, 5 Feb 2016 09:41:57 +0000
Subject: [keycloak-user] Retrieving Logged In User Information.
Message-ID: <56b46e3f.6507c20a.91457.7eff@mx.google.com>

Hello, I am trying to retrieve information about the User logged into the webapp via keycloak. I have seen around information on using the following;

@SecurityDomain("keycloak")

@Context
SecurityContext sc;

And 
KeycloakPrincipal principal = (KeycloakPrincipal) sc.getUserPrincipal();



But the above line is returning a NullPointerException.

I must say, I have already done the required configuration; as in enabling the Keycloak Subsystem within my app server's server configuration:?standalone.xml.
Please any lead on how to retrieve the logged in User via KeyCloak?


Sent from Mail for Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/20e6f2fd/attachment.html 

From sthorger at redhat.com  Fri Feb  5 04:46:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 10:46:45 +0100
Subject: [keycloak-user] turning on Direct Grant API in keycloak
	1.8.0.CR1
In-Reply-To: <CAA2tMp_oW44YqWtruu1ve=vgOD72zv+ya1nZ1FQVe4XENjkqDA@mail.gmail.com>
References: <CAA2tMp_oW44YqWtruu1ve=vgOD72zv+ya1nZ1FQVe4XENjkqDA@mail.gmail.com>
Message-ID: <CAJgngAcFXv_KVJ7qCeNUHvysrj86FxLTH5NdMmkODVhayeEuGA@mail.gmail.com>

We remove the option to enable/disable direct grant on the realm level a
long time ago. Instead you can control this on a per-client basis.

On 5 February 2016 at 07:02, Anuj Garg <anujgargcse at gmail.com> wrote:

> Can't find where is the option to turn on Direct Grant API  in keycloack
> 1.8.0.CR
>
> it was written somewhere "switch in the admin console under
> Settings->General, specifically the "Direct Grant API" switch."
> But cant find this in admin console.
>
> I know It is not good to use it but i need to
> Please tell how to turn it on or it have been removed from this release?
>
> _______________________________________________
> 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/20160205/b1864b43/attachment.html 

From sthorger at redhat.com  Fri Feb  5 04:50:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 10:50:04 +0100
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAL_Nbcnt8tdruqK3=+RzX+E5RjqJiT_vQfixGgLrVAvQDa2_VQ@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
	<56B2C5D5.8050702@redhat.com>
	<CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>
	<CAJgngAd_t-hE3y1itAZ6rBHfT7ZNh+rm7T6zqeJWT5MjZSs87A@mail.gmail.com>
	<CAL_Nbcn46D9b_ttV6jUkSxt5Msc4bMNeXCNmsuBxCA2PRCoDVQ@mail.gmail.com>
	<CAL_NbcmKYy7Du=tfMAuMS_pGNySQ=EDrtbdejw41e0_W8E8_YA@mail.gmail.com>
	<CAJgngAcf4RtoS__nf4KtpRBQ0DCWnOWhkECiaLhgK7ioWMq01Q@mail.gmail.com>
	<CAL_Nbcnt8tdruqK3=+RzX+E5RjqJiT_vQfixGgLrVAvQDa2_VQ@mail.gmail.com>
Message-ID: <CAJgngAffrAE1+P315PHAoF2stOnDdKV=kRAcA-1rFHAMvEKo1w@mail.gmail.com>

Either don't create roles concurrently or disable cache.

How frequently are you creating roles? Just wondering because if you do it
will significantly impact the benefits of the cache as we invalidate a
large amount of the cache when roles are added/removed.

The problem you are seeing is most likely down to a race condition when the
realm role list (or client role lists) are re-loaded after they are
invalidated. I haven't had much time to look at it yet, so I don't know the
exact cause or a solution.

On 5 February 2016 at 09:57, Malmi Samarasinghe <malmi.suh at gmail.com> wrote:

> Hi Stian,
>
> We have this in production is there any intermediary fix that we can do or
> any workaround?
>
> Regards,
> Malmi
>
> On Fri, Feb 5, 2016 at 2:11 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Confirmed this bug https://issues.jboss.org/browse/KEYCLOAK-2458
>>
>> On 5 February 2016 at 06:53, Malmi Samarasinghe <malmi.suh at gmail.com>
>> wrote:
>>
>>> Hi Stian/Bill,
>>>
>>> I just wanted to highlight that this issue only occurred when realm
>>> cache enabled option is ON.
>>>
>>> Regards,
>>> Malmi
>>>
>>> On Thu, Feb 4, 2016 at 8:38 PM, Malmi Samarasinghe <malmi.suh at gmail.com>
>>> wrote:
>>>
>>>> Hi Stian
>>>>
>>>> I have multiple threads creating different roles. Basically one thread
>>>> will execute all three apis one after another.
>>>>
>>>> Regards,
>>>> Malmi
>>>>
>>>> On Thu, Feb 4, 2016 at 5:23 PM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> When you say method1 is executed in multiple threads, do you mean one
>>>>> thread creates the role and another retrieves it? Or do you have multiple
>>>>> threads creating different roles?
>>>>>
>>>>> On 4 February 2016 at 12:31, Malmi Samarasinghe <malmi.suh at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Bill,
>>>>>>
>>>>>> Please find the work flow that we have implemented
>>>>>> create user : POST : admin/realms/{realm}/users
>>>>>>
>>>>>> *Method1* wrapps the following API calls
>>>>>> Create Realm role : POST : admin/realms/{realm}/roles
>>>>>> Retrieve Role : GET : admin/realms/{realm}/roles/{roleName}
>>>>>> Assign Role : POST :
>>>>>> admin/realms/leapset/users/{0}/role-mappings/realm
>>>>>>
>>>>>> Same for the client roles as well.
>>>>>>
>>>>>> *Method1 *is executed in multiple threads and assign reams role API
>>>>>> starts failing with 404 (keycloak log states role not found)
>>>>>>
>>>>>> Regards,
>>>>>> Malmi
>>>>>>
>>>>>> On Thu, Feb 4, 2016 at 9:00 AM, Bill Burke <bburke at redhat.com> wrote:
>>>>>>
>>>>>>> Can you give me what REST invocations you are doing? How do you find
>>>>>>> the role?  How do you create the role? etc...
>>>>>>>
>>>>>>> On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
>>>>>>>
>>>>>>> Hi Bill,
>>>>>>>
>>>>>>> We tried the above fix on top of 1.7.0 by applying the changes from
>>>>>>> the commits attached to the
>>>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and it
>>>>>>> seems to have the same issue. If you have any further update on this please
>>>>>>> let us know.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Malmi
>>>>>>>
>>>>>>> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <
>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>> This could be related to
>>>>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327.
>>>>>>>>
>>>>>>>> It's already fixed in master, so if you can try it out that would
>>>>>>>> be great. We should also have a 1.8.1.Final release this week with the fix
>>>>>>>> in as well.
>>>>>>>>
>>>>>>>> On 30 January 2016 at 05:16, Malmi Samarasinghe <
>>>>>>>> <malmi.suh at gmail.com>malmi.suh at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Bill,
>>>>>>>>>
>>>>>>>>> We are using keycloak 1.7.0 and rdbms (mysql)
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Malmi Samarasinghe
>>>>>>>>> On Jan 29, 2016 7:41 PM, "Bill Burke" < <bburke at redhat.com>
>>>>>>>>> bburke at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Which version of keycloak?  RDBMS or Mongo?
>>>>>>>>>>
>>>>>>>>>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Everyone,
>>>>>>>>>>
>>>>>>>>>> In my application we create retrieve and assign role subsequently
>>>>>>>>>> and it seems that even for a small load (2-3 threads) with realm cache
>>>>>>>>>> enabled option, assign realm role call fails due to role not exist error
>>>>>>>>>> and 404 is returned from keycloak.
>>>>>>>>>>
>>>>>>>>>> With the realm cache disabled option the load works fine.
>>>>>>>>>>
>>>>>>>>>> Please get back to me if you have any information on any other
>>>>>>>>>> option we can follow to get this issue sorted or on what action the realm
>>>>>>>>>> cache will be persisted to DB.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Malmi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Bill Burke
>>>>>>>>>> JBoss, a division of Red Hathttp://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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Bill Burke
>>>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/2b9b0406/attachment-0001.html 

From porfyrios.vasileiou at gmail.com  Fri Feb  5 04:52:28 2016
From: porfyrios.vasileiou at gmail.com (Porfyrios Vasileiou)
Date: Fri, 5 Feb 2016 11:52:28 +0200
Subject: [keycloak-user] Keycloak saml v1.1 to oauth2 token
Message-ID: <CAHa5F_sYXAiYBhrwPyrDSAh-zhtVe0GR+sKEXw7kZDuD-CxXOg@mail.gmail.com>

Hello, I have a project that includes 2 client applications.

In ONLY ONE of the clients(web application in angular) users login via a
3rd party authorization server that also has a login procedure where the
user logs in and it returns an saml v1.1 xml token and then they can access
the client. (This procedure cannot be changed) But i want this client to
also be secured with keycloak so i can have a token that i can pass to my
rest services that are also secured with keycloak.

Can i convert this saml v1.1 token to oauth2 via keycloak?

Once we have logged in I want to login this user to keycloak
programmatically and get an oauth2 token instead that can be used for the
rest services requests in the  Bearer authentication header. How can i do
this?

I also want to say that the keycloak is setup to use the same active
directory that the 3rd party authorization server is using to authenticate
the users.

Is this possible?

Thanks, Porfyrios
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/fd8a8c3d/attachment.html 

From sthorger at redhat.com  Fri Feb  5 04:53:59 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 10:53:59 +0100
Subject: [keycloak-user] Retrieving Logged In User Information.
In-Reply-To: <56b46e3f.6507c20a.91457.7eff@mx.google.com>
References: <56b46e3f.6507c20a.91457.7eff@mx.google.com>
Message-ID: <CAJgngAfg=CnVYnmGzuVWQyo1yPofEqE_C0M+os3_fcL=9_Oitw@mail.gmail.com>

Did you actually add @SecurityDomain("keycloak")?

Does the request require authentication (does it have a security-constraint
in web.xml)?

On 5 February 2016 at 10:41, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com>
wrote:

> Hello, I am trying to retrieve information about the User logged into the
> webapp via keycloak. I have seen around information on using the following;
>
>
>
> *@SecurityDomain("keycloak")*
>
>
>
> *@Context*
>
> *SecurityContext** sc**;*
>
>
>
> And
>
> *KeycloakPrincipal principal = (KeycloakPrincipal) sc.getUserPrincipal();*
>
>
>
>
>
>
>
> *But the above line is returning a NullPointerException**.*
>
>
>
> I must say, I have already done the required configuration; as in enabling
> the Keycloak Subsystem within my app server's server configuration:
> standalone.xml.
>
> Please any lead on how to retrieve the logged in User via KeyCloak?
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> _______________________________________________
> 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/20160205/e37f0469/attachment.html 

From pkkamos at gmail.com  Fri Feb  5 04:57:33 2016
From: pkkamos at gmail.com (pkkamos)
Date: Fri, 5 Feb 2016 09:57:33 +0000
Subject: [keycloak-user] Retrieving Logged In User Information.
In-Reply-To: <CAJgngAfg=CnVYnmGzuVWQyo1yPofEqE_C0M+os3_fcL=9_Oitw@mail.gmail.com>
References: <56b46e3f.6507c20a.91457.7eff@mx.google.com>
	<CAJgngAfg=CnVYnmGzuVWQyo1yPofEqE_C0M+os3_fcL=9_Oitw@mail.gmail.com>
Message-ID: <CAHS6aAQ1u8qczEYjLiMRDDCqZ6+Nc1jXK8u_POHPGTbEOcU=0w@mail.gmail.com>

Yes to both questions.
On 5 Feb 2016 09:53, "Stian Thorgersen" <sthorger at redhat.com> wrote:

> Did you actually add @SecurityDomain("keycloak")?
>
> Does the request require authentication (does it have a
> security-constraint in web.xml)?
>
> On 5 February 2016 at 10:41, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com>
> wrote:
>
>> Hello, I am trying to retrieve information about the User logged into the
>> webapp via keycloak. I have seen around information on using the following;
>>
>>
>>
>> *@SecurityDomain("keycloak")*
>>
>>
>>
>> *@Context*
>>
>> *SecurityContext** sc**;*
>>
>>
>>
>> And
>>
>> *KeycloakPrincipal principal = (KeycloakPrincipal) sc.getUserPrincipal();*
>>
>>
>>
>>
>>
>>
>>
>> *But the above line is returning a NullPointerException**.*
>>
>>
>>
>> I must say, I have already done the required configuration; as in enabling
>> the Keycloak Subsystem within my app server's server configuration:
>> standalone.xml.
>>
>> Please any lead on how to retrieve the logged in User via KeyCloak?
>>
>>
>>
>>
>>
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>> Windows 10
>>
>>
>>
>> _______________________________________________
>> 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/20160205/9452a245/attachment.html 

From manfred.duchrow at caprica.biz  Fri Feb  5 05:17:03 2016
From: manfred.duchrow at caprica.biz (manfred.duchrow at caprica.biz)
Date: Fri, 5 Feb 2016 11:17:03 +0100
Subject: [keycloak-user] access_token always contains JWT
Message-ID: <56B4769F.8080603@caprica.biz>

Hi,

I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
service account by
POST /auth/realms/myrealm/protocol/openid-connect/token
with grant_type=client_credentials.

The result contains a signed JWT as value of field "access_token" rather
than a simple token
as described in chapter 18 (Service Accounts) of the user guide.

So what I expect (need) is a response like this:

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":60,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "refresh_expires_in":600,
    "id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "not-before-policy":0,
    "session-state":"234234-234234-234234"
}

Is there a way to configure the account or the realm to return a simple
token
in "access_token" (and "refresh_token") rather than a JWT?

Cheers,
  Manfred


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/f1cf06c6/attachment.html 

From pkkamos at gmail.com  Fri Feb  5 05:29:14 2016
From: pkkamos at gmail.com (PAA KOJO KONDUAH AMOS)
Date: Fri, 5 Feb 2016 10:29:14 +0000
Subject: [keycloak-user] Retrieving Logged In User Information.
In-Reply-To: <CAJgngAfg=CnVYnmGzuVWQyo1yPofEqE_C0M+os3_fcL=9_Oitw@mail.gmail.com>
References: <56b46e3f.6507c20a.91457.7eff@mx.google.com>
	<CAJgngAfg=CnVYnmGzuVWQyo1yPofEqE_C0M+os3_fcL=9_Oitw@mail.gmail.com>
Message-ID: <56b47956.9447620a.f3b5a.2e92@mx.google.com>

Hello Stian, my reponse in blue below.

Did you actually add?@SecurityDomain("keycloak")?

YES.

Does the request require authentication (does it have a security-constraint in web.xml)??


YES; The request say http://ip:port/context/index.html will be routed to Keycloak for the rquester to login. On successful log-in the requester is redirected back to the index.html. It is at this point I want to retrieve or know who the User is.


Sent from Mail for Windows 10

From: Stian Thorgersen
Sent: Friday, February 5, 2016 9:53 AM
To: PAA KOJO KONDUAH AMOS
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Retrieving Logged In User Information.

Did you actually add?@SecurityDomain("keycloak")?

Does the request require authentication (does it have a security-constraint in web.xml)??

On 5 February 2016 at 10:41, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com> wrote:
Hello, I am trying to retrieve information about the User logged into the webapp via keycloak. I have seen around information on using the following;
?
@SecurityDomain("keycloak")
?
@Context
SecurityContext sc;
?
And 
KeycloakPrincipal principal = (KeycloakPrincipal) sc.getUserPrincipal();
?
?
?
But the above line is returning a NullPointerException.
?
I must say, I have already done the required configuration; as in enabling the Keycloak Subsystem within my app server's server configuration:?standalone.xml.
Please any lead on how to retrieve the logged in User via KeyCloak?
?
?
Sent from Mail for Windows 10
?

_______________________________________________
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/20160205/86cb2f2a/attachment-0001.html 

From Tero.Ahonen at cybercom.com  Fri Feb  5 05:37:31 2016
From: Tero.Ahonen at cybercom.com (Tero Ahonen)
Date: Fri, 5 Feb 2016 10:37:31 +0000
Subject: [keycloak-user] Retrieving Logged In User Information.
In-Reply-To: <56b47956.9447620a.f3b5a.2e92@mx.google.com>
References: <56b46e3f.6507c20a.91457.7eff@mx.google.com>
	<CAJgngAfg=CnVYnmGzuVWQyo1yPofEqE_C0M+os3_fcL=9_Oitw@mail.gmail.com>
	<56b47956.9447620a.f3b5a.2e92@mx.google.com>
Message-ID: <B992199E-9ADF-473D-9658-5901028ED32F@cybercom.com>

Hi,

Do u have auth-contraint in web.xml?

<auth-constraint>
  <role-name>somerolehere</role-name>
</auth-constraint>

If there is not required role then no auth is needed.

.t

On 05 Feb 2016, at 12:29 PM, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com<mailto:pkkamos at gmail.com>> wrote:

Hello Stian, my reponse in blue below.

Did you actually add @SecurityDomain("keycloak")?

YES.

Does the request require authentication (does it have a security-constraint in web.xml)?


YES; The request say http://ip:port/context/index.html will be routed to Keycloak for the rquester to login. On successful log-in the requester is redirected back to the index.html. It is at this point I want to retrieve or know who the User is.


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Stian Thorgersen<mailto:sthorger at redhat.com>
Sent: Friday, February 5, 2016 9:53 AM
To: PAA KOJO KONDUAH AMOS<mailto:pkkamos at gmail.com>
Cc: keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Retrieving Logged In User Information.

Did you actually add @SecurityDomain("keycloak")?

Does the request require authentication (does it have a security-constraint in web.xml)?

On 5 February 2016 at 10:41, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com<mailto:pkkamos at gmail.com>> wrote:
Hello, I am trying to retrieve information about the User logged into the webapp via keycloak. I have seen around information on using the following;


@SecurityDomain("keycloak")


@Context

SecurityContext sc;

And

KeycloakPrincipal principal = (KeycloakPrincipal) sc.getUserPrincipal();







But the above line is returning a NullPointerException.



I must say, I have already done the required configuration; as in enabling the Keycloak Subsystem within my app server's server configuration: standalone.xml.

Please any lead on how to retrieve the logged in User via KeyCloak?


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/e666ba94/attachment.html 

From pkkamos at gmail.com  Fri Feb  5 05:45:13 2016
From: pkkamos at gmail.com (PAA KOJO KONDUAH AMOS)
Date: Fri, 5 Feb 2016 10:45:13 +0000
Subject: [keycloak-user] Retrieving Logged In User Information.
In-Reply-To: <B992199E-9ADF-473D-9658-5901028ED32F@cybercom.com>
References: <56b46e3f.6507c20a.91457.7eff@mx.google.com>
	<CAJgngAfg=CnVYnmGzuVWQyo1yPofEqE_C0M+os3_fcL=9_Oitw@mail.gmail.com>
	<56b47956.9447620a.f3b5a.2e92@mx.google.com>
	<B992199E-9ADF-473D-9658-5901028ED32F@cybercom.com>
Message-ID: <56b47d13.c615c20a.950c7.ffff924d@mx.google.com>

Hi, This is my auth-constraint definition in my web.xml

<security-constraint>
		<web-resource-collection>
			<web-resource-name>keyconnect</web-resource-name>
			<url-pattern>/*</url-pattern>
		</web-resource-collection>
		<auth-constraint>
			<role-name>customer</role-name>
		</auth-constraint>
		<user-data-constraint>
			<transport-guarantee>CONFIDENTIAL</transport-guarantee>
		</user-data-constraint>
	</security-constraint>

So, this is fine. Works well for me. I just want to after a successful login?.retrieve the User who logged in.

Sent from Mail for Windows 10

From: Tero Ahonen
Sent: Friday, February 5, 2016 10:37 AM
To: PAA KOJO KONDUAH AMOS
Cc: Stian Thorgersen; keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Retrieving Logged In User Information.

Hi,

Do u have auth-contraint in web.xml? 

<auth-constraint>
??<role-name>somerolehere</role-name>
</auth-constraint>

If there is not required role then no auth is needed.

.t

On 05 Feb 2016, at 12:29 PM, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com> wrote:

Hello Stian, my reponse in blue below.
?
Did you actually add?@SecurityDomain("keycloak")?
?
YES.
?
Does the request require authentication (does it have a security-constraint in web.xml)??
?
?
YES; The request say?http://ip:port/context/index.html?will be routed to Keycloak for the rquester to login. On successful log-in the requester is redirected back to the index.html. It is at this point I want to retrieve or know who the User is.
?
?
Sent from?Mail?for Windows 10
?
From:?Stian Thorgersen
Sent:?Friday, February 5, 2016 9:53 AM
To:?PAA KOJO KONDUAH AMOS
Cc:?keycloak-user at lists.jboss.org
Subject:?Re: [keycloak-user] Retrieving Logged In User Information.
?
Did you actually add?@SecurityDomain("keycloak")?
?
Does the request require authentication (does it have a security-constraint in web.xml)??
?
On 5 February 2016 at 10:41, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com> wrote:
Hello, I am trying to retrieve information about the User logged into the webapp via keycloak. I have seen around information on using the following;
?
@SecurityDomain("keycloak")
?
@Context
SecurityContext sc;
?
And?
KeycloakPrincipal principal = (KeycloakPrincipal) sc.getUserPrincipal();
?
?
?
But the above line is returning a NullPointerException.
?
I must say, I have already done the required configuration; as in?enabling the Keycloak Subsystem within my app server's server configuration:?standalone.xml.
Please any lead on how to retrieve the logged in User via KeyCloak?
?
?
Sent from?Mail?for Windows 10
?

_______________________________________________
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/20160205/a3b7a4f7/attachment-0001.html 

From Tero.Ahonen at cybercom.com  Fri Feb  5 06:06:56 2016
From: Tero.Ahonen at cybercom.com (Tero Ahonen)
Date: Fri, 5 Feb 2016 11:06:56 +0000
Subject: [keycloak-user] Retrieving Logged In User Information.
In-Reply-To: <56b47d13.c615c20a.950c7.ffff924d@mx.google.com>
References: <56b46e3f.6507c20a.91457.7eff@mx.google.com>
	<CAJgngAfg=CnVYnmGzuVWQyo1yPofEqE_C0M+os3_fcL=9_Oitw@mail.gmail.com>
	<56b47956.9447620a.f3b5a.2e92@mx.google.com>
	<B992199E-9ADF-473D-9658-5901028ED32F@cybercom.com>
	<56b47d13.c615c20a.950c7.ffff924d@mx.google.com>
Message-ID: <39211878-7970-4E6C-B34F-C0EB3E598D9C@cybercom.com>

What request.getRemoteUser() returns?

.t
On 05 Feb 2016, at 12:45 PM, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com<mailto:pkkamos at gmail.com>> wrote:

Hi, This is my auth-constraint definition in my web.xml

<security-constraint>
                           <web-resource-collection>
                                         <web-resource-name>keyconnect</web-resource-name>
                                         <url-pattern>/*</url-pattern>
                           </web-resource-collection>
                           <auth-constraint>
                                         <role-name>customer</role-name>
                           </auth-constraint>
                           <user-data-constraint>
                                         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
                           </user-data-constraint>
              </security-constraint>

So, this is fine. Works well for me. I just want to after a successful login?.retrieve the User who logged in.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Tero Ahonen<mailto:Tero.Ahonen at cybercom.com>
Sent: Friday, February 5, 2016 10:37 AM
To: PAA KOJO KONDUAH AMOS<mailto:pkkamos at gmail.com>
Cc: Stian Thorgersen<mailto:sthorger at redhat.com>; keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Retrieving Logged In User Information.

Hi,

Do u have auth-contraint in web.xml?

<auth-constraint>
  <role-name>somerolehere</role-name>
</auth-constraint>

If there is not required role then no auth is needed.

.t

On 05 Feb 2016, at 12:29 PM, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com<mailto:pkkamos at gmail.com>> wrote:

Hello Stian, my reponse in blue below.

Did you actually add @SecurityDomain("keycloak")?

YES.

Does the request require authentication (does it have a security-constraint in web.xml)?


YES; The request say http://ip:port/context/index.html will be routed to Keycloak for the rquester to login. On successful log-in the requester is redirected back to the index.html. It is at this point I want to retrieve or know who the User is.


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Stian Thorgersen<mailto:sthorger at redhat.com>
Sent: Friday, February 5, 2016 9:53 AM
To: PAA KOJO KONDUAH AMOS<mailto:pkkamos at gmail.com>
Cc: keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Retrieving Logged In User Information.

Did you actually add @SecurityDomain("keycloak")?

Does the request require authentication (does it have a security-constraint in web.xml)?

On 5 February 2016 at 10:41, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com<mailto:pkkamos at gmail.com>> wrote:
Hello, I am trying to retrieve information about the User logged into the webapp via keycloak. I have seen around information on using the following;


@SecurityDomain("keycloak")



@Context

SecurityContext sc;

And

KeycloakPrincipal principal = (KeycloakPrincipal) sc.getUserPrincipal();







But the above line is returning a NullPointerException.



I must say, I have already done the required configuration; as in enabling the Keycloak Subsystem within my app server's server configuration: standalone.xml.
Please any lead on how to retrieve the logged in User via KeyCloak?


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10


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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/c9767c63/attachment-0001.html 

From pkkamos at gmail.com  Fri Feb  5 06:26:24 2016
From: pkkamos at gmail.com (PAA KOJO KONDUAH AMOS)
Date: Fri, 5 Feb 2016 11:26:24 +0000
Subject: [keycloak-user] Retrieving Logged In User Information.
In-Reply-To: <39211878-7970-4E6C-B34F-C0EB3E598D9C@cybercom.com>
References: <56b46e3f.6507c20a.91457.7eff@mx.google.com>
	<CAJgngAfg=CnVYnmGzuVWQyo1yPofEqE_C0M+os3_fcL=9_Oitw@mail.gmail.com>
	<56b47956.9447620a.f3b5a.2e92@mx.google.com>
	<B992199E-9ADF-473D-9658-5901028ED32F@cybercom.com>
	<56b47d13.c615c20a.950c7.ffff924d@mx.google.com>
	<39211878-7970-4E6C-B34F-C0EB3E598D9C@cybercom.com>
Message-ID: <56b486ba.6a69c20a.37087.ffff9ebf@mx.google.com>

Hello Tero, I have found my answer. Thanks to the Lead from a friend @Edem_Morny. You see, I am using JSF(PrimeFaces) and so @Context HttpServletRequest didn?t work for me. Rather this worked. So rather than passing the HttpServletRequest using the @Context annotation, I obtain same via the FacesContext.

FacesContext context = FacesContext.getCurrentInstance();
KeycloakSecurityContext session = (KeycloakSecurityContext) ((HttpServletRequest) context.getExternalContext()
				.getRequest()).getAttribute(KeycloakSecurityContext.class.getName());


So this works for me now. Thanks greatly for your time.

Sent from Mail for Windows 10

From: Tero Ahonen
Sent: Friday, February 5, 2016 11:07 AM
To: PAA KOJO KONDUAH AMOS
Cc: Stian Thorgersen; keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Retrieving Logged In User Information.

What request.getRemoteUser() returns? 

.t
On 05 Feb 2016, at 12:45 PM, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com> wrote:

Hi, This is my auth-constraint definition in my web.xml
?
<security-constraint>
?????????????????????????? <web-resource-collection>
???????????????????????????????????????? <web-resource-name>keyconnect</web-resource-name>
???????????????????????????????????????? <url-pattern>/*</url-pattern>
?????????????????????????? </web-resource-collection>
?????????????????????????? <auth-constraint>
???????????????????????????????????????? <role-name>customer</role-name>
?????????????????????????? </auth-constraint>
?????????????????????????? <user-data-constraint>
???????????????????????????????????????? <transport-guarantee>CONFIDENTIAL</transport-guarantee>
?????????????????????????? </user-data-constraint>
????????????? </security-constraint>
?
So, this is fine. Works well for me. I just want to after a successful login?.retrieve the User who logged in.
?
Sent from?Mail?for Windows 10
?
From:?Tero Ahonen
Sent:?Friday, February 5, 2016 10:37 AM
To:?PAA KOJO KONDUAH AMOS
Cc:?Stian Thorgersen;?keycloak-user at lists.jboss.org
Subject:?Re: [keycloak-user] Retrieving Logged In User Information.
?
Hi,
?
Do u have auth-contraint in web.xml??
?
<auth-constraint>
??<role-name>somerolehere</role-name>
</auth-constraint>
?
If there is not required role then no auth is needed.
?
.t
?
On 05 Feb 2016, at 12:29 PM, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com> wrote:
?
Hello Stian, my reponse in blue below.
?
Did you actually add?@SecurityDomain("keycloak")?
?
YES.
?
Does the request require authentication (does it have a security-constraint in web.xml)??
?
?
YES; The request say?http://ip:port/context/index.html?will be routed to Keycloak for the rquester to login. On successful log-in the requester is redirected back to the index.html. It is at this point I want to retrieve or know who the User is.
?
?
Sent from?Mail?for Windows 10
?
From:?Stian Thorgersen
Sent:?Friday, February 5, 2016 9:53 AM
To:?PAA KOJO KONDUAH AMOS
Cc:?keycloak-user at lists.jboss.org
Subject:?Re: [keycloak-user] Retrieving Logged In User Information.
?
Did you actually add?@SecurityDomain("keycloak")?
?
Does the request require authentication (does it have a security-constraint in web.xml)??
?
On 5 February 2016 at 10:41, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com> wrote:
Hello, I am trying to retrieve information about the User logged into the webapp via keycloak. I have seen around information on using the following;
?
@SecurityDomain("keycloak")
?
@Context
SecurityContext sc;
?
And?
KeycloakPrincipal principal = (KeycloakPrincipal) sc.getUserPrincipal();
?
?
?
But the above line is returning a NullPointerException.
?
I must say, I have already done the required configuration; as in?enabling the Keycloak Subsystem within my app server's server configuration:?standalone.xml.
Please any lead on how to retrieve the logged in User via KeyCloak?
?
?
Sent from?Mail?for Windows 10
?

_______________________________________________
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/20160205/bcb1c9e5/attachment-0001.html 

From m.hayen at first8.nl  Fri Feb  5 07:00:17 2016
From: m.hayen at first8.nl (Mark Hayen)
Date: Fri, 5 Feb 2016 13:00:17 +0100
Subject: [keycloak-user] changes in Email SPI
Message-ID: <56B48ED1.9080404@first8.nl>

Hi,

In keycloak 1.4.0.Final I've made a custom EmailSender, plugging into 
the Email SPI.
Now we're upgrading to 1.8.1.Final but I'm running into problems porting 
my existing
EmailSender to 1.8.1.
 From the docs I understand that it has been split up.

Has there been changes to the registration of the email SPI in 
keycloak-server.json?

How do I register the emailtemplate and emailsender providers?

Thank you
Mark Hayen
First8


From sthorger at redhat.com  Fri Feb  5 07:06:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 13:06:39 +0100
Subject: [keycloak-user] changes in Email SPI
In-Reply-To: <56B48ED1.9080404@first8.nl>
References: <56B48ED1.9080404@first8.nl>
Message-ID: <CAJgngAehty4Uwr4B2Mn5Ls1GkLLm1=UEaggcS+TF+_OMF6zr+w@mail.gmail.com>

I don't quite understand what your problem is. If you where able to
register and configure a custom provider for email SPI in the past it seems
you know what to do.

Taking a guess what you are doing is trying to register a provider using
"email" in keycloak-server.json. As the migration docs states there is no
longer a single "email" SPI, instead there are now "emailTemplate" and
"emailSender".

On 5 February 2016 at 13:00, Mark Hayen <m.hayen at first8.nl> wrote:

> Hi,
>
> In keycloak 1.4.0.Final I've made a custom EmailSender, plugging into
> the Email SPI.
> Now we're upgrading to 1.8.1.Final but I'm running into problems porting
> my existing
> EmailSender to 1.8.1.
>  From the docs I understand that it has been split up.
>
> Has there been changes to the registration of the email SPI in
> keycloak-server.json?
>
> How do I register the emailtemplate and emailsender providers?
>
> Thank you
> Mark Hayen
> First8
>
> _______________________________________________
> 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/20160205/f5e00449/attachment.html 

From sthorger at redhat.com  Fri Feb  5 07:10:05 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 13:10:05 +0100
Subject: [keycloak-user] access_token always contains JWT
In-Reply-To: <56B4769F.8080603@caprica.biz>
References: <56B4769F.8080603@caprica.biz>
Message-ID: <CAJgngAe8x1nNYUvF2sz6UhtMSXdCpY0O4i34=NDfWpZCpP+hjQ@mail.gmail.com>

There's no such thing as a "simple token". Tokens are always a signed JWT.

On 5 February 2016 at 11:17, <manfred.duchrow at caprica.biz> wrote:

> Hi,
>
> I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
> service account by
> POST /auth/realms/myrealm/protocol/openid-connect/token
> with grant_type=client_credentials.
>
> The result contains a signed JWT as value of field "access_token" rather
> than a simple token
> as described in chapter 18 (Service Accounts) of the user guide.
>
> So what I expect (need) is a response like this:
>
> {
>     "access_token":"2YotnFZFEjr1zCsicMWpAA",
>     "token_type":"bearer",
>     "expires_in":60,
>     "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>     "refresh_expires_in":600,
>     "id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>     "not-before-policy":0,
>     "session-state":"234234-234234-234234"
> }
>
> Is there a way to configure the account or the realm to return a simple
> token
> in "access_token" (and "refresh_token") rather than a JWT?
>
> Cheers,
>   Manfred
>
>
>
>
> _______________________________________________
> 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/20160205/98cbf1a9/attachment.html 

From sthorger at redhat.com  Fri Feb  5 07:12:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 13:12:21 +0100
Subject: [keycloak-user] invalid code errormessage
In-Reply-To: <56B37329.4060909@first8.nl>
References: <56B37329.4060909@first8.nl>
Message-ID: <CAJgngAfeijUomF+jruWLdHhTiYYwqvJa9+w1nQ_+9f+CSMUb-g@mail.gmail.com>

The link is probably expired. By default these links are only valid for 5
minutes (may have been 10 in 1.4). You can configure this in the tokens
settings in the admin console, it's "Login action timeout".

On 4 February 2016 at 16:50, Mark Hayen <m.hayen at first8.nl> wrote:

> Hi all,
>
> We have a problem with the link in the reset password email.
> Sometimes, but not always we get an error saying invalid code.
> This is the log entry:
>
> type=RESET_PASSWORD_ERROR, realmId=master, clientId=null, userId=null,
> ipAddress=xxx.xxx.xxx.xxx, error=invalid_code
>
> Has anybody seen this error too?
> Is it maybe fixed in a newer version? We are running keycloak 1.4.0.Final.
>
> Thank you
>
> Mark Hayen
> First8
> _______________________________________________
> 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/20160205/e5ec0aef/attachment.html 

From sthorger at redhat.com  Fri Feb  5 07:13:54 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 13:13:54 +0100
Subject: [keycloak-user] KeyCloak Admin Client : DEALING WITH
 [Unrecognized field "access_token" (class
 org.keycloak.representations.AccessTokenResponse)] ISSUE.
In-Reply-To: <56b44c26.42711c0a.25efd.4c16@mx.google.com>
References: <56b1f3e1.8e811c0a.ca774.63f6@mx.google.com>
	<CAJgngAenvjBL58avwONabohE_9oe-FWXqrdE5zwhHmvhi1p-ew@mail.gmail.com>
	<56b44c26.42711c0a.25efd.4c16@mx.google.com>
Message-ID: <CAJgngAdBN-v_JrEpmGde9WH9J=7C1gdkPeDugmw71RAPSiqyKA@mail.gmail.com>

On 5 February 2016 at 08:16, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com>
wrote:

> Hello Stian, I am very happy to share that, Keycloak admin-client
> 1.9.0.CR1 is working for me. I will like to share 2 things I have done to
> get it woking in a web context.
>
>
>
> 1.      Dependency definition:
>
>
>
> *                <dependency>*
>
> *                                  <groupId>org.keycloak</groupId>*
>
> *
> <artifactId>keycloak-admin-client</artifactId>*
>
> *                                  <version>1.9.0.CR1</version>*
>
> *                    </dependency>*
>
>
>
> 2.      created a *jboss-deployment-structure.xml* file, placed it in my
> *WEB-INF* folder ,with the following content(*This ensures Jackson2 is
> used*)[Credit:
> https://docs.jboss.org/resteasy/docs/3.0.2.Final/userguide/html/json.html,
> 21.4. Using Jackson 2.2.x Inside of JBoss AS7]:
>
>                  *<jboss-deployment-structure>*
>
> *                               <deployment>*
>
> *                                        <exclusions>*
>
>
>
> *                                             <module
> name="org.jboss.resteasy.resteasy-jackson-provider" />*
>
> *                                     </exclusions>*
>
> *                                   <dependencies>*
>
> *                                          <module
> name="org.jboss.resteasy.resteasy-jackson2-provider"*
>
> *                                                     services="import" />*
>
> *                                  </dependencies>*
>
> *                          </deployment>*
>
> *                 </jboss-deployment-structure>*
>

You shouldn't need the jboss-deployment-structure.xml at all if you are
using a recent version of WildFly as Jackson2 is the default.


>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Stian Thorgersen <sthorger at redhat.com>
> *Sent: *Wednesday, February 3, 2016 12:57 PM
> *To: *PAA KOJO KONDUAH AMOS <pkkamos at gmail.com>
> *Cc: *keycloak-user at lists.jboss.org
> *Subject: *Re: [keycloak-user] KeyCloak Admin Client :
>
>
>
> In the past the admin client required Jackson 1.x and didn't work with
> Jackson 2.x. This is being fixed in 1.9.
>
>
>
> To make it work you'll need to either wait for 1.9 or make your WAR use
> Jackson instead of Jackson 2. Check out the admin client example as it
> doesn't exactly that.
>
>
>
> On 3 February 2016 at 13:35, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com>
> wrote:
>
> Hello, I have tried out KeyCloak Admin Client. In fact, I have done a
> standalone application which works nicely with KeyCloak Server.
>
>
>
> What I don?t get is, when I port a similar thing into a web application
> context and deploy same on wildfly fly I keep getting the Exception below:
>
>
>
> *Caused by: javax.ws.rs.ProcessingException:
> com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException:
> Unrecognized field "access_token" (class
> org.keycloak.representations.AccessTokenResponse), not marked as ignorable
> (9 known properties: "notBeforePolicy", "otherClaims", "tokenType",
> "token", "expiresIn", "sessionState", "refreshExpiresIn", "idToken",
> "refreshToken"])*
>
>
>
>
>
> Any lead on how to resolve all these maven dependency issues?
>
>
>
>
>
> Thanks.
>
>
>
> Sent from Mail <http://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
>
> _______________________________________________
> 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/20160205/bdc7da9b/attachment-0001.html 

From pkkamos at gmail.com  Fri Feb  5 07:35:48 2016
From: pkkamos at gmail.com (PAA KOJO KONDUAH AMOS)
Date: Fri, 5 Feb 2016 12:35:48 +0000
Subject: [keycloak-user] KeyCloak Admin Client : DEALING
 WITH[Unrecognized field "access_token"
 (classorg.keycloak.representations.AccessTokenResponse)] ISSUE.
In-Reply-To: <CAJgngAdBN-v_JrEpmGde9WH9J=7C1gdkPeDugmw71RAPSiqyKA@mail.gmail.com>
References: <56b1f3e1.8e811c0a.ca774.63f6@mx.google.com>
	<CAJgngAenvjBL58avwONabohE_9oe-FWXqrdE5zwhHmvhi1p-ew@mail.gmail.com>
	<56b44c26.42711c0a.25efd.4c16@mx.google.com>
	<CAJgngAdBN-v_JrEpmGde9WH9J=7C1gdkPeDugmw71RAPSiqyKA@mail.gmail.com>
Message-ID: <56b496ff.a3e8420a.ba474.4523@mx.google.com>

Ok. Noted. Thanks Kindly.

Sent from Mail for Windows 10

From: Stian Thorgersen
Sent: Friday, February 5, 2016 12:13 PM
To: PAA KOJO KONDUAH AMOS
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] KeyCloak Admin Client : DEALING WITH[Unrecognized field "access_token" (classorg.keycloak.representations.AccessTokenResponse)] ISSUE.



On 5 February 2016 at 08:16, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com> wrote:
Hello Stian, I am very happy to share that, Keycloak admin-client 1.9.0.CR1 is working for me. I will like to share 2 things I have done to get it woking in a web context.
?
1.????? Dependency definition:
?
??????????????? <dependency>
????????????????????????????????? <groupId>org.keycloak</groupId>
????????????????????????????????? <artifactId>keycloak-admin-client</artifactId>
????????????????????????????????? <version>1.9.0.CR1</version>
??????????????????? </dependency>
?
2.????? created a jboss-deployment-structure.xml file, placed it in my WEB-INF folder ,with the following content(This ensures Jackson2 is used)[Credit: https://docs.jboss.org/resteasy/docs/3.0.2.Final/userguide/html/json.html, 21.4. Using Jackson 2.2.x Inside of JBoss AS7]:
???????????????? <jboss-deployment-structure>
??????? ?????????????????????? <deployment>
????????????????????? ????????????????? <exclusions>
?
?????????????????????????????????? ????????? <module name="org.jboss.resteasy.resteasy-jackson-provider" />
????????????????????? ?????????????? </exclusions>
????????????????????? ???????????? <dependencies>
?????????????????????????????????? ?????? <module name="org.jboss.resteasy.resteasy-jackson2-provider"
???????????????????????????????????????????????? ??? services="import" />
????????????????????? ??????????? </dependencies>
??????? ????????????????? </deployment>
???????????????? </jboss-deployment-structure>??????????????? ???????

You shouldn't need the?jboss-deployment-structure.xml at all if you are using a recent version of WildFly as Jackson2 is the default.
?
?
?
Sent from Mail for Windows 10
?
From: Stian Thorgersen
Sent: Wednesday, February 3, 2016 12:57 PM
To: PAA KOJO KONDUAH AMOS
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] KeyCloak Admin Client :
?
In the past the admin client required Jackson 1.x and didn't work with Jackson 2.x. This is being fixed in 1.9.
?
To make it work you'll need to either wait for 1.9 or make your WAR use Jackson instead of Jackson 2. Check out the admin client example as it doesn't exactly that.
?
On 3 February 2016 at 13:35, PAA KOJO KONDUAH AMOS <pkkamos at gmail.com> wrote:
Hello, I have tried out KeyCloak Admin Client. In fact, I have done a standalone application which works nicely with KeyCloak Server.
?
What I don?t get is, when I port a similar thing into a web application context and deploy same on wildfly fly I keep getting the Exception below:
?
Caused by: javax.ws.rs.ProcessingException: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "access_token" (class org.keycloak.representations.AccessTokenResponse), not marked as ignorable (9 known properties: "notBeforePolicy", "otherClaims", "tokenType", "token", "expiresIn", "sessionState", "refreshExpiresIn", "idToken", "refreshToken"])
?
?
Any lead on how to resolve all these maven dependency issues?
?
?
Thanks.
?
Sent from Mail for Windows 10
?

_______________________________________________
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/20160205/389c1762/attachment.html 

From prabhalar at yahoo.com  Fri Feb  5 07:47:03 2016
From: prabhalar at yahoo.com (Raghuram Prabhala)
Date: Fri, 5 Feb 2016 12:47:03 +0000 (UTC)
Subject: [keycloak-user] access_token always contains JWT
In-Reply-To: <CAJgngAe8x1nNYUvF2sz6UhtMSXdCpY0O4i34=NDfWpZCpP+hjQ@mail.gmail.com>
References: <CAJgngAe8x1nNYUvF2sz6UhtMSXdCpY0O4i34=NDfWpZCpP+hjQ@mail.gmail.com>
Message-ID: <355538146.1756649.1454676424011.JavaMail.yahoo@mail.yahoo.com>

Access token is implementation specific. Some commercial software have the concept of "reference tokens" which are nothing but random strings indicated below. The clients have to query back the Authorization server to get a validated JWT token


      From: Stian Thorgersen <sthorger at redhat.com>
 To: manfred.duchrow at caprica.biz 
Cc: keycloak-user <keycloak-user at lists.jboss.org>
 Sent: Friday, February 5, 2016 7:10 AM
 Subject: Re: [keycloak-user] access_token always contains JWT
   
There's no such thing as a "simple token". Tokens are always a signed JWT.
On 5 February 2016 at 11:17, <manfred.duchrow at caprica.biz> wrote:

   Hi,

I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
service account by
POST /auth/realms/myrealm/protocol/openid-connect/token
with grant_type=client_credentials.

The result contains a signed JWT as value of field "access_token" rather
than a simple token
as described in chapter 18 (Service Accounts) of the user guide.

So what I expect (need) is a response like this:

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":60,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "refresh_expires_in":600,
    "id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "not-before-policy":0,
    "session-state":"234234-234234-234234"
}

Is there a way to configure the account or the realm to return a simple
token
in "access_token" (and "refresh_token") rather than a JWT?

Cheers,
  Manfred


  
_______________________________________________
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/20160205/396739d2/attachment-0001.html 

From malmi.suh at gmail.com  Fri Feb  5 07:50:47 2016
From: malmi.suh at gmail.com (Malmi Samarasinghe)
Date: Fri, 5 Feb 2016 18:20:47 +0530
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAJgngAffrAE1+P315PHAoF2stOnDdKV=kRAcA-1rFHAMvEKo1w@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
	<56B2C5D5.8050702@redhat.com>
	<CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>
	<CAJgngAd_t-hE3y1itAZ6rBHfT7ZNh+rm7T6zqeJWT5MjZSs87A@mail.gmail.com>
	<CAL_Nbcn46D9b_ttV6jUkSxt5Msc4bMNeXCNmsuBxCA2PRCoDVQ@mail.gmail.com>
	<CAL_NbcmKYy7Du=tfMAuMS_pGNySQ=EDrtbdejw41e0_W8E8_YA@mail.gmail.com>
	<CAJgngAcf4RtoS__nf4KtpRBQ0DCWnOWhkECiaLhgK7ioWMq01Q@mail.gmail.com>
	<CAL_Nbcnt8tdruqK3=+RzX+E5RjqJiT_vQfixGgLrVAvQDa2_VQ@mail.gmail.com>
	<CAJgngAffrAE1+P315PHAoF2stOnDdKV=kRAcA-1rFHAMvEKo1w@mail.gmail.com>
Message-ID: <CAL_Nbc=RYFunMG9aAcf4N3tLSUV8pm7riUaS0zk+5yM7FxXhmw@mail.gmail.com>

Hi Stian,

Thank you very much for looking in to the issue. We tried with around 6
role creations per second, and I tried switching off realm cache and it had
negative impact on the performance of other API s.

Really appreciate if you could suggest us a rough timeline for a fix date.

Regards,
Malmi

On Fri, Feb 5, 2016 at 3:20 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Either don't create roles concurrently or disable cache.
>
> How frequently are you creating roles? Just wondering because if you do it
> will significantly impact the benefits of the cache as we invalidate a
> large amount of the cache when roles are added/removed.
>
> The problem you are seeing is most likely down to a race condition when
> the realm role list (or client role lists) are re-loaded after they are
> invalidated. I haven't had much time to look at it yet, so I don't know the
> exact cause or a solution.
>
> On 5 February 2016 at 09:57, Malmi Samarasinghe <malmi.suh at gmail.com>
> wrote:
>
>> Hi Stian,
>>
>> We have this in production is there any intermediary fix that we can do
>> or any workaround?
>>
>> Regards,
>> Malmi
>>
>> On Fri, Feb 5, 2016 at 2:11 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Confirmed this bug https://issues.jboss.org/browse/KEYCLOAK-2458
>>>
>>> On 5 February 2016 at 06:53, Malmi Samarasinghe <malmi.suh at gmail.com>
>>> wrote:
>>>
>>>> Hi Stian/Bill,
>>>>
>>>> I just wanted to highlight that this issue only occurred when realm
>>>> cache enabled option is ON.
>>>>
>>>> Regards,
>>>> Malmi
>>>>
>>>> On Thu, Feb 4, 2016 at 8:38 PM, Malmi Samarasinghe <malmi.suh at gmail.com
>>>> > wrote:
>>>>
>>>>> Hi Stian
>>>>>
>>>>> I have multiple threads creating different roles. Basically one thread
>>>>> will execute all three apis one after another.
>>>>>
>>>>> Regards,
>>>>> Malmi
>>>>>
>>>>> On Thu, Feb 4, 2016 at 5:23 PM, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> When you say method1 is executed in multiple threads, do you mean one
>>>>>> thread creates the role and another retrieves it? Or do you have multiple
>>>>>> threads creating different roles?
>>>>>>
>>>>>> On 4 February 2016 at 12:31, Malmi Samarasinghe <malmi.suh at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Bill,
>>>>>>>
>>>>>>> Please find the work flow that we have implemented
>>>>>>> create user : POST : admin/realms/{realm}/users
>>>>>>>
>>>>>>> *Method1* wrapps the following API calls
>>>>>>> Create Realm role : POST : admin/realms/{realm}/roles
>>>>>>> Retrieve Role : GET : admin/realms/{realm}/roles/{roleName}
>>>>>>> Assign Role : POST :
>>>>>>> admin/realms/leapset/users/{0}/role-mappings/realm
>>>>>>>
>>>>>>> Same for the client roles as well.
>>>>>>>
>>>>>>> *Method1 *is executed in multiple threads and assign reams role API
>>>>>>> starts failing with 404 (keycloak log states role not found)
>>>>>>>
>>>>>>> Regards,
>>>>>>> Malmi
>>>>>>>
>>>>>>> On Thu, Feb 4, 2016 at 9:00 AM, Bill Burke <bburke at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Can you give me what REST invocations you are doing? How do you
>>>>>>>> find the role?  How do you create the role? etc...
>>>>>>>>
>>>>>>>> On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
>>>>>>>>
>>>>>>>> Hi Bill,
>>>>>>>>
>>>>>>>> We tried the above fix on top of 1.7.0 by applying the changes from
>>>>>>>> the commits attached to the
>>>>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and it
>>>>>>>> seems to have the same issue. If you have any further update on this please
>>>>>>>> let us know.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Malmi
>>>>>>>>
>>>>>>>> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <
>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> This could be related to
>>>>>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327.
>>>>>>>>>
>>>>>>>>> It's already fixed in master, so if you can try it out that would
>>>>>>>>> be great. We should also have a 1.8.1.Final release this week with the fix
>>>>>>>>> in as well.
>>>>>>>>>
>>>>>>>>> On 30 January 2016 at 05:16, Malmi Samarasinghe <
>>>>>>>>> <malmi.suh at gmail.com>malmi.suh at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Bill,
>>>>>>>>>>
>>>>>>>>>> We are using keycloak 1.7.0 and rdbms (mysql)
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Malmi Samarasinghe
>>>>>>>>>> On Jan 29, 2016 7:41 PM, "Bill Burke" < <bburke at redhat.com>
>>>>>>>>>> bburke at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Which version of keycloak?  RDBMS or Mongo?
>>>>>>>>>>>
>>>>>>>>>>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>
>>>>>>>>>>> In my application we create retrieve and assign role
>>>>>>>>>>> subsequently and it seems that even for a small load (2-3 threads) with
>>>>>>>>>>> realm cache enabled option, assign realm role call fails due to role not
>>>>>>>>>>> exist error and 404 is returned from keycloak.
>>>>>>>>>>>
>>>>>>>>>>> With the realm cache disabled option the load works fine.
>>>>>>>>>>>
>>>>>>>>>>> Please get back to me if you have any information on any other
>>>>>>>>>>> option we can follow to get this issue sorted or on what action the realm
>>>>>>>>>>> cache will be persisted to DB.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Malmi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Bill Burke
>>>>>>>>>>> JBoss, a division of Red Hathttp://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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Bill Burke
>>>>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/b43a2b64/attachment.html 

From thomas.darimont at googlemail.com  Fri Feb  5 07:59:03 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 5 Feb 2016 13:59:03 +0100
Subject: [keycloak-user] Realm wide custom id / access token claims.
Message-ID: <CAK-7U1hci0xcXQZa9LzWkAFYDa8W0EhmG5pd4V_JYtc3TwSG-w@mail.gmail.com>

Hello group,

In my user model I have a custom user attribute that I want to make
available to multiple
clients via the id / access token with just one definition. Is this already
possible somehow?

Currently one can define custom mappers for a single client via:
(In Admin Console) Realm -> Clients -> example-client -> Mappers -> create

There I can specify a new mapper of type "user attribute" where I can refer
to the actual user attribute, give it a "token claim name" (e.g.
"myattribute") and specify whether this should be included in the ID and /
or access token.

The user attribute in the token can then be accessed from within the client
via:
KeycloakSecurityContext:getIdToken().getOtherClaims().get("myattribute")

This apporach however requires that I configure this for every client - for
which I already have 10 (trend: upwards)...
It would make thinks a lot easier if it were possible to specify those
mappers realm wide...

PS: I'm currently using Keycloak 1.9.0.CR1

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/7140c821/attachment.html 

From bburke at redhat.com  Fri Feb  5 08:42:35 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 5 Feb 2016 08:42:35 -0500
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <CAL_Nbc=RYFunMG9aAcf4N3tLSUV8pm7riUaS0zk+5yM7FxXhmw@mail.gmail.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
	<56B2C5D5.8050702@redhat.com>
	<CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>
	<CAJgngAd_t-hE3y1itAZ6rBHfT7ZNh+rm7T6zqeJWT5MjZSs87A@mail.gmail.com>
	<CAL_Nbcn46D9b_ttV6jUkSxt5Msc4bMNeXCNmsuBxCA2PRCoDVQ@mail.gmail.com>
	<CAL_NbcmKYy7Du=tfMAuMS_pGNySQ=EDrtbdejw41e0_W8E8_YA@mail.gmail.com>
	<CAJgngAcf4RtoS__nf4KtpRBQ0DCWnOWhkECiaLhgK7ioWMq01Q@mail.gmail.com>
	<CAL_Nbcnt8tdruqK3=+RzX+E5RjqJiT_vQfixGgLrVAvQDa2_VQ@mail.gmail.com>
	<CAJgngAffrAE1+P315PHAoF2stOnDdKV=kRAcA-1rFHAMvEKo1w@mail.gmail.com>
	<CAL_Nbc=RYFunMG9aAcf4N3tLSUV8pm7riUaS0zk+5yM7FxXhmw@mail.gmail.com>
Message-ID: <56B4A6CB.3020507@redhat.com>

1.9.0.Final will have it...

On 2/5/2016 7:50 AM, Malmi Samarasinghe wrote:
> Hi Stian,
>
> Thank you very much for looking in to the issue. We tried with around 
> 6 role creations per second, and I tried switching off realm cache and 
> it had negative impact on the performance of other API s.
>
> Really appreciate if you could suggest us a rough timeline for a fix 
> date.
>
> Regards,
> Malmi
>
> On Fri, Feb 5, 2016 at 3:20 PM, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     Either don't create roles concurrently or disable cache.
>
>     How frequently are you creating roles? Just wondering because if
>     you do it will significantly impact the benefits of the cache as
>     we invalidate a large amount of the cache when roles are
>     added/removed.
>
>     The problem you are seeing is most likely down to a race condition
>     when the realm role list (or client role lists) are re-loaded
>     after they are invalidated. I haven't had much time to look at it
>     yet, so I don't know the exact cause or a solution.
>
>     On 5 February 2016 at 09:57, Malmi Samarasinghe
>     <malmi.suh at gmail.com <mailto:malmi.suh at gmail.com>> wrote:
>
>         Hi Stian,
>
>         We have this in production is there any intermediary fix that
>         we can do or any workaround?
>
>         Regards,
>         Malmi
>
>         On Fri, Feb 5, 2016 at 2:11 PM, Stian Thorgersen
>         <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>
>             Confirmed this bug
>             https://issues.jboss.org/browse/KEYCLOAK-2458
>
>             On 5 February 2016 at 06:53, Malmi Samarasinghe
>             <malmi.suh at gmail.com <mailto:malmi.suh at gmail.com>> wrote:
>
>                 Hi Stian/Bill,
>
>                 I just wanted to highlight that this issue only
>                 occurred when realm cache enabled option is ON.
>
>                 Regards,
>                 Malmi
>
>                 On Thu, Feb 4, 2016 at 8:38 PM, Malmi Samarasinghe
>                 <malmi.suh at gmail.com <mailto:malmi.suh at gmail.com>> wrote:
>
>                     Hi Stian
>
>                     I have multiple threads creating different roles.
>                     Basically one thread will execute all three apis
>                     one after another.
>
>                     Regards,
>                     Malmi
>
>                     On Thu, Feb 4, 2016 at 5:23 PM, Stian Thorgersen
>                     <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>                     wrote:
>
>                         When you say method1 is executed in multiple
>                         threads, do you mean one thread creates the
>                         role and another retrieves it? Or do you have
>                         multiple threads creating different roles?
>
>                         On 4 February 2016 at 12:31, Malmi
>                         Samarasinghe <malmi.suh at gmail.com
>                         <mailto:malmi.suh at gmail.com>> wrote:
>
>                             Hi Bill,
>
>                             Please find the work flow that we have
>                             implemented
>                             create user : POST
>                             : admin/realms/{realm}/users
>
>                             *Method1* wrapps the following API calls
>                             Create Realm role : POST :
>                             admin/realms/{realm}/roles
>                             Retrieve Role : GET
>                             : admin/realms/{realm}/roles/{roleName}
>                             Assign Role : POST :
>                             admin/realms/leapset/users/{0}/role-mappings/realm
>
>                             Same for the client roles as well.
>
>                             *Method1 *is executed in multiple threads
>                             and assign reams role API starts failing
>                             with 404 (keycloak log states role not found)
>
>                             Regards,
>                             Malmi
>
>                             On Thu, Feb 4, 2016 at 9:00 AM, Bill Burke
>                             <bburke at redhat.com
>                             <mailto:bburke at redhat.com>> wrote:
>
>                                 Can you give me what REST invocations
>                                 you are doing? How do you find the
>                                 role?  How do you create the role? etc...
>
>                                 On 2/3/2016 9:45 PM, Malmi
>                                 Samarasinghe wrote:
>>                                 Hi Bill,
>>
>>                                 We tried the above fix on top of
>>                                 1.7.0 by applying the changes from
>>                                 the commits attached to the
>>                                 https://issues.jboss.org/browse/KEYCLOAK-2327 and
>>                                 deployed, and it seems to have the
>>                                 same issue. If you have any
>>                                 further update on this please let us
>>                                 know.
>>
>>                                 Regards,
>>                                 Malmi
>>
>>                                 On Mon, Feb 1, 2016 at 4:02 PM, Stian
>>                                 Thorgersen <sthorger at redhat.com
>>                                 <mailto:sthorger at redhat.com>> wrote:
>>
>>                                     This could be related to
>>                                     https://issues.jboss.org/browse/KEYCLOAK-2327.
>>
>>
>>                                     It's already fixed in master, so
>>                                     if you can try it out that would
>>                                     be great. We should also have a
>>                                     1.8.1.Final release this week
>>                                     with the fix in as well.
>>
>>                                     On 30 January 2016 at 05:16,
>>                                     Malmi Samarasinghe
>>                                     <malmi.suh at gmail.com
>>                                     <mailto:malmi.suh at gmail.com>> wrote:
>>
>>                                         Hi Bill,
>>
>>                                         We are using keycloak 1.7.0
>>                                         and rdbms (mysql)
>>
>>                                         Regards,
>>                                         Malmi Samarasinghe
>>
>>                                         On Jan 29, 2016 7:41 PM,
>>                                         "Bill Burke"
>>                                         <bburke at redhat.com
>>                                         <mailto:bburke at redhat.com>>
>>                                         wrote:
>>
>>                                             Which version of
>>                                             keycloak? RDBMS or Mongo?
>>
>>                                             On 1/29/2016 12:35 AM,
>>                                             Malmi Samarasinghe wrote:
>>>                                             Hi Everyone,
>>>
>>>                                             In my application we
>>>                                             create retrieve and
>>>                                             assign role subsequently
>>>                                             and it seems that even
>>>                                             for a small load (2-3
>>>                                             threads) with realm
>>>                                             cache enabled option,
>>>                                             assign realm role call
>>>                                             fails due to role not
>>>                                             exist error and 404 is
>>>                                             returned from keycloak.
>>>
>>>                                             With the realm cache
>>>                                             disabled option the load
>>>                                             works fine.
>>>
>>>                                             Please get back to me if
>>>                                             you have any information
>>>                                             on any other option we
>>>                                             can follow to get this
>>>                                             issue sorted or on what
>>>                                             action the realm cache
>>>                                             will be persisted to DB.
>>>
>>>                                             Regards,
>>>                                             Malmi
>>>
>>>
>>>                                             _______________________________________________
>>>                                             keycloak-user mailing list
>>>                                             keycloak-user at lists.jboss.org
>>>                                             <mailto:keycloak-user at lists.jboss.org>
>>>                                             https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>                                             -- 
>>                                             Bill Burke
>>                                             JBoss, a division of Red Hat
>>                                             http://bill.burkecentral.com
>>
>>
>>                                             _______________________________________________
>>                                             keycloak-user mailing list
>>                                             keycloak-user at lists.jboss.org
>>                                             <mailto:keycloak-user at lists.jboss.org>
>>                                             https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>                                         _______________________________________________
>>                                         keycloak-user mailing list
>>                                         keycloak-user at lists.jboss.org
>>                                         <mailto:keycloak-user at lists.jboss.org>
>>                                         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>
>                                 -- 
>                                 Bill Burke
>                                 JBoss, a division of Red Hat
>                                 http://bill.burkecentral.com
>
>
>
>
>
>
>
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/b0692957/attachment-0001.html 

From thomas.darimont at googlemail.com  Fri Feb  5 08:48:35 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 5 Feb 2016 14:48:35 +0100
Subject: [keycloak-user] Default client for a realm
Message-ID: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>

Hi group,

I have multiple realms and a list of clients registered within each realm.
For each realm I'd like to configure
a "default" client that can be used as a redirect fallback if no client or
redirect_uri was specified in requests.

The usecase is to provide some kind of "home" or "launchpad" service where
users are redirected to in case
they don't know or didn't specify where to go.
The launchpad would then present a "fancy selection" of all the apps
(clients) that are available to the current user,
somewhat comparable to the https://www.google.de/intl/de/about/products/
page.

Is this already possible or considered as a feature?

A default "default" client could be the account application.

A quick hack I could think of would be to define a client with the name
"default" (or another well-known name)
and register a custom endpoint in Keycloak that would accept the client_id
as a url parameter and redirect to the
configured client base url.

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/62034466/attachment.html 

From thomas.raehalme at aitiofinland.com  Fri Feb  5 08:55:19 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Fri, 5 Feb 2016 15:55:19 +0200
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
Message-ID: <CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>

Hi!

How about just a default redirect URL where the user is redirected when
it's appropriate to return back to the application?
The redirection could be immediate or a link on the error view.

I think this would help avoid a lot of confusion when Keycloak for a reason
or another is not aware of the client and needs to abort the process.

Best regards,
Thomas


On Fri, Feb 5, 2016 at 3:48 PM, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hi group,
>
> I have multiple realms and a list of clients registered within each realm.
> For each realm I'd like to configure
> a "default" client that can be used as a redirect fallback if no client or
> redirect_uri was specified in requests.
>
> The usecase is to provide some kind of "home" or "launchpad" service where
> users are redirected to in case
> they don't know or didn't specify where to go.
> The launchpad would then present a "fancy selection" of all the apps
> (clients) that are available to the current user,
> somewhat comparable to the https://www.google.de/intl/de/about/products/
> page.
>
> Is this already possible or considered as a feature?
>
> A default "default" client could be the account application.
>
> A quick hack I could think of would be to define a client with the name
> "default" (or another well-known name)
> and register a custom endpoint in Keycloak that would accept the client_id
> as a url parameter and redirect to the
> configured client base url.
>
> Cheers,
> Thomas
>
> _______________________________________________
> 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/20160205/811e4236/attachment.html 

From sthorger at redhat.com  Fri Feb  5 08:59:31 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 14:59:31 +0100
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
Message-ID: <CAJgngAd2H2aQQKj2qbDTLip2o4S8DsaHODDstzetdFftC2qy1g@mail.gmail.com>

Missing client_id or redirect_uri are errors and should not just be masked
by redirecting the user to a random location. You can customize the error
page though to make it more friendly to your users, as well as including a
link to your apps page.

FIY We actually want to eventually have a clients page like
https://www.google.de/intl/de/about/products/ which lists all clients
available in the realm.

On 5 February 2016 at 14:48, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Hi group,
>
> I have multiple realms and a list of clients registered within each realm.
> For each realm I'd like to configure
> a "default" client that can be used as a redirect fallback if no client or
> redirect_uri was specified in requests.
>
> The usecase is to provide some kind of "home" or "launchpad" service where
> users are redirected to in case
> they don't know or didn't specify where to go.
> The launchpad would then present a "fancy selection" of all the apps
> (clients) that are available to the current user,
> somewhat comparable to the https://www.google.de/intl/de/about/products/
> page.
>
> Is this already possible or considered as a feature?
>
> A default "default" client could be the account application.
>
> A quick hack I could think of would be to define a client with the name
> "default" (or another well-known name)
> and register a custom endpoint in Keycloak that would accept the client_id
> as a url parameter and redirect to the
> configured client base url.
>
> Cheers,
> Thomas
>
> _______________________________________________
> 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/20160205/ddbc58d2/attachment.html 

From thomas.darimont at googlemail.com  Fri Feb  5 09:02:19 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 5 Feb 2016 15:02:19 +0100
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
	<CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
Message-ID: <CAK-7U1gH5zKL4EYRpenmd=LT-S6pV7Z5y6frxGzLrJB4ZyqbWQ@mail.gmail.com>

Hoi,

I had the same idea initially but then I thought that simply tagging a
client as "default" would be more flexible since you have all the client
metadata, role support etc.

Cheers,
Thomas

2016-02-05 14:55 GMT+01:00 Thomas Raehalme <thomas.raehalme at aitiofinland.com
>:

> Hi!
>
> How about just a default redirect URL where the user is redirected when
> it's appropriate to return back to the application?
> The redirection could be immediate or a link on the error view.
>
> I think this would help avoid a lot of confusion when Keycloak for a
> reason or another is not aware of the client and needs to abort the process.
>
> Best regards,
> Thomas
>
>
> On Fri, Feb 5, 2016 at 3:48 PM, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hi group,
>>
>> I have multiple realms and a list of clients registered within each
>> realm. For each realm I'd like to configure
>> a "default" client that can be used as a redirect fallback if no client
>> or redirect_uri was specified in requests.
>>
>> The usecase is to provide some kind of "home" or "launchpad" service
>> where users are redirected to in case
>> they don't know or didn't specify where to go.
>> The launchpad would then present a "fancy selection" of all the apps
>> (clients) that are available to the current user,
>> somewhat comparable to the https://www.google.de/intl/de/about/products/
>> page.
>>
>> Is this already possible or considered as a feature?
>>
>> A default "default" client could be the account application.
>>
>> A quick hack I could think of would be to define a client with the name
>> "default" (or another well-known name)
>> and register a custom endpoint in Keycloak that would accept the
>> client_id as a url parameter and redirect to the
>> configured client base url.
>>
>> Cheers,
>> Thomas
>>
>> _______________________________________________
>> 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/20160205/780fbf1a/attachment.html 

From sthorger at redhat.com  Fri Feb  5 09:03:08 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 15:03:08 +0100
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
	<CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
Message-ID: <CAJgngAfGC-e+j0c2AzM4YXUVSfV7yzzV0rThRGrhTicd6a5SaA@mail.gmail.com>

On 5 February 2016 at 14:55, Thomas Raehalme <
thomas.raehalme at aitiofinland.com> wrote:

> Hi!
>
> How about just a default redirect URL where the user is redirected when
> it's appropriate to return back to the application?
> The redirection could be immediate or a link on the error view.
>

Errors should not be masked and you can already customize the error page to
add a link


>
> I think this would help avoid a lot of confusion when Keycloak for a
> reason or another is not aware of the client and needs to abort the process.
>

There are only a few cases where the client isn't known and I don't think
this is a good solution for either of those:

* Admin sends email action to user - a better solution here would be to
allow admin to select a client
* Client session times out and is garbage collected - we could add client
uuid to the client session code which would mean it's always available
* Client is not specified - this is an error in your application and should
not just be masked. Solution to make it more friendly is to improve error
page


>
> Best regards,
> Thomas
>
>
> On Fri, Feb 5, 2016 at 3:48 PM, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hi group,
>>
>> I have multiple realms and a list of clients registered within each
>> realm. For each realm I'd like to configure
>> a "default" client that can be used as a redirect fallback if no client
>> or redirect_uri was specified in requests.
>>
>> The usecase is to provide some kind of "home" or "launchpad" service
>> where users are redirected to in case
>> they don't know or didn't specify where to go.
>> The launchpad would then present a "fancy selection" of all the apps
>> (clients) that are available to the current user,
>> somewhat comparable to the https://www.google.de/intl/de/about/products/
>> page.
>>
>> Is this already possible or considered as a feature?
>>
>> A default "default" client could be the account application.
>>
>> A quick hack I could think of would be to define a client with the name
>> "default" (or another well-known name)
>> and register a custom endpoint in Keycloak that would accept the
>> client_id as a url parameter and redirect to the
>> configured client base url.
>>
>> Cheers,
>> Thomas
>>
>> _______________________________________________
>> 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/20160205/79f2fb4f/attachment-0001.html 

From bburke at redhat.com  Fri Feb  5 09:05:30 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 5 Feb 2016 09:05:30 -0500
Subject: [keycloak-user] Realm wide custom id / access token claims.
In-Reply-To: <CAK-7U1hci0xcXQZa9LzWkAFYDa8W0EhmG5pd4V_JYtc3TwSG-w@mail.gmail.com>
References: <CAK-7U1hci0xcXQZa9LzWkAFYDa8W0EhmG5pd4V_JYtc3TwSG-w@mail.gmail.com>
Message-ID: <56B4AC2A.3020201@redhat.com>

See ClientTemplates


On 2/5/2016 7:59 AM, Thomas Darimont wrote:
> Hello group,
>
> In my user model I have a custom user attribute that I want to make 
> available to multiple
> clients via the id / access token with just one definition. Is this 
> already possible somehow?
>
> Currently one can define custom mappers for a single client via:
> (In Admin Console) Realm -> Clients -> example-client -> Mappers -> create
>
> There I can specify a new mapper of type "user attribute" where I can 
> refer to the actual user attribute, give it a "token claim name" (e.g. 
> "myattribute") and specify whether this should be included in the ID 
> and / or access token.
>
> The user attribute in the token can then be accessed from within the 
> client via:
> KeycloakSecurityContext:getIdToken().getOtherClaims().get("myattribute")
>
> This apporach however requires that I configure this for every client 
> - for which I already have 10 (trend: upwards)...
> It would make thinks a lot easier if it were possible to specify those 
> mappers realm wide...
>
> PS: I'm currently using Keycloak 1.9.0.CR1
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/7024b2a6/attachment.html 

From thomas.darimont at googlemail.com  Fri Feb  5 09:15:31 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 5 Feb 2016 15:15:31 +0100
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAJgngAfGC-e+j0c2AzM4YXUVSfV7yzzV0rThRGrhTicd6a5SaA@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
	<CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
	<CAJgngAfGC-e+j0c2AzM4YXUVSfV7yzzV0rThRGrhTicd6a5SaA@mail.gmail.com>
Message-ID: <CAK-7U1iR4THBqw21dPs89s6otnhRaZbn+vBshb6maoA5HgHLLw@mail.gmail.com>

Hello Stian, Hello Thomas,

yes I understand that - and I agree that falling back to the default client
in case of a missing client is not a good idea.

However I think I would be very helpful to be able to initiate a redirect
from one client to another client (that is just known by client_id)
for the use case I outlined above -> e.g. redirecting to a "launchpad" app.

E.g.:
https://keycloak-server:8080/auth/realms/my-realm/redirect?client_id=my-default-client
-> would redirect to the my-default-client base url.

https://keycloak-server:8080/auth/realms/my-realm/redirect
-> would redirect to the client marked as "default"

@Thomas
Initially I also thought about having a default redirect url per realm but
then I thought that simply refering to a client_id and let keycloak
redirect the user
appropriatly would be more flexible, especially because you can then also
leverage all the client metadata that is available for a client (name,
description etc.).

Cheers,
Thomas

2016-02-05 15:03 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

>
>
> On 5 February 2016 at 14:55, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>
>> Hi!
>>
>> How about just a default redirect URL where the user is redirected when
>> it's appropriate to return back to the application?
>> The redirection could be immediate or a link on the error view.
>>
>
> Errors should not be masked and you can already customize the error page
> to add a link
>
>
>>
>> I think this would help avoid a lot of confusion when Keycloak for a
>> reason or another is not aware of the client and needs to abort the process.
>>
>
> There are only a few cases where the client isn't known and I don't think
> this is a good solution for either of those:
>
> * Admin sends email action to user - a better solution here would be to
> allow admin to select a client
> * Client session times out and is garbage collected - we could add client
> uuid to the client session code which would mean it's always available
> * Client is not specified - this is an error in your application and
> should not just be masked. Solution to make it more friendly is to improve
> error page
>
>
>>
>> Best regards,
>> Thomas
>>
>>
>> On Fri, Feb 5, 2016 at 3:48 PM, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Hi group,
>>>
>>> I have multiple realms and a list of clients registered within each
>>> realm. For each realm I'd like to configure
>>> a "default" client that can be used as a redirect fallback if no client
>>> or redirect_uri was specified in requests.
>>>
>>> The usecase is to provide some kind of "home" or "launchpad" service
>>> where users are redirected to in case
>>> they don't know or didn't specify where to go.
>>> The launchpad would then present a "fancy selection" of all the apps
>>> (clients) that are available to the current user,
>>> somewhat comparable to the https://www.google.de/intl/de/about/products/
>>> page.
>>>
>>> Is this already possible or considered as a feature?
>>>
>>> A default "default" client could be the account application.
>>>
>>> A quick hack I could think of would be to define a client with the name
>>> "default" (or another well-known name)
>>> and register a custom endpoint in Keycloak that would accept the
>>> client_id as a url parameter and redirect to the
>>> configured client base url.
>>>
>>> Cheers,
>>> Thomas
>>>
>>> _______________________________________________
>>> 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/20160205/502b2cb6/attachment.html 

From manfred.duchrow at caprica.biz  Fri Feb  5 09:17:40 2016
From: manfred.duchrow at caprica.biz (manfred.duchrow at caprica.biz)
Date: Fri, 5 Feb 2016 15:17:40 +0100
Subject: [keycloak-user] access_token always contains JWT
In-Reply-To: <355538146.1756649.1454676424011.JavaMail.yahoo@mail.yahoo.com>
References: <CAJgngAe8x1nNYUvF2sz6UhtMSXdCpY0O4i34=NDfWpZCpP+hjQ@mail.gmail.com>
	<355538146.1756649.1454676424011.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <56B4AF04.4080608@caprica.biz>

Yes, that's true (even for some open source software too).
So am I supposed to put this JWT access token into the Authorization
request header as Bearer value to authorize a request?
The access token I got from Keycloak is over 5000 characters long!


On 05.02.2016 13:47, Raghuram Prabhala wrote:
> Access token is implementation specific. Some commercial software have
> the concept of "reference tokens" which are nothing but random strings
> indicated below. The clients have to query back the Authorization
> server to get a validated JWT token
>
>
>
> ------------------------------------------------------------------------
> *From:* Stian Thorgersen <sthorger at redhat.com>
> *To:* manfred.duchrow at caprica.biz
> *Cc:* keycloak-user <keycloak-user at lists.jboss.org>
> *Sent:* Friday, February 5, 2016 7:10 AM
> *Subject:* Re: [keycloak-user] access_token always contains JWT
>
> There's no such thing as a "simple token". Tokens are always a signed JWT.
>
> On 5 February 2016 at 11:17, <manfred.duchrow at caprica.biz
> <mailto:manfred.duchrow at caprica.biz>> wrote:
>
>     Hi,
>
>     I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
>     service account by
>     POST /auth/realms/myrealm/protocol/openid-connect/token
>     with grant_type=client_credentials.
>
>     The result contains a signed JWT as value of field "access_token" rather
>     than a simple token
>     as described in chapter 18 (Service Accounts) of the user guide.
>
>     So what I expect (need) is a response like this:
>
>     {
>         "access_token":"2YotnFZFEjr1zCsicMWpAA",
>         "token_type":"bearer",
>         "expires_in":60,
>         "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>         "refresh_expires_in":600,
>         "id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>         "not-before-policy":0,
>         "session-state":"234234-234234-234234"
>     }
>
>     Is there a way to configure the account or the realm to return a simple
>     token
>     in "access_token" (and "refresh_token") rather than a JWT?
>
>     Cheers,
>       Manfred
>
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

-- 
========================================
Caprica Ltd.
69 Great Hampton Street
Birmingham, West Midlands, B186EW, 
Registered in England and Wales
Company No. 5298548
Managing Director: Manfred Duchrow

Zweigniederlassung Deutschland
Gartenstr. 48, 89150 Laichingen
Amtsgericht Ulm: HRB 5073
Gesch?ftsf?hrer: Manfred Duchrow
----------------------------------------
Tel:    +49 (0)7333 9232190
Fax:    +49 (0)7333 9232191
E-Mail: manfred.duchrow at caprica.de
========================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/9ffbcf30/attachment-0001.html 

From thomas.raehalme at aitiofinland.com  Fri Feb  5 09:22:55 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Fri, 5 Feb 2016 16:22:55 +0200
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAK-7U1iR4THBqw21dPs89s6otnhRaZbn+vBshb6maoA5HgHLLw@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
	<CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
	<CAJgngAfGC-e+j0c2AzM4YXUVSfV7yzzV0rThRGrhTicd6a5SaA@mail.gmail.com>
	<CAK-7U1iR4THBqw21dPs89s6otnhRaZbn+vBshb6maoA5HgHLLw@mail.gmail.com>
Message-ID: <CAPyAMoY0Nb7bdqbi2VP6xv=XcSrk2M5QEYkZ7PJYu95Rg+MvJQ@mail.gmail.com>

Hi,

On Fri, Feb 5, 2016 at 4:15 PM, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> yes I understand that - and I agree that falling back to the default
> client in case of a missing client is not a good idea.
>

I understand this as well, but it has not been uncommon to encounter a
situation where the user needs to know where to go next, because Keycloak
doesn't have a link available.

Maybe and hopefully it's just related to the development phase when
applications are redeployed often.



> @Thomas
> Initially I also thought about having a default redirect url per realm but
> then I thought that simply refering to a client_id and let keycloak
> redirect the user
> appropriatly would be more flexible, especially because you can then also
> leverage all the client metadata that is available for a client (name,
> description etc.).
>

Defining an existing client as a default is indeed a better idea. I
probably misunderstood you first.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/5797f415/attachment.html 

From thomas.darimont at googlemail.com  Fri Feb  5 09:28:16 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 5 Feb 2016 15:28:16 +0100
Subject: [keycloak-user] Realm wide custom id / access token claims.
In-Reply-To: <56B4AC2A.3020201@redhat.com>
References: <CAK-7U1hci0xcXQZa9LzWkAFYDa8W0EhmG5pd4V_JYtc3TwSG-w@mail.gmail.com>
	<56B4AC2A.3020201@redhat.com>
Message-ID: <CAK-7U1jk276kpvVhHY3ie3sRdJTigLxu+czsyAvOyqiCmCsdAQ@mail.gmail.com>

Hello Bill,

seems to do what I need - I think it should be documented that changes in
client templates (e.g. configured mappers) are reflected in created clients.

Cheers,
Thomas

2016-02-05 15:05 GMT+01:00 Bill Burke <bburke at redhat.com>:

> See ClientTemplates
>
>
>
> On 2/5/2016 7:59 AM, Thomas Darimont wrote:
>
> Hello group,
>
> In my user model I have a custom user attribute that I want to make
> available to multiple
> clients via the id / access token with just one definition. Is this
> already possible somehow?
>
> Currently one can define custom mappers for a single client via:
> (In Admin Console) Realm -> Clients -> example-client -> Mappers -> create
>
> There I can specify a new mapper of type "user attribute" where I can
> refer to the actual user attribute, give it a "token claim name" (e.g.
> "myattribute") and specify whether this should be included in the ID and /
> or access token.
>
> The user attribute in the token can then be accessed from within the
> client via:
> KeycloakSecurityContext:getIdToken().getOtherClaims().get("myattribute")
>
> This apporach however requires that I configure this for every client -
> for which I already have 10 (trend: upwards)...
> It would make thinks a lot easier if it were possible to specify those
> mappers realm wide...
>
> PS: I'm currently using Keycloak 1.9.0.CR1
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160205/7c53f76b/attachment.html 

From thomas.darimont at googlemail.com  Fri Feb  5 10:23:41 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 5 Feb 2016 16:23:41 +0100
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAPyAMoY0Nb7bdqbi2VP6xv=XcSrk2M5QEYkZ7PJYu95Rg+MvJQ@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
	<CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
	<CAJgngAfGC-e+j0c2AzM4YXUVSfV7yzzV0rThRGrhTicd6a5SaA@mail.gmail.com>
	<CAK-7U1iR4THBqw21dPs89s6otnhRaZbn+vBshb6maoA5HgHLLw@mail.gmail.com>
	<CAPyAMoY0Nb7bdqbi2VP6xv=XcSrk2M5QEYkZ7PJYu95Rg+MvJQ@mail.gmail.com>
Message-ID: <CAK-7U1iFcuOnFRcYkWB7xC7mRWoMJqnz=JLtBP7R9xWYw3xtBg@mail.gmail.com>

Hello,

2016-02-05 15:22 GMT+01:00 Thomas Raehalme <thomas.raehalme at aitiofinland.com
>:

> I understand this as well, but it has not been uncommon to encounter a
> situation where the user needs to know where to go next, because Keycloak
> doesn't have a link available.


with a redirect facility as outlined above - one could render a link to the
"$KEYCLOAK_BASE_URL/redirect" or
lookup the "default" client in order to render the client base url link
with a proper label (client name).

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/605a7de9/attachment.html 

From manfred.duchrow at caprica.biz  Fri Feb  5 10:51:58 2016
From: manfred.duchrow at caprica.biz (Manfred Duchrow)
Date: Fri, 5 Feb 2016 16:51:58 +0100
Subject: [keycloak-user] Class is swallowing exceptions
Message-ID: <56B4C51E.7070701@caprica.biz>

Hi,

I just got a "Failed to introspect token" result when trying to use this
new endpoint.
When I tried to find out what went wrong I observed that also no
additional log entry was available.
Looking at the code (1.8.0.Final) of class TokenIntrospectionEndpoint
revealed that in method
introspect() there is a try-catch that swallows all caught exception
information.

In methods
   private AccessToken toAccessToken(String tokenString)
   private void authorizeClient()
its the same pattern.
A new exception gets thrown without any information about the caught
exception.

You might consider opening an issue to add either some log statements in
all catch blocks of this class
or propagate the exception information in the new thrown exceptions.

So currently there is no chance to find out why an introspection request
failed.

Cheers,
  Manfred

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/40ea9950/attachment.html 

From thomas.darimont at googlemail.com  Fri Feb  5 13:05:41 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 5 Feb 2016 19:05:41 +0100
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAK-7U1iFcuOnFRcYkWB7xC7mRWoMJqnz=JLtBP7R9xWYw3xtBg@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
	<CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
	<CAJgngAfGC-e+j0c2AzM4YXUVSfV7yzzV0rThRGrhTicd6a5SaA@mail.gmail.com>
	<CAK-7U1iR4THBqw21dPs89s6otnhRaZbn+vBshb6maoA5HgHLLw@mail.gmail.com>
	<CAPyAMoY0Nb7bdqbi2VP6xv=XcSrk2M5QEYkZ7PJYu95Rg+MvJQ@mail.gmail.com>
	<CAK-7U1iFcuOnFRcYkWB7xC7mRWoMJqnz=JLtBP7R9xWYw3xtBg@mail.gmail.com>
Message-ID: <CAK-7U1g_J9fQs5gc3TW4jCT_TLaxdp2SOMbbyphuKmojauZQ1A@mail.gmail.com>

Quick update - I did some further experiments with this...

I added /redirect path to the a
org.keycloak.services.resources.RealmsResource
like: @Path("{realm}/{client-id}/redirect")
see code fragment below.

This allows keycloak to initiate a redirect to the browser with the actual
target url of the client. Other clients now only need to now the realm and
clientId
to generate a link that eventually redirects to the target application.

Usage:
GET http://localhost:8081/auth/realms/master/launchpad/redirect -> 302
response with location: http://apps.corp.local/launchpad

Any chance to get this in as a PR?

Cheers,
Thomas

    @GET
    @Path("{realm}/{client-id}/redirect")
    public Response getRedirect(final @PathParam("realm") String realmName,
final @PathParam("client-id") String clientId) throws Exception{

        RealmModel realm = init(realmName);

        if (realm == null){
            return null;
        }

        ClientModel client = realm.getClientByClientId(clientId);

        if (client == null){
            return null;
        }

        if (client.getRootUrl() == null){
            return
Response.temporaryRedirect(uriInfo.getAbsolutePathBuilder().replacePath(client.getBaseUrl()).build()).build();
        }

        return Response.temporaryRedirect(URI.create(client.getRootUrl() +
client.getBaseUrl())).build();
    }

2016-02-05 16:23 GMT+01:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> Hello,
>
> 2016-02-05 15:22 GMT+01:00 Thomas Raehalme <
> thomas.raehalme at aitiofinland.com>:
>
>> I understand this as well, but it has not been uncommon to encounter a
>> situation where the user needs to know where to go next, because Keycloak
>> doesn't have a link available.
>
>
> with a redirect facility as outlined above - one could render a link to
> the "$KEYCLOAK_BASE_URL/redirect" or
> lookup the "default" client in order to render the client base url link
> with a proper label (client name).
>
> Cheers,
> Thomas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/370c4362/attachment-0001.html 

From m.hayen at first8.nl  Fri Feb  5 14:09:03 2016
From: m.hayen at first8.nl (Mark Hayen)
Date: Fri, 5 Feb 2016 20:09:03 +0100
Subject: [keycloak-user] changes in Email SPI
In-Reply-To: <CAJgngAehty4Uwr4B2Mn5Ls1GkLLm1=UEaggcS+TF+_OMF6zr+w@mail.gmail.com>
References: <56B48ED1.9080404@first8.nl>
	<CAJgngAehty4Uwr4B2Mn5Ls1GkLLm1=UEaggcS+TF+_OMF6zr+w@mail.gmail.com>
Message-ID: <56B4F34F.4010301@first8.nl>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160205/d1ddb072/attachment.html 

From malmi.suh at gmail.com  Fri Feb  5 22:03:38 2016
From: malmi.suh at gmail.com (Malmi Samarasinghe)
Date: Sat, 6 Feb 2016 08:33:38 +0530
Subject: [keycloak-user] Assign Role Fails Just After Creating the Role
In-Reply-To: <56B4A6CB.3020507@redhat.com>
References: <CAL_Nbcn-tvKSEwM6f5hEaXeObhajupzUnpRvoMCBoNr5YwLjpQ@mail.gmail.com>
	<56AB7318.6050009@redhat.com>
	<CAL_Nbcm+DrkjsHBYyaP__dr1=KCyE8PM7-bwYe=NtEXs57uqcQ@mail.gmail.com>
	<CAJgngAf2BBTHnykwzYsSww-HeMOmor4kNuUHekba1-MBjzCLbg@mail.gmail.com>
	<CAL_NbcnU+Qa=EXkqELYbhE57UhFoytdgO996kM8XCrHJC31_FA@mail.gmail.com>
	<56B2C5D5.8050702@redhat.com>
	<CAL_NbckNb2H8A5aGzfPPMjzx2Ggk16uhHZpmmBcXibCc_WqvWQ@mail.gmail.com>
	<CAJgngAd_t-hE3y1itAZ6rBHfT7ZNh+rm7T6zqeJWT5MjZSs87A@mail.gmail.com>
	<CAL_Nbcn46D9b_ttV6jUkSxt5Msc4bMNeXCNmsuBxCA2PRCoDVQ@mail.gmail.com>
	<CAL_NbcmKYy7Du=tfMAuMS_pGNySQ=EDrtbdejw41e0_W8E8_YA@mail.gmail.com>
	<CAJgngAcf4RtoS__nf4KtpRBQ0DCWnOWhkECiaLhgK7ioWMq01Q@mail.gmail.com>
	<CAL_Nbcnt8tdruqK3=+RzX+E5RjqJiT_vQfixGgLrVAvQDa2_VQ@mail.gmail.com>
	<CAJgngAffrAE1+P315PHAoF2stOnDdKV=kRAcA-1rFHAMvEKo1w@mail.gmail.com>
	<CAL_Nbc=RYFunMG9aAcf4N3tLSUV8pm7riUaS0zk+5yM7FxXhmw@mail.gmail.com>
	<56B4A6CB.3020507@redhat.com>
Message-ID: <CAL_NbckoRV4kxeMoBdm2dLEje+h_M7j6_45koEQgugS1S=XDfA@mail.gmail.com>

Many Thanks to your assistance regarding the issue.

On Fri, Feb 5, 2016 at 7:12 PM, Bill Burke <bburke at redhat.com> wrote:

> 1.9.0.Final will have it...
>
>
> On 2/5/2016 7:50 AM, Malmi Samarasinghe wrote:
>
> Hi Stian,
>
> Thank you very much for looking in to the issue. We tried with around 6
> role creations per second, and I tried switching off realm cache and it had
> negative impact on the performance of other API s.
>
> Really appreciate if you could suggest us a rough timeline for a fix date.
>
> Regards,
> Malmi
>
> On Fri, Feb 5, 2016 at 3:20 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Either don't create roles concurrently or disable cache.
>>
>> How frequently are you creating roles? Just wondering because if you do
>> it will significantly impact the benefits of the cache as we invalidate a
>> large amount of the cache when roles are added/removed.
>>
>> The problem you are seeing is most likely down to a race condition when
>> the realm role list (or client role lists) are re-loaded after they are
>> invalidated. I haven't had much time to look at it yet, so I don't know the
>> exact cause or a solution.
>>
>> On 5 February 2016 at 09:57, Malmi Samarasinghe < <malmi.suh at gmail.com>
>> malmi.suh at gmail.com> wrote:
>>
>>> Hi Stian,
>>>
>>> We have this in production is there any intermediary fix that we can do
>>> or any workaround?
>>>
>>> Regards,
>>> Malmi
>>>
>>> On Fri, Feb 5, 2016 at 2:11 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Confirmed this bug  <https://issues.jboss.org/browse/KEYCLOAK-2458>
>>>> https://issues.jboss.org/browse/KEYCLOAK-2458
>>>>
>>>> On 5 February 2016 at 06:53, Malmi Samarasinghe < <malmi.suh at gmail.com>
>>>> malmi.suh at gmail.com> wrote:
>>>>
>>>>> Hi Stian/Bill,
>>>>>
>>>>> I just wanted to highlight that this issue only occurred when realm
>>>>> cache enabled option is ON.
>>>>>
>>>>> Regards,
>>>>> Malmi
>>>>>
>>>>> On Thu, Feb 4, 2016 at 8:38 PM, Malmi Samarasinghe <
>>>>> <malmi.suh at gmail.com>malmi.suh at gmail.com> wrote:
>>>>>
>>>>>> Hi Stian
>>>>>>
>>>>>> I have multiple threads creating different roles. Basically one
>>>>>> thread will execute all three apis one after another.
>>>>>>
>>>>>> Regards,
>>>>>> Malmi
>>>>>>
>>>>>> On Thu, Feb 4, 2016 at 5:23 PM, Stian Thorgersen <
>>>>>> <sthorger at redhat.com>sthorger at redhat.com> wrote:
>>>>>>
>>>>>>> When you say method1 is executed in multiple threads, do you mean
>>>>>>> one thread creates the role and another retrieves it? Or do you have
>>>>>>> multiple threads creating different roles?
>>>>>>>
>>>>>>> On 4 February 2016 at 12:31, Malmi Samarasinghe <
>>>>>>> <malmi.suh at gmail.com>malmi.suh at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Bill,
>>>>>>>>
>>>>>>>> Please find the work flow that we have implemented
>>>>>>>> create user : POST : admin/realms/{realm}/users
>>>>>>>>
>>>>>>>> *Method1* wrapps the following API calls
>>>>>>>> Create Realm role : POST : admin/realms/{realm}/roles
>>>>>>>> Retrieve Role : GET : admin/realms/{realm}/roles/{roleName}
>>>>>>>> Assign Role : POST :
>>>>>>>> admin/realms/leapset/users/{0}/role-mappings/realm
>>>>>>>>
>>>>>>>> Same for the client roles as well.
>>>>>>>>
>>>>>>>> *Method1 *is executed in multiple threads and assign reams role
>>>>>>>> API starts failing with 404 (keycloak log states role not found)
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Malmi
>>>>>>>>
>>>>>>>> On Thu, Feb 4, 2016 at 9:00 AM, Bill Burke < <bburke at redhat.com>
>>>>>>>> bburke at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Can you give me what REST invocations you are doing? How do you
>>>>>>>>> find the role?  How do you create the role? etc...
>>>>>>>>>
>>>>>>>>> On 2/3/2016 9:45 PM, Malmi Samarasinghe wrote:
>>>>>>>>>
>>>>>>>>> Hi Bill,
>>>>>>>>>
>>>>>>>>> We tried the above fix on top of 1.7.0 by applying the changes
>>>>>>>>> from the commits attached to the
>>>>>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327 and deployed, and
>>>>>>>>> it seems to have the same issue. If you have any further update on this
>>>>>>>>> please let us know.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Malmi
>>>>>>>>>
>>>>>>>>> On Mon, Feb 1, 2016 at 4:02 PM, Stian Thorgersen <
>>>>>>>>> <sthorger at redhat.com>sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> This could be related to
>>>>>>>>>> <https://issues.jboss.org/browse/KEYCLOAK-2327>
>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2327.
>>>>>>>>>>
>>>>>>>>>> It's already fixed in master, so if you can try it out that would
>>>>>>>>>> be great. We should also have a 1.8.1.Final release this week with the fix
>>>>>>>>>> in as well.
>>>>>>>>>>
>>>>>>>>>> On 30 January 2016 at 05:16, Malmi Samarasinghe <
>>>>>>>>>> <malmi.suh at gmail.com>malmi.suh at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Bill,
>>>>>>>>>>>
>>>>>>>>>>> We are using keycloak 1.7.0 and rdbms (mysql)
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Malmi Samarasinghe
>>>>>>>>>>> On Jan 29, 2016 7:41 PM, "Bill Burke" < <bburke at redhat.com>
>>>>>>>>>>> bburke at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Which version of keycloak?  RDBMS or Mongo?
>>>>>>>>>>>>
>>>>>>>>>>>> On 1/29/2016 12:35 AM, Malmi Samarasinghe wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>>
>>>>>>>>>>>> In my application we create retrieve and assign role
>>>>>>>>>>>> subsequently and it seems that even for a small load (2-3 threads) with
>>>>>>>>>>>> realm cache enabled option, assign realm role call fails due to role not
>>>>>>>>>>>> exist error and 404 is returned from keycloak.
>>>>>>>>>>>>
>>>>>>>>>>>> With the realm cache disabled option the load works fine.
>>>>>>>>>>>>
>>>>>>>>>>>> Please get back to me if you have any information on any other
>>>>>>>>>>>> option we can follow to get this issue sorted or on what action the realm
>>>>>>>>>>>> cache will be persisted to DB.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Malmi
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Bill Burke
>>>>>>>>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>> <keycloak-user at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>> <keycloak-user at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Bill Burke
>>>>>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160206/4c1e25c7/attachment-0001.html 

From leo.nunes at gjccorp.com.br  Sat Feb  6 08:53:56 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Sat, 6 Feb 2016 13:53:56 +0000
Subject: [keycloak-user] NoClassDefFoundError during Logout (Domain Mode)
Message-ID: <D2DB8F52.26422%leo.nunes@ojc.com.br>

Hi, i'm getting the exception below when I try to logout from my aplication or when I click Logout All from the Sessions menu at the admin console.

I'm using the Overlay keycloak-overlay-eap6-1.8.1.Final on our EAP 6.3.3 in Domain Mode with 2 hosts.
I copied the modules from the overlay zip to our modules in the EAP folder. Then, I did the installation with jboss-cli.

The Admin Console is working fine. I deployed the customer-app at another server and i'm able to register and login succssesfully.
Then, when I try to logout I get the error below.


>>>>>>>>

2016-02-06 11:47:13,502 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[eap-corp-dev].[/auth].[Keycloak REST Interface]] (ajp-/192.168.10.67:8019-2) JBWEB000236: Servlet.service() for servlet Keycloak REST Interface threw exception: java.lang.RuntimeException: request path: /auth/admin/realms/demo/logout-all
at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:75) [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
Caused by: org.jboss.resteasy.spi.UnhandledException: org.jboss.resteasy.spi.ApplicationException: java.lang.NoClassDefFoundError: org/apache/http/conn/socket/LayeredConnectionSocketFactory
at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:365) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:233) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:209) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:557) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61) [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
... 15 more
Caused by: org.jboss.resteasy.spi.ApplicationException: java.lang.NoClassDefFoundError: org/apache/http/conn/socket/LayeredConnectionSocketFactory
at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:69) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at com.sun.proxy.$Proxy206.getProvider(Unknown Source)
at org.keycloak.services.managers.ResourceAdminManager.sendLogoutRequest(ResourceAdminManager.java:235) [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
at org.keycloak.services.managers.ResourceAdminManager.logoutClient(ResourceAdminManager.java:220) [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
at org.keycloak.services.managers.ResourceAdminManager.logoutAll(ResourceAdminManager.java:196) [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
at org.keycloak.services.resources.admin.RealmAdminResource.logoutAll(RealmAdminResource.java:338) [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
... 24 more
Caused by: java.lang.NoClassDefFoundError: org/apache/http/conn/socket/LayeredConnectionSocketFactory
at org.keycloak.connections.httpclient.DefaultHttpClientFactory.lazyInit(DefaultHttpClientFactory.java:120)
at org.keycloak.connections.httpclient.DefaultHttpClientFactory.create(DefaultHttpClientFactory.java:36)
at org.keycloak.connections.httpclient.DefaultHttpClientFactory.create(DefaultHttpClientFactory.java:27)
at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:57) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
... 41 more
Caused by: java.lang.ClassNotFoundException: org.apache.http.conn.socket.LayeredConnectionSocketFactory from [Module "org.keycloak.keycloak-connections-http-client:main" from local module loader @543c6f6d (finder: local module finder @13eb8acf (roots: /opt/jboss-eap-6.3/modules,/opt/jboss-eap-6.3/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.3.3.CP,/opt/jboss-eap-6.3/modules/system/layers/base,/var/opt/jboss_domains/modules))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.5.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.5.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.5.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.5.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.5.Final-redhat-1]
... 50 more



--
Leonardo Nunes


________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160206/eca12eb1/attachment-0001.html 

From sthorger at redhat.com  Mon Feb  8 02:57:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 8 Feb 2016 08:57:09 +0100
Subject: [keycloak-user] Class is swallowing exceptions
In-Reply-To: <56B4C51E.7070701@caprica.biz>
References: <56B4C51E.7070701@caprica.biz>
Message-ID: <CAJgngAf3BNiorRX6HahPJjXdgZsJUroZEgzuyz3xa2Bo03_xag@mail.gmail.com>

Please create a JIRA

On 5 February 2016 at 16:51, Manfred Duchrow <manfred.duchrow at caprica.biz>
wrote:

> Hi,
>
> I just got a "Failed to introspect token" result when trying to use this
> new endpoint.
> When I tried to find out what went wrong I observed that also no
> additional log entry was available.
> Looking at the code (1.8.0.Final) of class TokenIntrospectionEndpoint
> revealed that in method
> introspect() there is a try-catch that swallows all caught exception
> information.
>
> In methods
>    private AccessToken toAccessToken(String tokenString)
>    private void authorizeClient()
> its the same pattern.
> A new exception gets thrown without any information about the caught
> exception.
>
> You might consider opening an issue to add either some log statements in
> all catch blocks of this class
> or propagate the exception information in the new thrown exceptions.
>
> So currently there is no chance to find out why an introspection request
> failed.
>
> Cheers,
>   Manfred
>
>
> _______________________________________________
> 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/20160208/7bf39038/attachment.html 

From sthorger at redhat.com  Mon Feb  8 04:29:32 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 8 Feb 2016 10:29:32 +0100
Subject: [keycloak-user] Keycloak saml v1.1 to oauth2 token
In-Reply-To: <CAHa5F_sYXAiYBhrwPyrDSAh-zhtVe0GR+sKEXw7kZDuD-CxXOg@mail.gmail.com>
References: <CAHa5F_sYXAiYBhrwPyrDSAh-zhtVe0GR+sKEXw7kZDuD-CxXOg@mail.gmail.com>
Message-ID: <CAJgngAfxh2C0RvK29mBYp0MFg=GwiW+yk1VDLYEgr7W7Xmnffw@mail.gmail.com>

We don't have a token exchange facility, but we have support for
authenticating with external IdPs through what we call identity brokering.
It supports SAMLv2 IdPs only though.

We do have SPIs that let you customize/extend Keycloak. For your use-case I
could think of two options:
1. Add a custom authenticator for direct grant flow that allows
authenticating by passing a SAML v1.1 token  - see
http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html
for more info
2. Add a custom identity broker provider that allows users to login through
an external SAMLv1.1 IdP

On 5 February 2016 at 10:52, Porfyrios Vasileiou <
porfyrios.vasileiou at gmail.com> wrote:

> Hello, I have a project that includes 2 client applications.
>
> In ONLY ONE of the clients(web application in angular) users login via a
> 3rd party authorization server that also has a login procedure where the
> user logs in and it returns an saml v1.1 xml token and then they can access
> the client. (This procedure cannot be changed) But i want this client to
> also be secured with keycloak so i can have a token that i can pass to my
> rest services that are also secured with keycloak.
>
> Can i convert this saml v1.1 token to oauth2 via keycloak?
>
> Once we have logged in I want to login this user to keycloak
> programmatically and get an oauth2 token instead that can be used for the
> rest services requests in the  Bearer authentication header. How can i do
> this?
>
> I also want to say that the keycloak is setup to use the same active
> directory that the 3rd party authorization server is using to authenticate
> the users.
>
> Is this possible?
>
> Thanks, Porfyrios
>
> _______________________________________________
> 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/20160208/22d8974e/attachment.html 

From andrey.saroul at gmail.com  Mon Feb  8 04:30:59 2016
From: andrey.saroul at gmail.com (Andrey Saroul)
Date: Mon, 8 Feb 2016 12:30:59 +0300
Subject: [keycloak-user] Keycloak logout flow
In-Reply-To: <CAJgngAccWZtbRBYjLhtOxBjS8iWY+hN+wxFiE6cdd6j9=kzq7w@mail.gmail.com>
References: <CAFZbuCMQwkS-2nwQmSscqv6JYO_vrHF1PFx=pmRn5rV_L1_k0A@mail.gmail.com>
	<CAJgngAccWZtbRBYjLhtOxBjS8iWY+hN+wxFiE6cdd6j9=kzq7w@mail.gmail.com>
Message-ID: <CAFZbuCODBtTk3x5nhaNTqcULBBsvERc1Yq72dO57qAE5S2e7gA@mail.gmail.com>

Thanks, it was the right reason.

2016-02-02 15:55 GMT+03:00 Stian Thorgersen <sthorger at redhat.com>:

> You probably haven't configured admin url for your client so the Keycloak
> server can't send backchannel logout to your service
>
> On 2 February 2016 at 12:06, Andrey Saroul <andrey.saroul at gmail.com>
> wrote:
>
>> I'm using keycloak 1.7.0 with WildFly 9.0.2
>> I have rest service and Keycloak deployed on one the same machine.
>> Consider this scenario:
>> 1) In browser i try to test my rest service (e.g.
>> http://my-ip-address:8080/rest/test) secured under Keycloak
>> 2) I got redirect to login page.
>> 3) I enter my login and password.
>> 4) I got some response from my rest service. That's Ok!
>> 5) Then I go to Keycloak admin console, find my user and force session
>> logout.
>> 6) Then I try to access my rest service again by the same url, and NO
>> redirect happens. Browser caches jsessionid cookie and don't know anything
>> about user beeing logout.
>> It seems to my that during step #6 server should invalidate expired
>> session cookie due to admin logout.
>> I considere that user after beeing logout will get redirect to login page
>> again, and will not be able to access service with old jsessionid cookie.
>> Is this a bug, or could you help me explain what am i doing wrong?
>>
>> _______________________________________________
>> 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/20160208/cfb8e05b/attachment.html 

From mstrukel at redhat.com  Mon Feb  8 05:27:55 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Mon, 8 Feb 2016 11:27:55 +0100
Subject: [keycloak-user] NoClassDefFoundError during Logout (Domain Mode)
In-Reply-To: <D2DB8F52.26422%leo.nunes@ojc.com.br>
References: <D2DB8F52.26422%leo.nunes@ojc.com.br>
Message-ID: <CA+1OW+iXXeRAKE7xOq6UNrMggmsgOXFL+je3e4hpUX=-L4Pnng@mail.gmail.com>

Server overlay is only supposed to be used with latest EAP 6 version.
But ATM it should work on EAP 6.4, and above.

Your error suggests the org.apache.httpcomponents module is too old.
And in fact EAP 6.3 uses httpclient 4.2.1, whereas Keycloak server
depends on version 4.3.6.

On Sat, Feb 6, 2016 at 2:53 PM, LEONARDO NUNES <leo.nunes at gjccorp.com.br> wrote:
> Hi, i'm getting the exception below when I try to logout from my aplication
> or when I click Logout All from the Sessions menu at the admin console.
>
> I'm using the Overlay keycloak-overlay-eap6-1.8.1.Final on our EAP 6.3.3 in
> Domain Mode with 2 hosts.
> I copied the modules from the overlay zip to our modules in the EAP folder.
> Then, I did the installation with jboss-cli.
>
> The Admin Console is working fine. I deployed the customer-app at another
> server and i'm able to register and login succssesfully.
> Then, when I try to logout I get the error below.
>
>
>>>>>>>>>
>
> 2016-02-06 11:47:13,502 ERROR
> [org.apache.catalina.core.ContainerBase.[jboss.web].[eap-corp-dev].[/auth].[Keycloak
> REST Interface]] (ajp-/192.168.10.67:8019-2) JBWEB000236: Servlet.service()
> for servlet Keycloak REST Interface threw exception:
> java.lang.RuntimeException: request path: /auth/admin/realms/demo/logout-all
> at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:75)
> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
> at
> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
> at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> Caused by: org.jboss.resteasy.spi.UnhandledException:
> org.jboss.resteasy.spi.ApplicationException: java.lang.NoClassDefFoundError:
> org/apache/http/conn/socket/LayeredConnectionSocketFactory
> at
> org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:365)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:233)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:209)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:557)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> ... 15 more
> Caused by: org.jboss.resteasy.spi.ApplicationException:
> java.lang.NoClassDefFoundError:
> org/apache/http/conn/socket/LayeredConnectionSocketFactory
> at
> org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:69)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at com.sun.proxy.$Proxy206.getProvider(Unknown Source)
> at
> org.keycloak.services.managers.ResourceAdminManager.sendLogoutRequest(ResourceAdminManager.java:235)
> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> at
> org.keycloak.services.managers.ResourceAdminManager.logoutClient(ResourceAdminManager.java:220)
> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> at
> org.keycloak.services.managers.ResourceAdminManager.logoutAll(ResourceAdminManager.java:196)
> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> at
> org.keycloak.services.resources.admin.RealmAdminResource.logoutAll(RealmAdminResource.java:338)
> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.8.0_45]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [rt.jar:1.8.0_45]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_45]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
> at
> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> ... 24 more
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/http/conn/socket/LayeredConnectionSocketFactory
> at
> org.keycloak.connections.httpclient.DefaultHttpClientFactory.lazyInit(DefaultHttpClientFactory.java:120)
> at
> org.keycloak.connections.httpclient.DefaultHttpClientFactory.create(DefaultHttpClientFactory.java:36)
> at
> org.keycloak.connections.httpclient.DefaultHttpClientFactory.create(DefaultHttpClientFactory.java:27)
> at
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.8.0_45]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [rt.jar:1.8.0_45]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_45]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
> at
> org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:57)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> ... 41 more
> Caused by: java.lang.ClassNotFoundException:
> org.apache.http.conn.socket.LayeredConnectionSocketFactory from [Module
> "org.keycloak.keycloak-connections-http-client:main" from local module
> loader @543c6f6d (finder: local module finder @13eb8acf (roots:
> /opt/jboss-eap-6.3/modules,/opt/jboss-eap-6.3/modules/system/layers/base/.overlays/layer-base-jboss-eap-6.3.3.CP,/opt/jboss-eap-6.3/modules/system/layers/base,/var/opt/jboss_domains/modules))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> [jboss-modules.jar:1.3.5.Final-redhat-1]
> at
> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> [jboss-modules.jar:1.3.5.Final-redhat-1]
> at
> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> [jboss-modules.jar:1.3.5.Final-redhat-1]
> at
> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> [jboss-modules.jar:1.3.5.Final-redhat-1]
> at
> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> [jboss-modules.jar:1.3.5.Final-redhat-1]
> ... 50 more
>
>
>
> --
> Leonardo Nunes
>
>
> ________________________________
> Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc?
> n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o
> poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar
> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por
> engano, por favor avise imediatamente o remetente, respondendo o e-mail e em
> seguida apague-o. Agradecemos sua coopera??o.
>
> This message may contain confidential and/or privileged information. If you
> are not the addressee or authorized to receive this for the addressee, you
> must not use, copy, disclose or take any action based on this message or any
> information herein. If you have received this message in error, please
> advise the sender immediately by reply e-mail and delete this message. Thank
> you for your cooperation
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From parul.com at gmail.com  Mon Feb  8 11:57:43 2016
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Mon, 8 Feb 2016 22:27:43 +0530
Subject: [keycloak-user] do we have reference document for enabling ECP on
	keycloak
Message-ID: <CAFj68vWsz8VUCKXrdc-oSo0nQUaCsgyk8vgs4fn9N06LbHy_kw@mail.gmail.com>

Hi All,
do we have any reference document for keycloak IDP ECP profile?

Thanks,
Arul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160208/5789885f/attachment.html 

From srossillo at smartling.com  Mon Feb  8 12:16:45 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 8 Feb 2016 12:16:45 -0500
Subject: [keycloak-user] access_token always contains JWT
In-Reply-To: <56B4AF04.4080608@caprica.biz>
References: <CAJgngAe8x1nNYUvF2sz6UhtMSXdCpY0O4i34=NDfWpZCpP+hjQ@mail.gmail.com>
	<355538146.1756649.1454676424011.JavaMail.yahoo@mail.yahoo.com>
	<56B4AF04.4080608@caprica.biz>
Message-ID: <E13F86C3-409C-4351-A972-A0872D274D95@smartling.com>

Opaque access tokens are an interesting idea for security reasons. I?ve heard them referred to as "by reference" access tokens because the actual JWT access token has to be stored somewhere. The OpenID spec doesn?t address this but it?s a solid idea for access tokens exposed to external applications, which do not need to be concerned with, or possibly shouldn?t be privy to the information inside the token.

There?s another option that may be more manageable. That is to offer a per client option of encrypting the access token, known as JWE, or JSON Web Encryption[0]. The basic idea is that the signed token is then encrypted with a symmetrical key. This key would probably be a realm level key. Another benefit or JWE is the access token payload is compressed, making the access token shorter.

Is this something we would be interested in adding support for?

[0]: https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Feb 5, 2016, at 9:17 AM, manfred.duchrow at caprica.biz wrote:
> 
> Yes, that's true (even for some open source software too).
> So am I supposed to put this JWT access token into the Authorization request header as Bearer value to authorize a request?
> The access token I got from Keycloak is over 5000 characters long!
> 
> 
> On 05.02.2016 13:47, Raghuram Prabhala wrote:
>> Access token is implementation specific. Some commercial software have the concept of "reference tokens" which are nothing but random strings indicated below. The clients have to query back the Authorization server to get a validated JWT token
>> 
>> 
>> 
>> From: Stian Thorgersen <sthorger at redhat.com> <mailto:sthorger at redhat.com>
>> To: manfred.duchrow at caprica.biz <mailto:manfred.duchrow at caprica.biz> 
>> Cc: keycloak-user <keycloak-user at lists.jboss.org> <mailto:keycloak-user at lists.jboss.org>
>> Sent: Friday, February 5, 2016 7:10 AM
>> Subject: Re: [keycloak-user] access_token always contains JWT
>> 
>> There's no such thing as a "simple token". Tokens are always a signed JWT.
>> 
>> On 5 February 2016 at 11:17, < <mailto:manfred.duchrow at caprica.biz>manfred.duchrow at caprica.biz <mailto:manfred.duchrow at caprica.biz>> wrote:
>> Hi,
>> 
>> I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
>> service account by
>> POST /auth/realms/myrealm/protocol/openid-connect/token
>> with grant_type=client_credentials.
>> 
>> The result contains a signed JWT as value of field "access_token" rather
>> than a simple token
>> as described in chapter 18 (Service Accounts) of the user guide.
>> 
>> So what I expect (need) is a response like this:
>> 
>> {
>>     "access_token":"2YotnFZFEjr1zCsicMWpAA",
>>     "token_type":"bearer",
>>     "expires_in":60,
>>     "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>>     "refresh_expires_in":600,
>>     "id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>>     "not-before-policy":0,
>>     "session-state":"234234-234234-234234"
>> }
>> 
>> Is there a way to configure the account or the realm to return a simple
>> token
>> in "access_token" (and "refresh_token") rather than a JWT?
>> 
>> Cheers,
>>   Manfred
>> 
>> 
>> 
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>> 
>> 
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>> 
> 
> -- 
> ========================================
> Caprica Ltd.
> 69 Great Hampton Street
> Birmingham, West Midlands, B186EW, 
> Registered in England and Wales
> Company No. 5298548
> Managing Director: Manfred Duchrow
> 
> Zweigniederlassung Deutschland
> Gartenstr. 48, 89150 Laichingen
> Amtsgericht Ulm: HRB 5073
> Gesch?ftsf?hrer: Manfred Duchrow
> ----------------------------------------
> Tel:    +49 (0)7333 9232190
> Fax:    +49 (0)7333 9232191
> E-Mail: manfred.duchrow at caprica.de <mailto:manfred.duchrow at caprica.de>
> ========================================
> _______________________________________________
> 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/20160208/676b0a6e/attachment.html 

From bburke at redhat.com  Mon Feb  8 12:22:25 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 8 Feb 2016 12:22:25 -0500
Subject: [keycloak-user] access_token always contains JWT
In-Reply-To: <E13F86C3-409C-4351-A972-A0872D274D95@smartling.com>
References: <CAJgngAe8x1nNYUvF2sz6UhtMSXdCpY0O4i34=NDfWpZCpP+hjQ@mail.gmail.com>
	<355538146.1756649.1454676424011.JavaMail.yahoo@mail.yahoo.com>
	<56B4AF04.4080608@caprica.biz>
	<E13F86C3-409C-4351-A972-A0872D274D95@smartling.com>
Message-ID: <56B8CED1.2000003@redhat.com>

Yes.  We want that.  Just too busy :)

On 2/8/2016 12:16 PM, Scott Rossillo wrote:
> Opaque access tokens are an interesting idea for security reasons. 
> I?ve heard them referred to as "by reference" access tokens because 
> the actual JWT access token has to be stored somewhere. The OpenID 
> spec doesn?t address this but it?s a solid idea for access tokens 
> exposed to external applications, which do not need to be concerned 
> with, or possibly shouldn?t be privy to the information inside the token.
>
> There?s another option that may be more manageable. That is to offer a 
> per client option of encrypting the access token, known as JWE, or 
> JSON Web Encryption[0]. The basic idea is that the signed token is 
> then encrypted with a symmetrical key. This key would probably be a 
> realm level key. Another benefit or JWE is the access token payload is 
> compressed, making the access token shorter.
>
> Is this something we would be interested in adding support for?
>
> [0]: https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com <mailto:srossillo at smartling.com>
>
>> On Feb 5, 2016, at 9:17 AM, manfred.duchrow at caprica.biz 
>> <mailto:manfred.duchrow at caprica.biz> wrote:
>>
>> Yes, that's true (even for some open source software too).
>> So am I supposed to put this JWT access token into the Authorization 
>> request header as Bearer value to authorize a request?
>> The access token I got from Keycloak is over 5000 characters long!
>>
>>
>> On 05.02.2016 13:47, Raghuram Prabhala wrote:
>>> Access token is implementation specific. Some commercial software 
>>> have the concept of "reference tokens" which are nothing but random 
>>> strings indicated below. The clients have to query back the 
>>> Authorization server to get a validated JWT token
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Stian Thorgersen <sthorger at redhat.com>
>>> *To:* manfred.duchrow at caprica.biz
>>> *Cc:* keycloak-user <keycloak-user at lists.jboss.org>
>>> *Sent:* Friday, February 5, 2016 7:10 AM
>>> *Subject:* Re: [keycloak-user] access_token always contains JWT
>>>
>>> There's no such thing as a "simple token". Tokens are always a 
>>> signed JWT.
>>>
>>> On 5 February 2016 at 11:17, <manfred.duchrow at caprica.biz> wrote:
>>>
>>>     Hi,
>>>
>>>     I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
>>>     service account by
>>>     POST /auth/realms/myrealm/protocol/openid-connect/token
>>>     with grant_type=client_credentials.
>>>
>>>     The result contains a signed JWT as value of field "access_token" rather
>>>     than a simple token
>>>     as described in chapter 18 (Service Accounts) of the user guide.
>>>
>>>     So what I expect (need) is a response like this:
>>>
>>>     {
>>>          "access_token":"2YotnFZFEjr1zCsicMWpAA",
>>>          "token_type":"bearer",
>>>          "expires_in":60,
>>>          "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>>>          "refresh_expires_in":600,
>>>          "id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
>>>          "not-before-policy":0,
>>>          "session-state":"234234-234234-234234"
>>>     }
>>>
>>>     Is there a way to configure the account or the realm to return a simple
>>>     token
>>>     in "access_token" (and "refresh_token") rather than a JWT?
>>>
>>>     Cheers,
>>>        Manfred
>>>
>>>
>>>
>>>     _______________________________________________
>>>     keycloak-user mailing list
>>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>
>> -- 
>> ========================================
>> Caprica Ltd.
>> 69 Great Hampton Street
>> Birmingham, West Midlands, B186EW,
>> Registered in England and Wales
>> Company No. 5298548
>> Managing Director: Manfred Duchrow
>>
>> Zweigniederlassung Deutschland
>> Gartenstr. 48, 89150 Laichingen
>> Amtsgericht Ulm: HRB 5073
>> Gesch?ftsf?hrer: Manfred Duchrow
>> ----------------------------------------
>> Tel:    +49 (0)7333 9232190
>> Fax:    +49 (0)7333 9232191
>> E-Mail:manfred.duchrow at caprica.de
>> ========================================
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160208/970431fe/attachment-0001.html 

From pblair at clearme.com  Mon Feb  8 14:22:48 2016
From: pblair at clearme.com (Paul Blair)
Date: Mon, 8 Feb 2016 19:22:48 +0000
Subject: [keycloak-user] access_token always contains JWT
In-Reply-To: <56B8CED1.2000003@redhat.com>
References: <CAJgngAe8x1nNYUvF2sz6UhtMSXdCpY0O4i34=NDfWpZCpP+hjQ@mail.gmail.com>
	<355538146.1756649.1454676424011.JavaMail.yahoo@mail.yahoo.com>
	<56B4AF04.4080608@caprica.biz>
	<E13F86C3-409C-4351-A972-A0872D274D95@smartling.com>
	<56B8CED1.2000003@redhat.com>
Message-ID: <D2DE551A.116E9%pblair@clearme.com>

+1 on this, but I understand the time constraints.

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>>
Date: Monday, February 8, 2016 at 12:22 PM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] access_token always contains JWT

Yes.  We want that.  Just too busy :)

On 2/8/2016 12:16 PM, Scott Rossillo wrote:
Opaque access tokens are an interesting idea for security reasons. I've heard them referred to as "by reference" access tokens because the actual JWT access token has to be stored somewhere. The OpenID spec doesn't address this but it's a solid idea for access tokens exposed to external applications, which do not need to be concerned with, or possibly shouldn't be privy to the information inside the token.

There's another option that may be more manageable. That is to offer a per client option of encrypting the access token, known as JWE, or JSON Web Encryption[0]. The basic idea is that the signed token is then encrypted with a symmetrical key. This key would probably be a realm level key. Another benefit or JWE is the access token payload is compressed, making the access token shorter.

Is this something we would be interested in adding support for?

[0]: https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com<mailto:srossillo at smartling.com>

On Feb 5, 2016, at 9:17 AM, <mailto:manfred.duchrow at caprica.biz> manfred.duchrow at caprica.biz<mailto:manfred.duchrow at caprica.biz> wrote:

Yes, that's true (even for some open source software too).
So am I supposed to put this JWT access token into the Authorization request header as Bearer value to authorize a request?
The access token I got from Keycloak is over 5000 characters long!


On 05.02.2016 13:47, Raghuram Prabhala wrote:
Access token is implementation specific. Some commercial software have the concept of "reference tokens" which are nothing but random strings indicated below. The clients have to query back the Authorization server to get a validated JWT token



________________________________
From: Stian Thorgersen <sthorger at redhat.com><mailto:sthorger at redhat.com>
To: <mailto:manfred.duchrow at caprica.biz> manfred.duchrow at caprica.biz<mailto:manfred.duchrow at caprica.biz>
Cc: keycloak-user <mailto:keycloak-user at lists.jboss.org> <keycloak-user at lists.jboss.org><mailto:keycloak-user at lists.jboss.org>
Sent: Friday, February 5, 2016 7:10 AM
Subject: Re: [keycloak-user] access_token always contains JWT

There's no such thing as a "simple token". Tokens are always a signed JWT.

On 5 February 2016 at 11:17, <<mailto:manfred.duchrow at caprica.biz>manfred.duchrow at caprica.biz<mailto:manfred.duchrow at caprica.biz>> wrote:

Hi,

I am trying to retrieve an access token from a Keycloak (1.8.0.Final)
service account by
POST /auth/realms/myrealm/protocol/openid-connect/token
with grant_type=client_credentials.

The result contains a signed JWT as value of field "access_token" rather
than a simple token
as described in chapter 18 (Service Accounts) of the user guide.

So what I expect (need) is a response like this:

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":60,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "refresh_expires_in":600,
    "id_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "not-before-policy":0,
    "session-state":"234234-234234-234234"
}

Is there a way to configure the account or the realm to return a simple
token
in "access_token" (and "refresh_token") rather than a JWT?

Cheers,
  Manfred




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


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




--
========================================
Caprica Ltd.
69 Great Hampton Street
Birmingham, West Midlands, B186EW,
Registered in England and Wales
Company No. 5298548
Managing Director: Manfred Duchrow

Zweigniederlassung Deutschland
Gartenstr. 48, 89150 Laichingen
Amtsgericht Ulm: HRB 5073
Gesch?ftsf?hrer: Manfred Duchrow
----------------------------------------
Tel:    +49 (0)7333 9232190
Fax:    +49 (0)7333 9232191
E-Mail: manfred.duchrow at caprica.de<mailto:manfred.duchrow at caprica.de>
========================================

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




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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160208/c618b56c/attachment.html 

From jessec at dnbcloud.com  Mon Feb  8 20:18:59 2016
From: jessec at dnbcloud.com (Jesse Chahal)
Date: Mon, 8 Feb 2016 17:18:59 -0800
Subject: [keycloak-user] Social Login, whitelist company domains (google)
Message-ID: <CAP26fkfYFpRCYZtb2RC9GJOgxMsmi0_6xiKn6jnB6qDoPopExA@mail.gmail.com>

Hi,

So I've been experimented with the social login, mostly the google one, and
am trying to figure out how to allow whitelisting of domains for people
using google apps for business. I think it is common practice to use social
login for companies if they are using services from said provider. Is there
a way to limit google's social login to only those who are using email's
from specific domains? If not would be the best way for me to go around
implementing this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160208/d170eb91/attachment.html 

From sthorger at redhat.com  Tue Feb  9 03:11:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 9 Feb 2016 09:11:39 +0100
Subject: [keycloak-user] Social Login, whitelist company domains (google)
In-Reply-To: <CAP26fkfYFpRCYZtb2RC9GJOgxMsmi0_6xiKn6jnB6qDoPopExA@mail.gmail.com>
References: <CAP26fkfYFpRCYZtb2RC9GJOgxMsmi0_6xiKn6jnB6qDoPopExA@mail.gmail.com>
Message-ID: <CAJgngAfjzwd+fzUipHLAGg-Z8aRuoA5TQhsoy4U8ayJ14omAHA@mail.gmail.com>

We don't currently have support for this. However, it would be a nice
addition and you're not the first person to ask.

Google provides an hd query parameter that allows specifying the domain.
However, it also needs to be verified on the server side in the callback.

On 9 February 2016 at 02:18, Jesse Chahal <jessec at dnbcloud.com> wrote:

> Hi,
>
> So I've been experimented with the social login, mostly the google one,
> and am trying to figure out how to allow whitelisting of domains for people
> using google apps for business. I think it is common practice to use social
> login for companies if they are using services from said provider. Is there
> a way to limit google's social login to only those who are using email's
> from specific domains? If not would be the best way for me to go around
> implementing this?
>
> _______________________________________________
> 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/20160209/f23feccf/attachment-0001.html 

From davidillsley at gmail.com  Tue Feb  9 03:27:55 2016
From: davidillsley at gmail.com (David Illsley)
Date: Tue, 9 Feb 2016 08:27:55 +0000
Subject: [keycloak-user] Social Login, whitelist company domains (google)
In-Reply-To: <CAJgngAfjzwd+fzUipHLAGg-Z8aRuoA5TQhsoy4U8ayJ14omAHA@mail.gmail.com>
References: <CAP26fkfYFpRCYZtb2RC9GJOgxMsmi0_6xiKn6jnB6qDoPopExA@mail.gmail.com>
	<CAJgngAfjzwd+fzUipHLAGg-Z8aRuoA5TQhsoy4U8ayJ14omAHA@mail.gmail.com>
Message-ID: <CA+E3Fw1zBBJEEWfiG7cAnvrZiYqRdpp=dv9FACkRZj4Qsvxauw@mail.gmail.com>

Are there any thoughts or plans to implement something like auth0 rules [1]
which would allow easy customisaton of things like this (the checking part
anyway)?

[1] https://auth0.com/docs/rules

On Tue, Feb 9, 2016 at 8:11 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> We don't currently have support for this. However, it would be a nice
> addition and you're not the first person to ask.
>
> Google provides an hd query parameter that allows specifying the domain.
> However, it also needs to be verified on the server side in the callback.
>
> On 9 February 2016 at 02:18, Jesse Chahal <jessec at dnbcloud.com> wrote:
>
>> Hi,
>>
>> So I've been experimented with the social login, mostly the google one,
>> and am trying to figure out how to allow whitelisting of domains for people
>> using google apps for business. I think it is common practice to use social
>> login for companies if they are using services from said provider. Is there
>> a way to limit google's social login to only those who are using email's
>> from specific domains? If not would be the best way for me to go around
>> implementing this?
>>
>> _______________________________________________
>> 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/20160209/2fd5da35/attachment.html 

From sthorger at redhat.com  Tue Feb  9 03:36:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 9 Feb 2016 09:36:09 +0100
Subject: [keycloak-user] Social Login, whitelist company domains (google)
In-Reply-To: <CA+E3Fw1zBBJEEWfiG7cAnvrZiYqRdpp=dv9FACkRZj4Qsvxauw@mail.gmail.com>
References: <CAP26fkfYFpRCYZtb2RC9GJOgxMsmi0_6xiKn6jnB6qDoPopExA@mail.gmail.com>
	<CAJgngAfjzwd+fzUipHLAGg-Z8aRuoA5TQhsoy4U8ayJ14omAHA@mail.gmail.com>
	<CA+E3Fw1zBBJEEWfiG7cAnvrZiYqRdpp=dv9FACkRZj4Qsvxauw@mail.gmail.com>
Message-ID: <CAJgngAfHK7aHuYqCgbpSHa5xm93veZ1Hib3Gr8oPu2gWHvfdTA@mail.gmail.com>

We already have that through custom authentication flows. See
http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html

Whitelist company domain can be done by customizing the first social login
flow.

On 9 February 2016 at 09:27, David Illsley <davidillsley at gmail.com> wrote:

> Are there any thoughts or plans to implement something like auth0 rules
> [1] which would allow easy customisaton of things like this (the checking
> part anyway)?
>
> [1] https://auth0.com/docs/rules
>
> On Tue, Feb 9, 2016 at 8:11 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> We don't currently have support for this. However, it would be a nice
>> addition and you're not the first person to ask.
>>
>> Google provides an hd query parameter that allows specifying the domain.
>> However, it also needs to be verified on the server side in the callback.
>>
>> On 9 February 2016 at 02:18, Jesse Chahal <jessec at dnbcloud.com> wrote:
>>
>>> Hi,
>>>
>>> So I've been experimented with the social login, mostly the google one,
>>> and am trying to figure out how to allow whitelisting of domains for people
>>> using google apps for business. I think it is common practice to use social
>>> login for companies if they are using services from said provider. Is there
>>> a way to limit google's social login to only those who are using email's
>>> from specific domains? If not would be the best way for me to go around
>>> implementing this?
>>>
>>> _______________________________________________
>>> 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/20160209/547af226/attachment.html 

From andrey.saroul at gmail.com  Tue Feb  9 05:43:19 2016
From: andrey.saroul at gmail.com (Andrey Saroul)
Date: Tue, 9 Feb 2016 13:43:19 +0300
Subject: [keycloak-user] Keycloak redirect to wrong destination
Message-ID: <CAFZbuCNafLtX8=X6rcOLvq74NFsGufku+Ewvwa++XknM5oZE9w@mail.gmail.com>

Recently I encountered with unexpected behavour of Keycloak.
I did a simple rest service and had deployed Keycloak on one the same
machine.
I'm using keycloak 1.7.0 with WildFly 9.0.2

My root URL of rest service is: /rest
In Keycloak admin console I have configured my rest service this way:
Client Protocol: openid-connect, Valid Redirect URIs: /rest/*

I tried to access my test page of rest service by url:
http://localhost:8080/rest/test?id=1
I got redirect to login form, entered my login and password. That's fine,
browser got valid jsessionid from Keycloak, BUT at the end of redirect
chain I end up with root url of my webapp (http://localhost:8080/rest), but
I tried to access different location (http://localhost:8080/rest/test?id=1)
I expect to be redirected to the url I entered in the first place.
I wonder, is this a bug or a misconfiguration issue?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160209/8bd65f9d/attachment.html 

From thomas.darimont at googlemail.com  Tue Feb  9 06:02:14 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 9 Feb 2016 12:02:14 +0100
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAK-7U1g_J9fQs5gc3TW4jCT_TLaxdp2SOMbbyphuKmojauZQ1A@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
	<CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
	<CAJgngAfGC-e+j0c2AzM4YXUVSfV7yzzV0rThRGrhTicd6a5SaA@mail.gmail.com>
	<CAK-7U1iR4THBqw21dPs89s6otnhRaZbn+vBshb6maoA5HgHLLw@mail.gmail.com>
	<CAPyAMoY0Nb7bdqbi2VP6xv=XcSrk2M5QEYkZ7PJYu95Rg+MvJQ@mail.gmail.com>
	<CAK-7U1iFcuOnFRcYkWB7xC7mRWoMJqnz=JLtBP7R9xWYw3xtBg@mail.gmail.com>
	<CAK-7U1g_J9fQs5gc3TW4jCT_TLaxdp2SOMbbyphuKmojauZQ1A@mail.gmail.com>
Message-ID: <CAK-7U1j2SZ_jLCvrSg8uhHP0diQ5W55Xw-ap6QrVFL-4GULKpw@mail.gmail.com>

Hello,

any ideas regarding this?

We need to link to a default application from several applications and it
would be helpful if keycloak would provide said redirect mechanism, such
that
each application would only need to know the clientId of the default client
application and keycloak performs the proper redirect to the actual target
application.

The example posted earlier works like a charm. This could even be extended
to the point that in case no clientId is given keycloak can decide which
client to redirect to.

Cheers,
Thomas

2016-02-05 19:05 GMT+01:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> Quick update - I did some further experiments with this...
>
> I added /redirect path to the a
> org.keycloak.services.resources.RealmsResource
> like: @Path("{realm}/{client-id}/redirect")
> see code fragment below.
>
> This allows keycloak to initiate a redirect to the browser with the actual
> target url of the client. Other clients now only need to now the realm and
> clientId
> to generate a link that eventually redirects to the target application.
>
> Usage:
> GET http://localhost:8081/auth/realms/master/launchpad/redirect -> 302
> response with location: http://apps.corp.local/launchpad
>
> Any chance to get this in as a PR?
>
> Cheers,
> Thomas
>
>     @GET
>     @Path("{realm}/{client-id}/redirect")
>     public Response getRedirect(final @PathParam("realm") String
> realmName, final @PathParam("client-id") String clientId) throws Exception{
>
>         RealmModel realm = init(realmName);
>
>         if (realm == null){
>             return null;
>         }
>
>         ClientModel client = realm.getClientByClientId(clientId);
>
>         if (client == null){
>             return null;
>         }
>
>         if (client.getRootUrl() == null){
>             return
> Response.temporaryRedirect(uriInfo.getAbsolutePathBuilder().replacePath(client.getBaseUrl()).build()).build();
>         }
>
>         return Response.temporaryRedirect(URI.create(client.getRootUrl() +
> client.getBaseUrl())).build();
>     }
>
> 2016-02-05 16:23 GMT+01:00 Thomas Darimont <thomas.darimont at googlemail.com
> >:
>
>> Hello,
>>
>> 2016-02-05 15:22 GMT+01:00 Thomas Raehalme <
>> thomas.raehalme at aitiofinland.com>:
>>
>>> I understand this as well, but it has not been uncommon to encounter a
>>> situation where the user needs to know where to go next, because Keycloak
>>> doesn't have a link available.
>>
>>
>> with a redirect facility as outlined above - one could render a link to
>> the "$KEYCLOAK_BASE_URL/redirect" or
>> lookup the "default" client in order to render the client base url link
>> with a proper label (client name).
>>
>> Cheers,
>> Thomas
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160209/8dde1341/attachment-0001.html 

From sthorger at redhat.com  Tue Feb  9 06:18:51 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 9 Feb 2016 12:18:51 +0100
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAK-7U1j2SZ_jLCvrSg8uhHP0diQ5W55Xw-ap6QrVFL-4GULKpw@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
	<CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
	<CAJgngAfGC-e+j0c2AzM4YXUVSfV7yzzV0rThRGrhTicd6a5SaA@mail.gmail.com>
	<CAK-7U1iR4THBqw21dPs89s6otnhRaZbn+vBshb6maoA5HgHLLw@mail.gmail.com>
	<CAPyAMoY0Nb7bdqbi2VP6xv=XcSrk2M5QEYkZ7PJYu95Rg+MvJQ@mail.gmail.com>
	<CAK-7U1iFcuOnFRcYkWB7xC7mRWoMJqnz=JLtBP7R9xWYw3xtBg@mail.gmail.com>
	<CAK-7U1g_J9fQs5gc3TW4jCT_TLaxdp2SOMbbyphuKmojauZQ1A@mail.gmail.com>
	<CAK-7U1j2SZ_jLCvrSg8uhHP0diQ5W55Xw-ap6QrVFL-4GULKpw@mail.gmail.com>
Message-ID: <CAJgngAdMKFnkFSZDFU7q8EdgCKOYX2HzmqocBS9uG62n6ehAzw@mail.gmail.com>

One concern with including this is if there's some potential way it can be
a vulnerability.

The only thing I can think of is that it allows figuring out the base url
for a client. That could then be used to figure out valid redirect uris for
a client. Don't think that's a huge deal though.

Another thing is that it is related to a feature we want to add at some
point. We'd like to be able to have a SSO page that lists all clients,
including icons and links to the clients. This would have two use-cases:
1. As a landing page on SSO server, and as a way for users to find all
applications they can login to
2. A rest service would enable applications to get a list of all clients
and provide a link to other applications in the realm (like Google does
with the square boxes icon)

With that in mind it would be better if the URL for client redirect was
"{realm}/clients/{client-id}/redirect" as that would allows us to use
"{realm}/clients" in the future for the above feature. "{realm}/clients" is
already used by ClientRegistrationService, but I think we can move that to
"{realm}/clients/registration" as there's probably not that many people
that are using the client registration service yet.

On 9 February 2016 at 12:02, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Hello,
>
> any ideas regarding this?
>
> We need to link to a default application from several applications and it
> would be helpful if keycloak would provide said redirect mechanism, such
> that
> each application would only need to know the clientId of the default
> client application and keycloak performs the proper redirect to the actual
> target application.
>
> The example posted earlier works like a charm. This could even be extended
> to the point that in case no clientId is given keycloak can decide which
> client to redirect to.
>
> Cheers,
> Thomas
>
> 2016-02-05 19:05 GMT+01:00 Thomas Darimont <thomas.darimont at googlemail.com
> >:
>
>> Quick update - I did some further experiments with this...
>>
>> I added /redirect path to the a
>> org.keycloak.services.resources.RealmsResource
>> like: @Path("{realm}/{client-id}/redirect")
>> see code fragment below.
>>
>> This allows keycloak to initiate a redirect to the browser with the actual
>> target url of the client. Other clients now only need to now the realm
>> and clientId
>> to generate a link that eventually redirects to the target application.
>>
>> Usage:
>> GET http://localhost:8081/auth/realms/master/launchpad/redirect -> 302
>> response with location: http://apps.corp.local/launchpad
>>
>> Any chance to get this in as a PR?
>>
>> Cheers,
>> Thomas
>>
>>     @GET
>>     @Path("{realm}/{client-id}/redirect")
>>     public Response getRedirect(final @PathParam("realm") String
>> realmName, final @PathParam("client-id") String clientId) throws Exception{
>>
>>         RealmModel realm = init(realmName);
>>
>>         if (realm == null){
>>             return null;
>>         }
>>
>>         ClientModel client = realm.getClientByClientId(clientId);
>>
>>         if (client == null){
>>             return null;
>>         }
>>
>>         if (client.getRootUrl() == null){
>>             return
>> Response.temporaryRedirect(uriInfo.getAbsolutePathBuilder().replacePath(client.getBaseUrl()).build()).build();
>>         }
>>
>>         return Response.temporaryRedirect(URI.create(client.getRootUrl()
>> + client.getBaseUrl())).build();
>>     }
>>
>> 2016-02-05 16:23 GMT+01:00 Thomas Darimont <
>> thomas.darimont at googlemail.com>:
>>
>>> Hello,
>>>
>>> 2016-02-05 15:22 GMT+01:00 Thomas Raehalme <
>>> thomas.raehalme at aitiofinland.com>:
>>>
>>>> I understand this as well, but it has not been uncommon to encounter a
>>>> situation where the user needs to know where to go next, because Keycloak
>>>> doesn't have a link available.
>>>
>>>
>>> with a redirect facility as outlined above - one could render a link to
>>> the "$KEYCLOAK_BASE_URL/redirect" or
>>> lookup the "default" client in order to render the client base url link
>>> with a proper label (client name).
>>>
>>> Cheers,
>>> Thomas
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160209/97192e40/attachment.html 

From andrey.saroul at gmail.com  Tue Feb  9 10:25:56 2016
From: andrey.saroul at gmail.com (Andrey Saroul)
Date: Tue, 9 Feb 2016 18:25:56 +0300
Subject: [keycloak-user] Establish session by ajax request
Message-ID: <CAFZbuCO1RkkpcPbH480-9qor0g9xhvJJzffPgvYsfsNt9CsibQ@mail.gmail.com>

Is there any way to establish session with client (webapp with browser
enabled authn, not a Bearer type) by XMLHttpRequest?
I have central webapp which provide access to other services (restful). The
problem is that when I login into central app I establish session with
jsessionid connected to it. That works fine until I try to access other
services. I have front-end as a single page (ExtJS) which issue
XMLHttpRequest to service (separate web app in the same server). By the
time I login into central app browser has its jsessionid, but to access
other service, I need to establish another session and keycloak has to
generate another jsessionid for me to access this service. And I can't get
it supposedly because of XMLHttpRequest not a HttpRequest.

For example, for this request (with jsessionid of central webapp):
GET /rest/test HTTP/1.1
Host: localhost:8080
*X-Requested-With: XMLHttpRequest*
Cookie: JSESSIONID=XAVXi...
Connection: keep-alive

Response is (I ommited some unimportant headers):
*HTTP/1.1 401 Unauthorized*
Expires: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
X-Powered-By: Undertow/1
Server: WildFly/9
Pragma: no-cache
Connection: keep-alive


*WWW-Authenticate: Bearer realm="Unknown"*
And when I change request to generic http, I got correct jsessionid and can
access my rest service.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160209/bd06332c/attachment.html 

From thomas.darimont at googlemail.com  Tue Feb  9 11:18:59 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 9 Feb 2016 17:18:59 +0100
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAJgngAdMKFnkFSZDFU7q8EdgCKOYX2HzmqocBS9uG62n6ehAzw@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
	<CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
	<CAJgngAfGC-e+j0c2AzM4YXUVSfV7yzzV0rThRGrhTicd6a5SaA@mail.gmail.com>
	<CAK-7U1iR4THBqw21dPs89s6otnhRaZbn+vBshb6maoA5HgHLLw@mail.gmail.com>
	<CAPyAMoY0Nb7bdqbi2VP6xv=XcSrk2M5QEYkZ7PJYu95Rg+MvJQ@mail.gmail.com>
	<CAK-7U1iFcuOnFRcYkWB7xC7mRWoMJqnz=JLtBP7R9xWYw3xtBg@mail.gmail.com>
	<CAK-7U1g_J9fQs5gc3TW4jCT_TLaxdp2SOMbbyphuKmojauZQ1A@mail.gmail.com>
	<CAK-7U1j2SZ_jLCvrSg8uhHP0diQ5W55Xw-ap6QrVFL-4GULKpw@mail.gmail.com>
	<CAJgngAdMKFnkFSZDFU7q8EdgCKOYX2HzmqocBS9uG62n6ehAzw@mail.gmail.com>
Message-ID: <CAK-7U1iOoH4oUU2i9Cr6PUWN48dUSiACgBkxnNeyMT2fRwUvmw@mail.gmail.com>

Thanks for your input :)

The redirect would only work after a successful authentication,
so unauthenticated users couldn't "probe" the realm for clients / target
urls.

But I see your point that an authenticated "malicious" user could probe all
clients if he knew all clientIds (potentially via the new API).
Perhaps one could offer a way to define some kind of grouping concept to
describe
which clients that can see each other (client group?) - so only clients
from within the
same group would be eligible for such a redirect.

Btw. I adapted your suggestion regarding the endpoint path (which is now:
{realm}/clients/{client_id}/redirect)
and created a JIRA issue [0] and PR [1] with my current impl as a base for
further discussion.

> Another thing is that it is related to a feature we want to add at some
point.
> We'd like to be able to have a SSO > page that lists all clients,
including icons and links to the clients.
> This would have two use-cases:
> 1. As a landing page on SSO server, and as a way for users to find all
applications they can login to

This would be really helpful - is this supposed to replace the applications
section in the account page?

> 2. A rest service would enable applications to get a list of all clients
and provide a link
> to other applications in the realm (like Google does with the square
boxes icon)

This would also be very helpful, currently I pull the information with the
keycloak admin client
in order to render such a page. A dedicated endpoint that returns clients
metadata in JSON format
would be neat. Are you planning to just build a dedicated page of all apps
or also a html/js widget like the 9 square app selector?

[0] https://issues.jboss.org/browse/KEYCLOAK-2469
[1] https://github.com/keycloak/keycloak/pull/2202


2016-02-09 12:18 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> One concern with including this is if there's some potential way it can be
> a vulnerability.
>
> The only thing I can think of is that it allows figuring out the base url
> for a client. That could then be used to figure out valid redirect uris for
> a client. Don't think that's a huge deal though.
>
> Another thing is that it is related to a feature we want to add at some
> point. We'd like to be able to have a SSO page that lists all clients,
> including icons and links to the clients. This would have two use-cases:
> 1. As a landing page on SSO server, and as a way for users to find all
> applications they can login to
> 2. A rest service would enable applications to get a list of all clients
> and provide a link to other applications in the realm (like Google does
> with the square boxes icon)
>
> With that in mind it would be better if the URL for client redirect was
> "{realm}/clients/{client-id}/redirect" as that would allows us to use
> "{realm}/clients" in the future for the above feature. "{realm}/clients" is
> already used by ClientRegistrationService, but I think we can move that to
> "{realm}/clients/registration" as there's probably not that many people
> that are using the client registration service yet.
>
> On 9 February 2016 at 12:02, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hello,
>>
>> any ideas regarding this?
>>
>> We need to link to a default application from several applications and it
>> would be helpful if keycloak would provide said redirect mechanism, such
>> that
>> each application would only need to know the clientId of the default
>> client application and keycloak performs the proper redirect to the actual
>> target application.
>>
>> The example posted earlier works like a charm. This could even be
>> extended to the point that in case no clientId is given keycloak can decide
>> which client to redirect to.
>>
>> Cheers,
>> Thomas
>>
>> 2016-02-05 19:05 GMT+01:00 Thomas Darimont <
>> thomas.darimont at googlemail.com>:
>>
>>> Quick update - I did some further experiments with this...
>>>
>>> I added /redirect path to the a
>>> org.keycloak.services.resources.RealmsResource
>>> like: @Path("{realm}/{client-id}/redirect")
>>> see code fragment below.
>>>
>>> This allows keycloak to initiate a redirect to the browser with the
>>> actual
>>> target url of the client. Other clients now only need to now the realm
>>> and clientId
>>> to generate a link that eventually redirects to the target application.
>>>
>>> Usage:
>>> GET http://localhost:8081/auth/realms/master/launchpad/redirect -> 302
>>> response with location: http://apps.corp.local/launchpad
>>>
>>> Any chance to get this in as a PR?
>>>
>>> Cheers,
>>> Thomas
>>>
>>>     @GET
>>>     @Path("{realm}/{client-id}/redirect")
>>>     public Response getRedirect(final @PathParam("realm") String
>>> realmName, final @PathParam("client-id") String clientId) throws Exception{
>>>
>>>         RealmModel realm = init(realmName);
>>>
>>>         if (realm == null){
>>>             return null;
>>>         }
>>>
>>>         ClientModel client = realm.getClientByClientId(clientId);
>>>
>>>         if (client == null){
>>>             return null;
>>>         }
>>>
>>>         if (client.getRootUrl() == null){
>>>             return
>>> Response.temporaryRedirect(uriInfo.getAbsolutePathBuilder().replacePath(client.getBaseUrl()).build()).build();
>>>         }
>>>
>>>         return Response.temporaryRedirect(URI.create(client.getRootUrl()
>>> + client.getBaseUrl())).build();
>>>     }
>>>
>>> 2016-02-05 16:23 GMT+01:00 Thomas Darimont <
>>> thomas.darimont at googlemail.com>:
>>>
>>>> Hello,
>>>>
>>>> 2016-02-05 15:22 GMT+01:00 Thomas Raehalme <
>>>> thomas.raehalme at aitiofinland.com>:
>>>>
>>>>> I understand this as well, but it has not been uncommon to encounter a
>>>>> situation where the user needs to know where to go next, because Keycloak
>>>>> doesn't have a link available.
>>>>
>>>>
>>>> with a redirect facility as outlined above - one could render a link to
>>>> the "$KEYCLOAK_BASE_URL/redirect" or
>>>> lookup the "default" client in order to render the client base url link
>>>> with a proper label (client name).
>>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160209/cdbd1a01/attachment-0001.html 

From andrey.saroul at gmail.com  Tue Feb  9 13:00:24 2016
From: andrey.saroul at gmail.com (Andrey Saroul)
Date: Tue, 9 Feb 2016 21:00:24 +0300
Subject: [keycloak-user] Establish session by ajax request
Message-ID: <CAFZbuCMifGRXmUPkwDbesi=dUieU=cVDR=CfGoRBb5X8oJueKg@mail.gmail.com>

No more actual.
I fixed it by using bearer type auth instead of confidential.
I generated token and set its value to front-end ExtJs.

2016-02-09 18:25 GMT+03:00 Andrey Saroul <andrey.saroul at gmail.com>:

> Is there any way to establish session with client (webapp with browser
> enabled authn, not a Bearer type) by XMLHttpRequest?
> I have central webapp which provide access to other services (restful).
> The problem is that when I login into central app I establish session with
> jsessionid connected to it. That works fine until I try to access other
> services. I have front-end as a single page (ExtJS) which issue
> XMLHttpRequest to service (separate web app in the same server). By the
> time I login into central app browser has its jsessionid, but to access
> other service, I need to establish another session and keycloak has to
> generate another jsessionid for me to access this service. And I can't get
> it supposedly because of XMLHttpRequest not a HttpRequest.
>
> For example, for this request (with jsessionid of central webapp):
> GET /rest/test HTTP/1.1
> Host: localhost:8080
> *X-Requested-With: XMLHttpRequest*
> Cookie: JSESSIONID=XAVXi...
> Connection: keep-alive
>
> Response is (I ommited some unimportant headers):
> *HTTP/1.1 401 Unauthorized*
> Expires: 0
> Cache-Control: no-cache, no-store, max-age=0, must-revalidate
> X-Powered-By: Undertow/1
> Server: WildFly/9
> Pragma: no-cache
> Connection: keep-alive
>
>
> *WWW-Authenticate: Bearer realm="Unknown"*
> And when I change request to generic http, I got correct jsessionid and
> can access my rest service.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160209/3eb511a8/attachment.html 

From jeremy at jeremysimon.com  Tue Feb  9 14:47:31 2016
From: jeremy at jeremysimon.com (Jeremy Simon)
Date: Tue, 9 Feb 2016 14:47:31 -0500
Subject: [keycloak-user] spring security getting username
Message-ID: <CAPFuFv9mRbfpQM6Yo7X34n=Pb31pQbGBodjw-0F0uz4EGkeZog@mail.gmail.com>

Hi,

I can't seem to get my user's name using the keycloak adaptor for
spring security.  I have a rest controller that i'm trying this chunk
of code:

...
Authentication KeyCloakAuth =
SecurityContextHolder.getContext().getAuthentication();
KeycloakAccount  keyAccount = ((KeycloakAuthenticationToken)
KeyCloakAuth).getAccount();

String username1 = keyAccount.getPrincipal().getName()
String username2 =
SecurityContextHolder.getContext().getAuthentication().getName()

KeycloakPrincipal<?> prince = (KeycloakPrincipal<?>)
((KeycloakAuthenticationToken) KeyCloakAuth).getPrincipal();
String username3 = prince.getName();

...


username1, username2, username3 will have something like this:
aa5f6e42-9463-4862-a750-bd0c092daf11


I gleaned this from some stackoverflow examples that claimed these
approached worked... There something I don't have set right?


jeremy
jeremy at jeremysimon.com
www.JeremySimon.com

From thomas.darimont at googlemail.com  Tue Feb  9 15:25:12 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 9 Feb 2016 21:25:12 +0100
Subject: [keycloak-user] spring security getting username
In-Reply-To: <CAPFuFv9mRbfpQM6Yo7X34n=Pb31pQbGBodjw-0F0uz4EGkeZog@mail.gmail.com>
References: <CAPFuFv9mRbfpQM6Yo7X34n=Pb31pQbGBodjw-0F0uz4EGkeZog@mail.gmail.com>
Message-ID: <CAK-7U1gnrUQjmGYOpEw9Bq10hGGbphXEUsTWK+Cx4cSoy6PyDA@mail.gmail.com>

Hello Jeremy,

try adding: "principal-attribute": "preferred_username" to your
keycloak.json.

See:
http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config

Cheers,
Thomas

2016-02-09 20:47 GMT+01:00 Jeremy Simon <jeremy at jeremysimon.com>:

> Hi,
>
> I can't seem to get my user's name using the keycloak adaptor for
> spring security.  I have a rest controller that i'm trying this chunk
> of code:
>
> ...
> Authentication KeyCloakAuth =
> SecurityContextHolder.getContext().getAuthentication();
> KeycloakAccount  keyAccount = ((KeycloakAuthenticationToken)
> KeyCloakAuth).getAccount();
>
> String username1 = keyAccount.getPrincipal().getName()
> String username2 =
> SecurityContextHolder.getContext().getAuthentication().getName()
>
> KeycloakPrincipal<?> prince = (KeycloakPrincipal<?>)
> ((KeycloakAuthenticationToken) KeyCloakAuth).getPrincipal();
> String username3 = prince.getName();
>
> ...
>
>
> username1, username2, username3 will have something like this:
> aa5f6e42-9463-4862-a750-bd0c092daf11
>
>
> I gleaned this from some stackoverflow examples that claimed these
> approached worked... There something I don't have set right?
>
>
> jeremy
> jeremy at jeremysimon.com
> www.JeremySimon.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/20160209/22b9f922/attachment.html 

From RLewis at carbonite.com  Tue Feb  9 15:37:14 2016
From: RLewis at carbonite.com (Reed Lewis)
Date: Tue, 9 Feb 2016 20:37:14 +0000
Subject: [keycloak-user] Adding additional security questions for forgotten
	password.
Message-ID: <56A52C5E-07D4-4F69-ACE1-26EA4087984A@carbonite.com>

I am implementing Keycloak and need to have the ability to have user questions that can be stored, and asked randomly if the user forgets their password.

Can Keycloak store this content, or do I need a separate instance?   How do I integrate this into Keycloak?

Thank you,

Reed Lewis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160209/aa1248fe/attachment.html 

From jeremy at jeremysimon.com  Tue Feb  9 15:44:31 2016
From: jeremy at jeremysimon.com (Jeremy Simon)
Date: Tue, 9 Feb 2016 15:44:31 -0500
Subject: [keycloak-user] spring security getting username
In-Reply-To: <CAK-7U1gnrUQjmGYOpEw9Bq10hGGbphXEUsTWK+Cx4cSoy6PyDA@mail.gmail.com>
References: <CAPFuFv9mRbfpQM6Yo7X34n=Pb31pQbGBodjw-0F0uz4EGkeZog@mail.gmail.com>
	<CAK-7U1gnrUQjmGYOpEw9Bq10hGGbphXEUsTWK+Cx4cSoy6PyDA@mail.gmail.com>
Message-ID: <CAPFuFv_1vZ8LDYwHU+CfT29+7Pg7GC1QdvE+PF=Vy52O17TrqQ@mail.gmail.com>

That's the trick!  Thank you!
jeremy
jeremy at jeremysimon.com
www.JeremySimon.com


On Tue, Feb 9, 2016 at 3:25 PM, Thomas Darimont
<thomas.darimont at googlemail.com> wrote:
> Hello Jeremy,
>
> try adding: "principal-attribute": "preferred_username" to your
> keycloak.json.
>
> See:
> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>
> Cheers,
> Thomas
>
> 2016-02-09 20:47 GMT+01:00 Jeremy Simon <jeremy at jeremysimon.com>:
>>
>> Hi,
>>
>> I can't seem to get my user's name using the keycloak adaptor for
>> spring security.  I have a rest controller that i'm trying this chunk
>> of code:
>>
>> ...
>> Authentication KeyCloakAuth =
>> SecurityContextHolder.getContext().getAuthentication();
>> KeycloakAccount  keyAccount = ((KeycloakAuthenticationToken)
>> KeyCloakAuth).getAccount();
>>
>> String username1 = keyAccount.getPrincipal().getName()
>> String username2 =
>> SecurityContextHolder.getContext().getAuthentication().getName()
>>
>> KeycloakPrincipal<?> prince = (KeycloakPrincipal<?>)
>> ((KeycloakAuthenticationToken) KeyCloakAuth).getPrincipal();
>> String username3 = prince.getName();
>>
>> ...
>>
>>
>> username1, username2, username3 will have something like this:
>> aa5f6e42-9463-4862-a750-bd0c092daf11
>>
>>
>> I gleaned this from some stackoverflow examples that claimed these
>> approached worked... There something I don't have set right?
>>
>>
>> jeremy
>> jeremy at jeremysimon.com
>> www.JeremySimon.com
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From bl at onion.io  Tue Feb  9 17:11:23 2016
From: bl at onion.io (Boken Lin)
Date: Tue, 9 Feb 2016 17:11:23 -0500
Subject: [keycloak-user] Information in Access Token
Message-ID: <56BA640B.7000901@onion.io>

Hi all,

Is there a way to define what kind of information gets encoded in the 
access token? Right now I'm looking for a way to reduce the length of 
the access token.

Any help would be greatly appreciated!

Thanks.
Boken.

From thomas.darimont at googlemail.com  Tue Feb  9 17:32:59 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 9 Feb 2016 23:32:59 +0100
Subject: [keycloak-user] Information in Access Token
In-Reply-To: <56BA640B.7000901@onion.io>
References: <56BA640B.7000901@onion.io>
Message-ID: <CAK-7U1j6X90xSSvnwUoTa8MkW_fOE3YttAQg5-nURgQas_Z+-g@mail.gmail.com>

Hello Boken,

you can use Client Mappers to control which attributes are encoded in the
Access Token.
Further more check whether you have full scope activated and if yes,
whether this is necessary.

Cheers,
Thomas

2016-02-09 23:11 GMT+01:00 Boken Lin <bl at onion.io>:

> Hi all,
>
> Is there a way to define what kind of information gets encoded in the
> access token? Right now I'm looking for a way to reduce the length of
> the access token.
>
> Any help would be greatly appreciated!
>
> Thanks.
> Boken.
> _______________________________________________
> 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/20160209/98ba40c9/attachment.html 

From mstrukel at redhat.com  Tue Feb  9 17:39:42 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 9 Feb 2016 23:39:42 +0100
Subject: [keycloak-user] Adding additional security questions for
 forgotten password.
In-Reply-To: <56A52C5E-07D4-4F69-ACE1-26EA4087984A@carbonite.com>
References: <56A52C5E-07D4-4F69-ACE1-26EA4087984A@carbonite.com>
Message-ID: <CA+1OW+itZWQC3WTojB2-oCtDPJLrGUWV6CL8ip5untY=TohUng@mail.gmail.com>

There is an authenticator provider example you can study to create
your own auth provider:
https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator

It implements user questions - just what you need, but only one, and
without randomness.

On Tue, Feb 9, 2016 at 9:37 PM, Reed Lewis <RLewis at carbonite.com> wrote:
> I am implementing Keycloak and need to have the ability to have user
> questions that can be stored, and asked randomly if the user forgets their
> password.
>
> Can Keycloak store this content, or do I need a separate instance?   How do
> I integrate this into Keycloak?
>
> Thank you,
>
> Reed Lewis
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From bl at onion.io  Tue Feb  9 17:57:29 2016
From: bl at onion.io (Boken Lin)
Date: Tue, 9 Feb 2016 17:57:29 -0500
Subject: [keycloak-user] Information in Access Token
In-Reply-To: <CAK-7U1j6X90xSSvnwUoTa8MkW_fOE3YttAQg5-nURgQas_Z+-g@mail.gmail.com>
References: <56BA640B.7000901@onion.io>
	<CAK-7U1j6X90xSSvnwUoTa8MkW_fOE3YttAQg5-nURgQas_Z+-g@mail.gmail.com>
Message-ID: <CAD95a1K-nUwnBct3G3dpGMcmjQjpF-bUMcw102B-FNb-QpDSWQ@mail.gmail.com>

Thank you!
On Feb 9, 2016 5:33 PM, "Thomas Darimont" <thomas.darimont at googlemail.com>
wrote:

> Hello Boken,
>
> you can use Client Mappers to control which attributes are encoded in the
> Access Token.
> Further more check whether you have full scope activated and if yes,
> whether this is necessary.
>
> Cheers,
> Thomas
>
> 2016-02-09 23:11 GMT+01:00 Boken Lin <bl at onion.io>:
>
>> Hi all,
>>
>> Is there a way to define what kind of information gets encoded in the
>> access token? Right now I'm looking for a way to reduce the length of
>> the access token.
>>
>> Any help would be greatly appreciated!
>>
>> Thanks.
>> Boken.
>> _______________________________________________
>> 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/20160209/f326c016/attachment.html 

From technolengy at gmail.com  Tue Feb  9 21:56:14 2016
From: technolengy at gmail.com (Steve Nolen)
Date: Wed, 10 Feb 2016 02:56:14 +0000
Subject: [keycloak-user] trouble acting as SP with testshib.org IdP
Message-ID: <CAC_FVB7XdAzxSOCX4Dsq0gz4M+xiwChSiwdYjOhXqVLB7mREbQ@mail.gmail.com>

Hi!

First of all, keycloak is legitimately awesome!

I was attempting to test the use of keycloak as a shibboleth SP today
(testing against the testshib.org test IdP) and am having some trouble.

Keycloak Version: 1.9.0CR1 (using it on openshift currently)

Both sides seem to be set up as they should (I used the testshib endpoint
to import the settings to keycloak). I'm able to take the redirect over to
idp.testshib but on logging in I get a 500 Internal Server Error from
keycloak.  The message is "No Assertion from response" (stack trace below).

Any thoughts on what might be missing?

==== stack trace ====
http://pastebin.com/3tsApUKK

==== broker details ====
https://keycloak-technolengy.rhcloud.com/auth/realms/technolengy/broker/testshib.org/endpoint/descriptor

==== provider details ====
https://www.testshib.org/metadata/testshib-providers.xml

Thank you!
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/58dc1745/attachment.html 

From michael.anthon at infoview.com.au  Tue Feb  9 23:24:10 2016
From: michael.anthon at infoview.com.au (Michael Anthon)
Date: Wed, 10 Feb 2016 04:24:10 +0000
Subject: [keycloak-user] Issues with password reset link expiration
Message-ID: <e3c4dce4db8649958379bf11260f79d1@HsteqMX04.nexonhosted.local>

We are having issues with some users when they are attempting to use the password reset feature.  It does work for most users however for some they always end up at an error page saying "WE'RE SORRY ... An error occurred, please login again through your application"

What I have been able to determine so far is that for the affected users we are seeing a double hit on that URL in the server logs and from what I understand, these reset URLs are invalidated as soon as they are accessed.

So here's the state of play
* works for most users
* some users hitting the reset URL twice
* URL is only valid for the first access (I'm not 100% sure about this, can someone confirm please?)
* URL is only valid for 30 minutes (but is being accessed within a few minutes of generation)
* affected users are mostly using Outlook
* some people tend to double click links in emails but I've verified with a reliable user that they are only clicking the link once
* having the affected person send themselves another reset email and then copy and paste the URL from the mail client usually resolves this problem

And questions
* is this an issue anyone else has noticed with Outlook, doesn't affect ALL Outlook users, just some
* is there a way to prevent the URL from being invalidated on initial access
* is it feasible to change the behavior so that the URL is only invalidated when the password is changed
* any other thoughts on how to avoid this issue?

Thanks and Regards,

Michael Anthon
InfoView Technologies Pty Ltd
12/15 Adelaide St, Brisbane Qld 4000
P O Box 15478, City East, Brisbane Qld 4000
PH:????????? +61 7 3014 2204
F:???????????? +61 7 3014 2200
M:?????????? +61 408 768 055
michael.anthon at infoview.com.au

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of InfoView Technologies Pty Ltd.



From jayblanc at gmail.com  Wed Feb 10 04:10:40 2016
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Wed, 10 Feb 2016 09:10:40 +0000
Subject: [keycloak-user] trouble acting as SP with testshib.org IdP
In-Reply-To: <CAC_FVB7XdAzxSOCX4Dsq0gz4M+xiwChSiwdYjOhXqVLB7mREbQ@mail.gmail.com>
References: <CAC_FVB7XdAzxSOCX4Dsq0gz4M+xiwChSiwdYjOhXqVLB7mREbQ@mail.gmail.com>
Message-ID: <CAPNq5vbz4j5JGBP9S-FO4Pagy4402YSLJD2BkgN5Erecfxv0SQ@mail.gmail.com>

Hi Steve,

I'm using Keycloak as a shibboleth SP in a federation (Renater) and It's
working fine. The problem you encounter comes from the fact that you ask
for a persistent nameId in the config of your SP and, according to the
provider details, it's only able to send transient nameId.
Feel the parameter of nameId to undefined and check the authentication
again.

Best regards, J?r?me.

Le mer. 10 f?vr. 2016 ? 03:57, Steve Nolen <technolengy at gmail.com> a ?crit :

> Hi!
>
> First of all, keycloak is legitimately awesome!
>
> I was attempting to test the use of keycloak as a shibboleth SP today
> (testing against the testshib.org test IdP) and am having some trouble.
>
> Keycloak Version: 1.9.0CR1 (using it on openshift currently)
>
> Both sides seem to be set up as they should (I used the testshib endpoint
> to import the settings to keycloak). I'm able to take the redirect over to
> idp.testshib but on logging in I get a 500 Internal Server Error from
> keycloak.  The message is "No Assertion from response" (stack trace below).
>
> Any thoughts on what might be missing?
>
> ==== stack trace ====
> http://pastebin.com/3tsApUKK
>
> ==== broker details ====
>
> https://keycloak-technolengy.rhcloud.com/auth/realms/technolengy/broker/testshib.org/endpoint/descriptor
>
> ==== provider details ====
> https://www.testshib.org/metadata/testshib-providers.xml
>
> Thank you!
> Steve
> _______________________________________________
> 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/20160210/06e7e9ff/attachment-0001.html 

From sthorger at redhat.com  Wed Feb 10 04:21:40 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 10 Feb 2016 10:21:40 +0100
Subject: [keycloak-user] Issues with password reset link expiration
In-Reply-To: <e3c4dce4db8649958379bf11260f79d1@HsteqMX04.nexonhosted.local>
References: <e3c4dce4db8649958379bf11260f79d1@HsteqMX04.nexonhosted.local>
Message-ID: <CAJgngAdk_iN2vcR0i5t-3wriOe3xgQWAxPGWf1_D3sR62_s8JQ@mail.gmail.com>

It should be possible to open the link multiple times, but only submit the
password reset once. If that's not the case (sounds like it is) feel free
to create a JIRA issue to report this as a bug.

On 10 February 2016 at 05:24, Michael Anthon <michael.anthon at infoview.com.au
> wrote:

> We are having issues with some users when they are attempting to use the
> password reset feature.  It does work for most users however for some they
> always end up at an error page saying "WE'RE SORRY ... An error occurred,
> please login again through your application"
>
> What I have been able to determine so far is that for the affected users
> we are seeing a double hit on that URL in the server logs and from what I
> understand, these reset URLs are invalidated as soon as they are accessed.
>
> So here's the state of play
> * works for most users
> * some users hitting the reset URL twice
> * URL is only valid for the first access (I'm not 100% sure about this,
> can someone confirm please?)
> * URL is only valid for 30 minutes (but is being accessed within a few
> minutes of generation)
> * affected users are mostly using Outlook
> * some people tend to double click links in emails but I've verified with
> a reliable user that they are only clicking the link once
> * having the affected person send themselves another reset email and then
> copy and paste the URL from the mail client usually resolves this problem
>
> And questions
> * is this an issue anyone else has noticed with Outlook, doesn't affect
> ALL Outlook users, just some
> * is there a way to prevent the URL from being invalidated on initial
> access
> * is it feasible to change the behavior so that the URL is only
> invalidated when the password is changed
> * any other thoughts on how to avoid this issue?
>
> Thanks and Regards,
>
> Michael Anthon
> InfoView Technologies Pty Ltd
> 12/15 Adelaide St, Brisbane Qld 4000
> P O Box 15478, City East, Brisbane Qld 4000
> PH:          +61 7 3014 2204
> F:             +61 7 3014 2200
> M:           +61 408 768 055
> michael.anthon at infoview.com.au
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material from any
> computer. Any views or opinions expressed in this email are solely those of
> the author and do not necessarily represent those of InfoView Technologies
> Pty 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/20160210/4af26194/attachment.html 

From sthorger at redhat.com  Wed Feb 10 04:48:34 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 10 Feb 2016 10:48:34 +0100
Subject: [keycloak-user] Default client for a realm
In-Reply-To: <CAK-7U1iOoH4oUU2i9Cr6PUWN48dUSiACgBkxnNeyMT2fRwUvmw@mail.gmail.com>
References: <CAK-7U1hRHZAGeKm6ka3oT8A-A9vqHpAc0CeUaXQJ0jR0D2exMg@mail.gmail.com>
	<CAPyAMoaAU19atkxhSfgQRueM10x236fOKtzvkdPewDFxHU3i3w@mail.gmail.com>
	<CAJgngAfGC-e+j0c2AzM4YXUVSfV7yzzV0rThRGrhTicd6a5SaA@mail.gmail.com>
	<CAK-7U1iR4THBqw21dPs89s6otnhRaZbn+vBshb6maoA5HgHLLw@mail.gmail.com>
	<CAPyAMoY0Nb7bdqbi2VP6xv=XcSrk2M5QEYkZ7PJYu95Rg+MvJQ@mail.gmail.com>
	<CAK-7U1iFcuOnFRcYkWB7xC7mRWoMJqnz=JLtBP7R9xWYw3xtBg@mail.gmail.com>
	<CAK-7U1g_J9fQs5gc3TW4jCT_TLaxdp2SOMbbyphuKmojauZQ1A@mail.gmail.com>
	<CAK-7U1j2SZ_jLCvrSg8uhHP0diQ5W55Xw-ap6QrVFL-4GULKpw@mail.gmail.com>
	<CAJgngAdMKFnkFSZDFU7q8EdgCKOYX2HzmqocBS9uG62n6ehAzw@mail.gmail.com>
	<CAK-7U1iOoH4oUU2i9Cr6PUWN48dUSiACgBkxnNeyMT2fRwUvmw@mail.gmail.com>
Message-ID: <CAJgngAehuh=3svj=0EE-uCfHRvkNy7MX-=Cwbknr8smq5-kaJg@mail.gmail.com>

It's to late to add this for 1.9, so we need to wait with merging it after
we've branched 1.9.x.

I also need to figure out what to do with the client-registration service
as your PR adds this to "{realm}/clients" which is also the endpoint for
the client registration service.

On 9 February 2016 at 17:18, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Thanks for your input :)
>
> The redirect would only work after a successful authentication,
> so unauthenticated users couldn't "probe" the realm for clients / target
> urls.
>
> But I see your point that an authenticated "malicious" user could probe
> all
> clients if he knew all clientIds (potentially via the new API).
> Perhaps one could offer a way to define some kind of grouping concept to
> describe
> which clients that can see each other (client group?) - so only clients
> from within the
> same group would be eligible for such a redirect.
>
> Btw. I adapted your suggestion regarding the endpoint path (which is now:
> {realm}/clients/{client_id}/redirect)
> and created a JIRA issue [0] and PR [1] with my current impl as a base for
> further discussion.
>
> > Another thing is that it is related to a feature we want to add at some
> point.
> > We'd like to be able to have a SSO > page that lists all clients,
> including icons and links to the clients.
> > This would have two use-cases:
> > 1. As a landing page on SSO server, and as a way for users to find all
> applications they can login to
>
> This would be really helpful - is this supposed to replace the
> applications section in the account page?
>

The plan was to have a separate page. It would be simpler than the one in
account management as it would simply list the applications, not show
access.


>
> > 2. A rest service would enable applications to get a list of all clients
> and provide a link
> > to other applications in the realm (like Google does with the square
> boxes icon)
>
> This would also be very helpful, currently I pull the information with the
> keycloak admin client
> in order to render such a page. A dedicated endpoint that returns clients
> metadata in JSON format
>
would be neat. Are you planning to just build a dedicated page of all apps
> or also a html/js widget like the 9 square app selector?
>

We where only planning on doing the REST endpoints and the applications
landing page

Not sure a html/js widget would be that useful. It would be fairly simple
to create your own using the REST endpoints and chances are we wouldn't be
able to create one that accommodates everyone needs so most folks would end
up having to do their own.


>
> [0] https://issues.jboss.org/browse/KEYCLOAK-2469
> [1] https://github.com/keycloak/keycloak/pull/2202
>
>
> 2016-02-09 12:18 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> One concern with including this is if there's some potential way it can
>> be a vulnerability.
>>
>> The only thing I can think of is that it allows figuring out the base url
>> for a client. That could then be used to figure out valid redirect uris for
>> a client. Don't think that's a huge deal though.
>>
>> Another thing is that it is related to a feature we want to add at some
>> point. We'd like to be able to have a SSO page that lists all clients,
>> including icons and links to the clients. This would have two use-cases:
>> 1. As a landing page on SSO server, and as a way for users to find all
>> applications they can login to
>> 2. A rest service would enable applications to get a list of all clients
>> and provide a link to other applications in the realm (like Google does
>> with the square boxes icon)
>>
>> With that in mind it would be better if the URL for client redirect was
>> "{realm}/clients/{client-id}/redirect" as that would allows us to use
>> "{realm}/clients" in the future for the above feature. "{realm}/clients" is
>> already used by ClientRegistrationService, but I think we can move that to
>> "{realm}/clients/registration" as there's probably not that many people
>> that are using the client registration service yet.
>>
>> On 9 February 2016 at 12:02, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Hello,
>>>
>>> any ideas regarding this?
>>>
>>> We need to link to a default application from several applications and
>>> it would be helpful if keycloak would provide said redirect mechanism, such
>>> that
>>> each application would only need to know the clientId of the default
>>> client application and keycloak performs the proper redirect to the actual
>>> target application.
>>>
>>> The example posted earlier works like a charm. This could even be
>>> extended to the point that in case no clientId is given keycloak can decide
>>> which client to redirect to.
>>>
>>> Cheers,
>>> Thomas
>>>
>>> 2016-02-05 19:05 GMT+01:00 Thomas Darimont <
>>> thomas.darimont at googlemail.com>:
>>>
>>>> Quick update - I did some further experiments with this...
>>>>
>>>> I added /redirect path to the a
>>>> org.keycloak.services.resources.RealmsResource
>>>> like: @Path("{realm}/{client-id}/redirect")
>>>> see code fragment below.
>>>>
>>>> This allows keycloak to initiate a redirect to the browser with the
>>>> actual
>>>> target url of the client. Other clients now only need to now the realm
>>>> and clientId
>>>> to generate a link that eventually redirects to the target application.
>>>>
>>>> Usage:
>>>> GET http://localhost:8081/auth/realms/master/launchpad/redirect -> 302
>>>> response with location: http://apps.corp.local/launchpad
>>>>
>>>> Any chance to get this in as a PR?
>>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>>     @GET
>>>>     @Path("{realm}/{client-id}/redirect")
>>>>     public Response getRedirect(final @PathParam("realm") String
>>>> realmName, final @PathParam("client-id") String clientId) throws Exception{
>>>>
>>>>         RealmModel realm = init(realmName);
>>>>
>>>>         if (realm == null){
>>>>             return null;
>>>>         }
>>>>
>>>>         ClientModel client = realm.getClientByClientId(clientId);
>>>>
>>>>         if (client == null){
>>>>             return null;
>>>>         }
>>>>
>>>>         if (client.getRootUrl() == null){
>>>>             return
>>>> Response.temporaryRedirect(uriInfo.getAbsolutePathBuilder().replacePath(client.getBaseUrl()).build()).build();
>>>>         }
>>>>
>>>>         return
>>>> Response.temporaryRedirect(URI.create(client.getRootUrl() +
>>>> client.getBaseUrl())).build();
>>>>     }
>>>>
>>>> 2016-02-05 16:23 GMT+01:00 Thomas Darimont <
>>>> thomas.darimont at googlemail.com>:
>>>>
>>>>> Hello,
>>>>>
>>>>> 2016-02-05 15:22 GMT+01:00 Thomas Raehalme <
>>>>> thomas.raehalme at aitiofinland.com>:
>>>>>
>>>>>> I understand this as well, but it has not been uncommon to encounter
>>>>>> a situation where the user needs to know where to go next, because Keycloak
>>>>>> doesn't have a link available.
>>>>>
>>>>>
>>>>> with a redirect facility as outlined above - one could render a link
>>>>> to the "$KEYCLOAK_BASE_URL/redirect" or
>>>>> lookup the "default" client in order to render the client base url
>>>>> link with a proper label (client name).
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/c09224f5/attachment-0001.html 

From eduard.matuszak at atos.net  Wed Feb 10 04:56:47 2016
From: eduard.matuszak at atos.net (Matuszak, Eduard)
Date: Wed, 10 Feb 2016 09:56:47 +0000
Subject: [keycloak-user] angularjs ng2 sample
Message-ID: <61D077C6283D454FAFD06F6AC4AB74D723D7B263@DEFTHW99EZ1MSX.ww931.my-it-solutions.net>

Hello

We are adviced to implement the GUI of a new project with angularjs ng2. There is an inspiring sample (https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app) for using keycloak.js-library in colaboration with the older angular version. Do you intend to publish a comparable example based on ng2 in the near future? This would be very helpful.

Thanks in advance for your feedback, Eduard Matuszak


Dr. Eduard Matuszak

Worldline, an atos company
T  +49 (211)399 398 63
M +49 (163)166 23 67
F +49(211) 399 22 430
eduard.matuszak at atos.net<mailto:eduard.matuszak at atos.net>
Max-Stromeyer-Stra?e 116
78467 Konstanz
Germany
de.worldline.com<http://worldline.com/de/1/Home.html>
worldline.jobs.de<http://worldline.jobs.de>
facebook.com/WorldlineKarriere<http://www.facebook.com/WorldlineKarriere>



Worldline GmbH
Gesch?ftsf?hrer: Wolf Kunisch
Aufsichtsratsvorsitzender: Christophe Duquenne
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister: Frankfurt/Main HRB 40 417

* * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail by error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and shall not be liable for any damages resulting from any virus transmitted.
* * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/551270f9/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture (Device Independent Bitmap) 1.jpg
Type: image/jpeg
Size: 1226 bytes
Desc: Picture (Device Independent Bitmap) 1.jpg
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/551270f9/attachment.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Picture (Device Independent Bitmap) 2.jpg
Type: image/jpeg
Size: 2886 bytes
Desc: Picture (Device Independent Bitmap) 2.jpg
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/551270f9/attachment-0001.jpg 

From sthorger at redhat.com  Wed Feb 10 05:03:32 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 10 Feb 2016 11:03:32 +0100
Subject: [keycloak-user] angularjs ng2 sample
In-Reply-To: <61D077C6283D454FAFD06F6AC4AB74D723D7B263@DEFTHW99EZ1MSX.ww931.my-it-solutions.net>
References: <61D077C6283D454FAFD06F6AC4AB74D723D7B263@DEFTHW99EZ1MSX.ww931.my-it-solutions.net>
Message-ID: <CAJgngAefaZXHwG3peZZx0v_7Jg+aWYX4oO1BqhKf1JWRQvEjdA@mail.gmail.com>

The main issue with Angular is that Keycloak and the Route provider
conflicts with each other, which causes a endless redirect loop. Current
work around we have is to make sure Keycloak is fully initialized before
Angular is bootstrap. The proper solution would be to have a Angular
library for Keycloak that can handle this.

We have not had time to look at that, nor have we looked at Angular2 at
all. So it would be a while until we would get to this, unless someone from
the community wants to contribute it.

On 10 February 2016 at 10:56, Matuszak, Eduard <eduard.matuszak at atos.net>
wrote:

> Hello
>
> We are adviced to implement the GUI of a new project with angularjs ng2.
> There is an inspiring sample (
> https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app)
> for using keycloak.js-library in colaboration with the older angular
> version. Do you intend to publish a comparable example based on ng2 in the
> near future? This would be very helpful.
>
> Thanks in advance for your feedback, Eduard Matuszak
>
> *Dr. Eduard Matuszak*
>
> Worldline, an atos company
> T  +49 (211)399 398 63
> M +49 (163)166 23 67
> F +49(211) 399 22 430
> *eduard.matuszak at atos.net* <eduard.matuszak at atos.net>
> Max-Stromeyer-Stra?e 116
> 78467 Konstanz
> Germany
> *de.worldline.com* <http://worldline.com/de/1/Home.html>
> *worldline.jobs.de* <http://worldline.jobs.de>
> *facebook.com/WorldlineKarriere*
> <http://www.facebook.com/WorldlineKarriere>
>
>
> Worldline GmbH
> Gesch?ftsf?hrer: Wolf Kunisch
> Aufsichtsratsvorsitzender: Christophe Duquenne
> Sitz der Gesellschaft: Frankfurt/Main
> Handelsregister: Frankfurt/Main HRB 40 417
>
> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
> This e-mail and the documents attached are confidential and intended
> solely for the addressee; it may also be privileged. If you receive this
> e-mail by error, please notify the sender immediately and destroy it. As
> its integrity cannot be secured on the internet, the Atos group liability
> cannot be triggered for the message content. Although the sender endeavors
> to maintain a computer virus-free network, the sender does not warrant that
> this transmission is virus-free and shall not be liable for any damages
> resulting from any virus transmitted.
> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
>
>
>
>
>
> _______________________________________________
> 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/20160210/5a49774b/attachment.html 

From sthorger at redhat.com  Wed Feb 10 07:45:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 10 Feb 2016 13:45:29 +0100
Subject: [keycloak-user] Keycloak redirect to wrong destination
In-Reply-To: <CAFZbuCNafLtX8=X6rcOLvq74NFsGufku+Ewvwa++XknM5oZE9w@mail.gmail.com>
References: <CAFZbuCNafLtX8=X6rcOLvq74NFsGufku+Ewvwa++XknM5oZE9w@mail.gmail.com>
Message-ID: <CAJgngAeaO_RdJS=KgH3sG2_Y4m6szZMfiwF2BbOfKMNctjyYLw@mail.gmail.com>

I can't reproduce this issue. We have tests that verify query parameters
are including in the redirect uri, I've also verified this manually with
our demo (
http://localhost:8180/customer-portal/customers/view.jsp?test=test2).

A rest service should be bearer-only though, it shouldn't redirect to login
page at all.

On 9 February 2016 at 11:43, Andrey Saroul <andrey.saroul at gmail.com> wrote:

> Recently I encountered with unexpected behavour of Keycloak.
> I did a simple rest service and had deployed Keycloak on one the same
> machine.
> I'm using keycloak 1.7.0 with WildFly 9.0.2
>
> My root URL of rest service is: /rest
> In Keycloak admin console I have configured my rest service this way:
> Client Protocol: openid-connect, Valid Redirect URIs: /rest/*
>
> I tried to access my test page of rest service by url:
> http://localhost:8080/rest/test?id=1
> I got redirect to login form, entered my login and password. That's fine,
> browser got valid jsessionid from Keycloak, BUT at the end of redirect
> chain I end up with root url of my webapp (http://localhost:8080/rest),
> but I tried to access different location (
> http://localhost:8080/rest/test?id=1) I expect to be redirected to the
> url I entered in the first place.
> I wonder, is this a bug or a misconfiguration issue?
>
> _______________________________________________
> 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/20160210/b6de9449/attachment-0001.html 

From bburke at redhat.com  Wed Feb 10 08:53:52 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Feb 2016 08:53:52 -0500
Subject: [keycloak-user] Issues with password reset link expiration
In-Reply-To: <CAJgngAdk_iN2vcR0i5t-3wriOe3xgQWAxPGWf1_D3sR62_s8JQ@mail.gmail.com>
References: <e3c4dce4db8649958379bf11260f79d1@HsteqMX04.nexonhosted.local>
	<CAJgngAdk_iN2vcR0i5t-3wriOe3xgQWAxPGWf1_D3sR62_s8JQ@mail.gmail.com>
Message-ID: <56BB40F0.1080204@redhat.com>

We changed the "error" message in I think 1.9?  Maybe 1.8 to say "You 
clicked on a stale link.  Maybe you have already verified your email?"  
I'll look into improving this I guess.

On 2/10/2016 4:21 AM, Stian Thorgersen wrote:
> It should be possible to open the link multiple times, but only submit 
> the password reset once. If that's not the case (sounds like it is) 
> feel free to create a JIRA issue to report this as a bug.
>
> On 10 February 2016 at 05:24, Michael Anthon 
> <michael.anthon at infoview.com.au 
> <mailto:michael.anthon at infoview.com.au>> wrote:
>
>     We are having issues with some users when they are attempting to
>     use the password reset feature.  It does work for most users
>     however for some they always end up at an error page saying "WE'RE
>     SORRY ... An error occurred, please login again through your
>     application"
>
>     What I have been able to determine so far is that for the affected
>     users we are seeing a double hit on that URL in the server logs
>     and from what I understand, these reset URLs are invalidated as
>     soon as they are accessed.
>
>     So here's the state of play
>     * works for most users
>     * some users hitting the reset URL twice
>     * URL is only valid for the first access (I'm not 100% sure about
>     this, can someone confirm please?)
>     * URL is only valid for 30 minutes (but is being accessed within a
>     few minutes of generation)
>     * affected users are mostly using Outlook
>     * some people tend to double click links in emails but I've
>     verified with a reliable user that they are only clicking the link
>     once
>     * having the affected person send themselves another reset email
>     and then copy and paste the URL from the mail client usually
>     resolves this problem
>
>     And questions
>     * is this an issue anyone else has noticed with Outlook, doesn't
>     affect ALL Outlook users, just some
>     * is there a way to prevent the URL from being invalidated on
>     initial access
>     * is it feasible to change the behavior so that the URL is only
>     invalidated when the password is changed
>     * any other thoughts on how to avoid this issue?
>
>     Thanks and Regards,
>
>     Michael Anthon
>     InfoView Technologies Pty Ltd
>     12/15 Adelaide St, Brisbane Qld 4000
>     P O Box 15478, City East, Brisbane Qld 4000
>     PH: +61 7 3014 2204 <tel:%2B61%207%203014%202204>
>     F: +61 7 3014 2200 <tel:%2B61%207%203014%202200>
>     M: +61 408 768 055 <tel:%2B61%20408%20768%20055>
>     michael.anthon at infoview.com.au <mailto:michael.anthon at infoview.com.au>
>
>     The information transmitted is intended only for the person or
>     entity to which it is addressed and may contain confidential
>     and/or privileged material. Any review, retransmission,
>     dissemination or other use of, or taking of any action in reliance
>     upon, this information by persons or entities other than the
>     intended recipient is prohibited. If you received this in error,
>     please contact the sender and delete the material from any
>     computer. Any views or opinions expressed in this email are solely
>     those of the author and do not necessarily represent those of
>     InfoView Technologies Pty Ltd.
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/91f5b410/attachment.html 

From jeremy at jeremysimon.com  Wed Feb 10 08:56:38 2016
From: jeremy at jeremysimon.com (Jeremy Simon)
Date: Wed, 10 Feb 2016 08:56:38 -0500
Subject: [keycloak-user] spring security getting username
In-Reply-To: <CAPFuFv_1vZ8LDYwHU+CfT29+7Pg7GC1QdvE+PF=Vy52O17TrqQ@mail.gmail.com>
References: <CAPFuFv9mRbfpQM6Yo7X34n=Pb31pQbGBodjw-0F0uz4EGkeZog@mail.gmail.com>
	<CAK-7U1gnrUQjmGYOpEw9Bq10hGGbphXEUsTWK+Cx4cSoy6PyDA@mail.gmail.com>
	<CAPFuFv_1vZ8LDYwHU+CfT29+7Pg7GC1QdvE+PF=Vy52O17TrqQ@mail.gmail.com>
Message-ID: <CAPFuFv85qLnvPz3ckeaWX_S7rrkO7tXMONqLf1DE76gVsOkHrQ@mail.gmail.com>

So, this is nice that it can be fixed by hand.  I'm wondering, is
there any way to configure these things for a particular client or
realm so that when you're downloading the keycloak.json from the admin
console that it's present?
jeremy
jeremy at jeremysimon.com
www.JeremySimon.com


On Tue, Feb 9, 2016 at 3:44 PM, Jeremy Simon <jeremy at jeremysimon.com> wrote:
> That's the trick!  Thank you!
> jeremy
> jeremy at jeremysimon.com
> www.JeremySimon.com
>
>
> On Tue, Feb 9, 2016 at 3:25 PM, Thomas Darimont
> <thomas.darimont at googlemail.com> wrote:
>> Hello Jeremy,
>>
>> try adding: "principal-attribute": "preferred_username" to your
>> keycloak.json.
>>
>> See:
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>>
>> Cheers,
>> Thomas
>>
>> 2016-02-09 20:47 GMT+01:00 Jeremy Simon <jeremy at jeremysimon.com>:
>>>
>>> Hi,
>>>
>>> I can't seem to get my user's name using the keycloak adaptor for
>>> spring security.  I have a rest controller that i'm trying this chunk
>>> of code:
>>>
>>> ...
>>> Authentication KeyCloakAuth =
>>> SecurityContextHolder.getContext().getAuthentication();
>>> KeycloakAccount  keyAccount = ((KeycloakAuthenticationToken)
>>> KeyCloakAuth).getAccount();
>>>
>>> String username1 = keyAccount.getPrincipal().getName()
>>> String username2 =
>>> SecurityContextHolder.getContext().getAuthentication().getName()
>>>
>>> KeycloakPrincipal<?> prince = (KeycloakPrincipal<?>)
>>> ((KeycloakAuthenticationToken) KeyCloakAuth).getPrincipal();
>>> String username3 = prince.getName();
>>>
>>> ...
>>>
>>>
>>> username1, username2, username3 will have something like this:
>>> aa5f6e42-9463-4862-a750-bd0c092daf11
>>>
>>>
>>> I gleaned this from some stackoverflow examples that claimed these
>>> approached worked... There something I don't have set right?
>>>
>>>
>>> jeremy
>>> jeremy at jeremysimon.com
>>> www.JeremySimon.com
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user

From sthorger at redhat.com  Wed Feb 10 08:58:15 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 10 Feb 2016 14:58:15 +0100
Subject: [keycloak-user] Issues with password reset link expiration
In-Reply-To: <56BB40F0.1080204@redhat.com>
References: <e3c4dce4db8649958379bf11260f79d1@HsteqMX04.nexonhosted.local>
	<CAJgngAdk_iN2vcR0i5t-3wriOe3xgQWAxPGWf1_D3sR62_s8JQ@mail.gmail.com>
	<56BB40F0.1080204@redhat.com>
Message-ID: <CAJgngAfiUdD6TJviSRf3j8erStY3atLzk3ygFEXCgwst+wnu-Q@mail.gmail.com>

It's not about the error message though. It should be possible to open the
link multiple times as long as the form is not submitted.

On 10 February 2016 at 14:53, Bill Burke <bburke at redhat.com> wrote:

> We changed the "error" message in I think 1.9?  Maybe 1.8 to say "You
> clicked on a stale link.  Maybe you have already verified your email?"
> I'll look into improving this I guess.
>
>
> On 2/10/2016 4:21 AM, Stian Thorgersen wrote:
>
> It should be possible to open the link multiple times, but only submit the
> password reset once. If that's not the case (sounds like it is) feel free
> to create a JIRA issue to report this as a bug.
>
> On 10 February 2016 at 05:24, Michael Anthon <
> michael.anthon at infoview.com.au> wrote:
>
>> We are having issues with some users when they are attempting to use the
>> password reset feature.  It does work for most users however for some they
>> always end up at an error page saying "WE'RE SORRY ... An error occurred,
>> please login again through your application"
>>
>> What I have been able to determine so far is that for the affected users
>> we are seeing a double hit on that URL in the server logs and from what I
>> understand, these reset URLs are invalidated as soon as they are accessed.
>>
>> So here's the state of play
>> * works for most users
>> * some users hitting the reset URL twice
>> * URL is only valid for the first access (I'm not 100% sure about this,
>> can someone confirm please?)
>> * URL is only valid for 30 minutes (but is being accessed within a few
>> minutes of generation)
>> * affected users are mostly using Outlook
>> * some people tend to double click links in emails but I've verified with
>> a reliable user that they are only clicking the link once
>> * having the affected person send themselves another reset email and then
>> copy and paste the URL from the mail client usually resolves this problem
>>
>> And questions
>> * is this an issue anyone else has noticed with Outlook, doesn't affect
>> ALL Outlook users, just some
>> * is there a way to prevent the URL from being invalidated on initial
>> access
>> * is it feasible to change the behavior so that the URL is only
>> invalidated when the password is changed
>> * any other thoughts on how to avoid this issue?
>>
>> Thanks and Regards,
>>
>> Michael Anthon
>> InfoView Technologies Pty Ltd
>> 12/15 Adelaide St, Brisbane Qld 4000
>> P O Box 15478, City East, Brisbane Qld 4000
>> PH:          +61 7 3014 2204 <%2B61%207%203014%202204>
>> F:             +61 7 3014 2200 <%2B61%207%203014%202200>
>> M:           +61 408 768 055 <%2B61%20408%20768%20055>
>> michael.anthon at infoview.com.au
>>
>> The information transmitted is intended only for the person or entity to
>> which it is addressed and may contain confidential and/or privileged
>> material. Any review, retransmission, dissemination or other use of, or
>> taking of any action in reliance upon, this information by persons or
>> entities other than the intended recipient is prohibited. If you received
>> this in error, please contact the sender and delete the material from any
>> computer. Any views or opinions expressed in this email are solely those of
>> the author and do not necessarily represent those of InfoView Technologies
>> Pty Ltd.
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160210/fec405eb/attachment-0001.html 

From thomas.darimont at googlemail.com  Wed Feb 10 09:00:29 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 10 Feb 2016 15:00:29 +0100
Subject: [keycloak-user] spring security getting username
In-Reply-To: <CAPFuFv85qLnvPz3ckeaWX_S7rrkO7tXMONqLf1DE76gVsOkHrQ@mail.gmail.com>
References: <CAPFuFv9mRbfpQM6Yo7X34n=Pb31pQbGBodjw-0F0uz4EGkeZog@mail.gmail.com>
	<CAK-7U1gnrUQjmGYOpEw9Bq10hGGbphXEUsTWK+Cx4cSoy6PyDA@mail.gmail.com>
	<CAPFuFv_1vZ8LDYwHU+CfT29+7Pg7GC1QdvE+PF=Vy52O17TrqQ@mail.gmail.com>
	<CAPFuFv85qLnvPz3ckeaWX_S7rrkO7tXMONqLf1DE76gVsOkHrQ@mail.gmail.com>
Message-ID: <CAK-7U1jh6kzzezc3UFdzwXH9oNXTprNFpNr=rtJoW1-i=v3Tpg@mail.gmail.com>

Hello Jeremy,

have a look at this issue:
https://issues.jboss.org/browse/KEYCLOAK-2079?jql=project%20%3D%20KEYCLOAK%20AND%20status%20%3D%20Open%20AND%20text%20~%20%22installation%22

Cheers,
Thomas

2016-02-10 14:56 GMT+01:00 Jeremy Simon <jeremy at jeremysimon.com>:

> So, this is nice that it can be fixed by hand.  I'm wondering, is
> there any way to configure these things for a particular client or
> realm so that when you're downloading the keycloak.json from the admin
> console that it's present?
> jeremy
> jeremy at jeremysimon.com
> www.JeremySimon.com
>
>
> On Tue, Feb 9, 2016 at 3:44 PM, Jeremy Simon <jeremy at jeremysimon.com>
> wrote:
> > That's the trick!  Thank you!
> > jeremy
> > jeremy at jeremysimon.com
> > www.JeremySimon.com
> >
> >
> > On Tue, Feb 9, 2016 at 3:25 PM, Thomas Darimont
> > <thomas.darimont at googlemail.com> wrote:
> >> Hello Jeremy,
> >>
> >> try adding: "principal-attribute": "preferred_username" to your
> >> keycloak.json.
> >>
> >> See:
> >>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
> >>
> >> Cheers,
> >> Thomas
> >>
> >> 2016-02-09 20:47 GMT+01:00 Jeremy Simon <jeremy at jeremysimon.com>:
> >>>
> >>> Hi,
> >>>
> >>> I can't seem to get my user's name using the keycloak adaptor for
> >>> spring security.  I have a rest controller that i'm trying this chunk
> >>> of code:
> >>>
> >>> ...
> >>> Authentication KeyCloakAuth =
> >>> SecurityContextHolder.getContext().getAuthentication();
> >>> KeycloakAccount  keyAccount = ((KeycloakAuthenticationToken)
> >>> KeyCloakAuth).getAccount();
> >>>
> >>> String username1 = keyAccount.getPrincipal().getName()
> >>> String username2 =
> >>> SecurityContextHolder.getContext().getAuthentication().getName()
> >>>
> >>> KeycloakPrincipal<?> prince = (KeycloakPrincipal<?>)
> >>> ((KeycloakAuthenticationToken) KeyCloakAuth).getPrincipal();
> >>> String username3 = prince.getName();
> >>>
> >>> ...
> >>>
> >>>
> >>> username1, username2, username3 will have something like this:
> >>> aa5f6e42-9463-4862-a750-bd0c092daf11
> >>>
> >>>
> >>> I gleaned this from some stackoverflow examples that claimed these
> >>> approached worked... There something I don't have set right?
> >>>
> >>>
> >>> jeremy
> >>> jeremy at jeremysimon.com
> >>> www.JeremySimon.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/20160210/af5f7804/attachment.html 

From bburke at redhat.com  Wed Feb 10 09:15:48 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Feb 2016 09:15:48 -0500
Subject: [keycloak-user] Issues with password reset link expiration
In-Reply-To: <CAJgngAfiUdD6TJviSRf3j8erStY3atLzk3ygFEXCgwst+wnu-Q@mail.gmail.com>
References: <e3c4dce4db8649958379bf11260f79d1@HsteqMX04.nexonhosted.local>
	<CAJgngAdk_iN2vcR0i5t-3wriOe3xgQWAxPGWf1_D3sR62_s8JQ@mail.gmail.com>
	<56BB40F0.1080204@redhat.com>
	<CAJgngAfiUdD6TJviSRf3j8erStY3atLzk3ygFEXCgwst+wnu-Q@mail.gmail.com>
Message-ID: <56BB4614.8090509@redhat.com>

I think this may have been fixed in 1.9 with the flow changes I made.  I 
don't have time to try it out right now though.

On 2/10/2016 8:58 AM, Stian Thorgersen wrote:
> It's not about the error message though. It should be possible to open 
> the link multiple times as long as the form is not submitted.
>
> On 10 February 2016 at 14:53, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     We changed the "error" message in I think 1.9?  Maybe 1.8 to say
>     "You clicked on a stale link.  Maybe you have already verified
>     your email?"  I'll look into improving this I guess.
>
>
>     On 2/10/2016 4:21 AM, Stian Thorgersen wrote:
>>     It should be possible to open the link multiple times, but only
>>     submit the password reset once. If that's not the case (sounds
>>     like it is) feel free to create a JIRA issue to report this as a bug.
>>
>>     On 10 February 2016 at 05:24, Michael Anthon
>>     <michael.anthon at infoview.com.au
>>     <mailto:michael.anthon at infoview.com.au>> wrote:
>>
>>         We are having issues with some users when they are attempting
>>         to use the password reset feature.  It does work for most
>>         users however for some they always end up at an error page
>>         saying "WE'RE SORRY ... An error occurred, please login again
>>         through your application"
>>
>>         What I have been able to determine so far is that for the
>>         affected users we are seeing a double hit on that URL in the
>>         server logs and from what I understand, these reset URLs are
>>         invalidated as soon as they are accessed.
>>
>>         So here's the state of play
>>         * works for most users
>>         * some users hitting the reset URL twice
>>         * URL is only valid for the first access (I'm not 100% sure
>>         about this, can someone confirm please?)
>>         * URL is only valid for 30 minutes (but is being accessed
>>         within a few minutes of generation)
>>         * affected users are mostly using Outlook
>>         * some people tend to double click links in emails but I've
>>         verified with a reliable user that they are only clicking the
>>         link once
>>         * having the affected person send themselves another reset
>>         email and then copy and paste the URL from the mail client
>>         usually resolves this problem
>>
>>         And questions
>>         * is this an issue anyone else has noticed with Outlook,
>>         doesn't affect ALL Outlook users, just some
>>         * is there a way to prevent the URL from being invalidated on
>>         initial access
>>         * is it feasible to change the behavior so that the URL is
>>         only invalidated when the password is changed
>>         * any other thoughts on how to avoid this issue?
>>
>>         Thanks and Regards,
>>
>>         Michael Anthon
>>         InfoView Technologies Pty Ltd
>>         12/15 Adelaide St, Brisbane Qld 4000
>>         P O Box 15478, City East, Brisbane Qld 4000
>>         PH: +61 7 3014 2204 <tel:%2B61%207%203014%202204>
>>         F: +61 7 3014 2200 <tel:%2B61%207%203014%202200>
>>         M: +61 408 768 055 <tel:%2B61%20408%20768%20055>
>>         michael.anthon at infoview.com.au
>>         <mailto:michael.anthon at infoview.com.au>
>>
>>         The information transmitted is intended only for the person
>>         or entity to which it is addressed and may contain
>>         confidential and/or privileged material. Any review,
>>         retransmission, dissemination or other use of, or taking of
>>         any action in reliance upon, this information by persons or
>>         entities other than the intended recipient is prohibited. If
>>         you received this in error, please contact the sender and
>>         delete the material from any computer. Any views or opinions
>>         expressed in this email are solely those of the author and do
>>         not necessarily represent those of InfoView Technologies Pty Ltd.
>>
>>
>>         _______________________________________________
>>         keycloak-user mailing list
>>         keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/08cd7be0/attachment.html 

From sthorger at redhat.com  Wed Feb 10 09:25:57 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 10 Feb 2016 15:25:57 +0100
Subject: [keycloak-user] Issues with password reset link expiration
In-Reply-To: <56BB4614.8090509@redhat.com>
References: <e3c4dce4db8649958379bf11260f79d1@HsteqMX04.nexonhosted.local>
	<CAJgngAdk_iN2vcR0i5t-3wriOe3xgQWAxPGWf1_D3sR62_s8JQ@mail.gmail.com>
	<56BB40F0.1080204@redhat.com>
	<CAJgngAfiUdD6TJviSRf3j8erStY3atLzk3ygFEXCgwst+wnu-Q@mail.gmail.com>
	<56BB4614.8090509@redhat.com>
Message-ID: <CAJgngAd3NNYUXRaWYnf7rpKFxMzCLvVHGVXrmvjMUUxzFz2RzQ@mail.gmail.com>

Michael,

Can you confirm if this issue still exists on 1.9.0.CR1 and if it does
create a JIRA issue?

On 10 February 2016 at 15:15, Bill Burke <bburke at redhat.com> wrote:

> I think this may have been fixed in 1.9 with the flow changes I made.  I
> don't have time to try it out right now though.
>
>
> On 2/10/2016 8:58 AM, Stian Thorgersen wrote:
>
> It's not about the error message though. It should be possible to open the
> link multiple times as long as the form is not submitted.
>
> On 10 February 2016 at 14:53, Bill Burke <bburke at redhat.com> wrote:
>
>> We changed the "error" message in I think 1.9?  Maybe 1.8 to say "You
>> clicked on a stale link.  Maybe you have already verified your email?"
>> I'll look into improving this I guess.
>>
>>
>> On 2/10/2016 4:21 AM, Stian Thorgersen wrote:
>>
>> It should be possible to open the link multiple times, but only submit
>> the password reset once. If that's not the case (sounds like it is) feel
>> free to create a JIRA issue to report this as a bug.
>>
>> On 10 February 2016 at 05:24, Michael Anthon <
>> <michael.anthon at infoview.com.au>michael.anthon at infoview.com.au> wrote:
>>
>>> We are having issues with some users when they are attempting to use the
>>> password reset feature.  It does work for most users however for some they
>>> always end up at an error page saying "WE'RE SORRY ... An error occurred,
>>> please login again through your application"
>>>
>>> What I have been able to determine so far is that for the affected users
>>> we are seeing a double hit on that URL in the server logs and from what I
>>> understand, these reset URLs are invalidated as soon as they are accessed.
>>>
>>> So here's the state of play
>>> * works for most users
>>> * some users hitting the reset URL twice
>>> * URL is only valid for the first access (I'm not 100% sure about this,
>>> can someone confirm please?)
>>> * URL is only valid for 30 minutes (but is being accessed within a few
>>> minutes of generation)
>>> * affected users are mostly using Outlook
>>> * some people tend to double click links in emails but I've verified
>>> with a reliable user that they are only clicking the link once
>>> * having the affected person send themselves another reset email and
>>> then copy and paste the URL from the mail client usually resolves this
>>> problem
>>>
>>> And questions
>>> * is this an issue anyone else has noticed with Outlook, doesn't affect
>>> ALL Outlook users, just some
>>> * is there a way to prevent the URL from being invalidated on initial
>>> access
>>> * is it feasible to change the behavior so that the URL is only
>>> invalidated when the password is changed
>>> * any other thoughts on how to avoid this issue?
>>>
>>> Thanks and Regards,
>>>
>>> Michael Anthon
>>> InfoView Technologies Pty Ltd
>>> 12/15 Adelaide St, Brisbane Qld 4000
>>> P O Box 15478, City East, Brisbane Qld 4000
>>> PH:          +61 7 3014 2204 <%2B61%207%203014%202204>
>>> F:             +61 7 3014 2200 <%2B61%207%203014%202200>
>>> M:           +61 408 768 055 <%2B61%20408%20768%20055>
>>> michael.anthon at infoview.com.au
>>>
>>> The information transmitted is intended only for the person or entity to
>>> which it is addressed and may contain confidential and/or privileged
>>> material. Any review, retransmission, dissemination or other use of, or
>>> taking of any action in reliance upon, this information by persons or
>>> entities other than the intended recipient is prohibited. If you received
>>> this in error, please contact the sender and delete the material from any
>>> computer. Any views or opinions expressed in this email are solely those of
>>> the author and do not necessarily represent those of InfoView Technologies
>>> Pty Ltd.
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.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 Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/4e6c60d0/attachment-0001.html 

From technolengy at gmail.com  Wed Feb 10 11:02:51 2016
From: technolengy at gmail.com (Steve Nolen)
Date: Wed, 10 Feb 2016 16:02:51 +0000
Subject: [keycloak-user] trouble acting as SP with testshib.org IdP
In-Reply-To: <CAPNq5vbz4j5JGBP9S-FO4Pagy4402YSLJD2BkgN5Erecfxv0SQ@mail.gmail.com>
References: <CAC_FVB7XdAzxSOCX4Dsq0gz4M+xiwChSiwdYjOhXqVLB7mREbQ@mail.gmail.com>
	<CAPNq5vbz4j5JGBP9S-FO4Pagy4402YSLJD2BkgN5Erecfxv0SQ@mail.gmail.com>
Message-ID: <CAC_FVB6HywJ-2pxmXy8zTASwqO8KgTEajzbva8NJ43r6gk+Aqg@mail.gmail.com>

Hi J?r?me,

Thanks for the help! I swapped the NameId in keycloak for this broker to
unspecified (I uploaded my sp metadata to testshib.org again as well just
in case) and am still receiving the same error.

On Wed, Feb 10, 2016 at 1:10 AM J?r?me Blanchard <jayblanc at gmail.com> wrote:

> Hi Steve,
>
> I'm using Keycloak as a shibboleth SP in a federation (Renater) and It's
> working fine. The problem you encounter comes from the fact that you ask
> for a persistent nameId in the config of your SP and, according to the
> provider details, it's only able to send transient nameId.
> Feel the parameter of nameId to undefined and check the authentication
> again.
>
> Best regards, J?r?me.
>
> Le mer. 10 f?vr. 2016 ? 03:57, Steve Nolen <technolengy at gmail.com> a
> ?crit :
>
>> Hi!
>>
>> First of all, keycloak is legitimately awesome!
>>
>> I was attempting to test the use of keycloak as a shibboleth SP today
>> (testing against the testshib.org test IdP) and am having some trouble.
>>
>> Keycloak Version: 1.9.0CR1 (using it on openshift currently)
>>
>> Both sides seem to be set up as they should (I used the testshib endpoint
>> to import the settings to keycloak). I'm able to take the redirect over to
>> idp.testshib but on logging in I get a 500 Internal Server Error from
>> keycloak.  The message is "No Assertion from response" (stack trace below).
>>
>> Any thoughts on what might be missing?
>>
>> ==== stack trace ====
>> http://pastebin.com/3tsApUKK
>>
>> ==== broker details ====
>>
>> https://keycloak-technolengy.rhcloud.com/auth/realms/technolengy/broker/testshib.org/endpoint/descriptor
>>
>> ==== provider details ====
>> https://www.testshib.org/metadata/testshib-providers.xml
>>
>> Thank you!
>> Steve
>>
> _______________________________________________
>> 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/20160210/02dd324c/attachment.html 

From RRathod at carbonite.com  Wed Feb 10 15:00:59 2016
From: RRathod at carbonite.com (Riddhi Rathod)
Date: Wed, 10 Feb 2016 20:00:59 +0000
Subject: [keycloak-user] Keycloak clustering in AWS
Message-ID: <5D0EA50B-5F8C-4F79-A72F-738A1E586560@carboniteinc.com>

I am trying to setup keycloak cluster with a shared database in AWS environment. I followed all steps mentioned on this link: http://keycloak.github.io/docs/userguide/keycloak-server/html/clustering.html

Keycloak nodes are AWS EC2 and shared database is AWS RDS. How does the keycloak instances identify each other in cluster in AWS (how does multicast work in a AWS VPC)?

Has anyone tried this before? Any references or things to take care of list would be great.


Thank you,

Riddhi Rathod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/c5d8ea5b/attachment.html 

From bburke at redhat.com  Wed Feb 10 15:04:44 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Feb 2016 15:04:44 -0500
Subject: [keycloak-user] Keycloak clustering in AWS
In-Reply-To: <5D0EA50B-5F8C-4F79-A72F-738A1E586560@carboniteinc.com>
References: <5D0EA50B-5F8C-4F79-A72F-738A1E586560@carboniteinc.com>
Message-ID: <56BB97DC.5000006@redhat.com>

I don't have the link, but search the email archives of 
keycloak-user/keycloak-dev  There was a long discussion about this. 
Basically, you can't use multicast and you have to configure 
jgroups/infinispan to use a different protocol.

On 2/10/2016 3:00 PM, Riddhi Rathod wrote:
> I am trying to setup keycloak cluster with a shared database in AWS 
> environment. I followed all steps mentioned on this link: 
> http://keycloak.github.io/docs/userguide/keycloak-server/html/clustering.html
> Keycloak nodes are AWS EC2 and shared database is AWS RDS. How does 
> the keycloak instances identify each other in cluster in AWS (how does 
> multicast work in a AWS VPC)?
> Has anyone tried this before? Any references or things to take care of 
> list would be great.
> Thank you,
> Riddhi Rathod
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/348b9e66/attachment.html 

From darkness.renann at gmail.com  Wed Feb 10 15:23:12 2016
From: darkness.renann at gmail.com (Renann Prado)
Date: Wed, 10 Feb 2016 18:23:12 -0200
Subject: [keycloak-user] NullPointerException during deployment
Message-ID: <CAEBys6+VE-Ni16t_P+nZp-Fo_p4fvJwr0Sq5vc5VZZ--yxGmBw@mail.gmail.com>

I've been following keycloak guide, but I'm facing the below exception.
I'm trying to secure a WAR that is inside of an EAR, I've tried to add
below two dependencies in my pom.xml.
What am I missing?

*Wildfly version: *10.0.0.Final
*Keycloak version: *1.9.0.CR1

*Dependencies (tried in EAR and in WAR, no luck):*

<dependency>
    <groupId>org.keycloak</groupId>
    <artifactId>keycloak-core</artifactId>
    <version>1.9.0.CR1</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>org.keycloak</groupId>
    <artifactId>keycloak-adapter-core</artifactId>
    <version>1.9.0.CR1</version>
    <scope>provided</scope>
</dependency>

*Subsystem configuration:*

<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
    <secure-deployment name="Test-web-1.0-SNAPSHOT.war">
        <realm>TestRealm</realm>
        <resource>test-resource</resource>

<realm-public-key>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmpxbZQMAf2NPcWCbdVWfu3JKEZ5PHuL+a5JTzyuln/wXpfhGPyCDS8rYDj2tf5lA8WQYoV8M5ip3DbCdL43wsW8/oJM/UOKn7mwy2x0OdW40bw1c8b1D6FveliIXwtovyw0EGCFn67qLdtHPLAlVvv5UXPIPFCakzdx1xS/6zgZ1uF2fzwLZpLh21M9XYNHQk6ui047+13Uf5H5yYQNLin8WluZ4JLfO8teVV9ARTqezVoZ5/+SNH4Mw+N1i7sGr13mzl51XvpFmm10Yx0dNiuy+WPA9xv1eNWcWgQWXxCEzDBenn59pmZ9JnTpoOqvZknmBGqyQPDqN9tJIWnWZKQIDAQAB</realm-public-key>
        <auth-server-url>http://localhost:8082/auth</auth-server-url>
        <ssl-required>none</ssl-required>
        <credential name="secret">password</credential>
    </secure-deployment>
</subsystem>

*Exception*


8:13:18,779 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3)
MSC000001: Failed to start service
jboss.deployment.unit."Test-ear.ear".DEPENDENCIES:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."Test-ear.ear".DEPENDENCIES: WFLYSRV0153: Failed to
process phase DEPENDENCIES of deployment "Test-ear.ear"
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
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)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at
org.keycloak.subsystem.adapter.extension.KeycloakDependencyProcessor.deploy(KeycloakDependencyProcessor.java:52)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more

18:13:18,784 ERROR [org.jboss.as.controller.management-operation]
(management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed -
address: ([("deployment" => "Test-ear.ear")]) - failure description:
{"WFLYCTL0080: Failed services" =>
{"jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES" =>
"org.jboss.msc.service.StartException in service
jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES: WFLYSRV0153: Failed to
process phase DEPENDENCIES of deployment \"Test-ear.ear\"
    Caused by: java.lang.NullPointerException"}}
18:13:18,786 ERROR [org.jboss.as.server] (management-handler-thread - 2)
WFLYSRV0021: Deploy of deployment "Test-ear.ear" was rolled back with the
following failure message:
{"WFLYCTL0080: Failed services" =>
{"jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES" =>
"org.jboss.msc.service.StartException in service
jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES: WFLYSRV0153: Failed to
process phase DEPENDENCIES of deployment \"Test-ear.ear\"
    Caused by: java.lang.NullPointerException"}}

Renann Prado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/761a0d47/attachment-0001.html 

From RRathod at carbonite.com  Wed Feb 10 18:01:49 2016
From: RRathod at carbonite.com (Riddhi Rathod)
Date: Wed, 10 Feb 2016 23:01:49 +0000
Subject: [keycloak-user] Device tokens with keycloak
Message-ID: <BC3430FF-7F33-4F0E-ACAE-66D90FE63673@carboniteinc.com>

Does Keycloak have the ability to provide ?device? tokens in addition to the user tokens ?

I found discussion link on device registration:  http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001116.html . However, I wanted to know whether or not this feature is supported now?


Thank you,
Riddhi Rathod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/04da444f/attachment.html 

From charles at dazen.com.br  Wed Feb 10 18:49:25 2016
From: charles at dazen.com.br (Charles Queiroz)
Date: Wed, 10 Feb 2016 20:49:25 -0300
Subject: [keycloak-user] Create user + keycloak-admin-client
Message-ID: <DB042FAE-0A0D-4938-8460-C60E3F537E09@dazen.com.br>

Hi folks, 

I?m trying programmatically add user in keycloak server using the admin client (version 1.8.0.RC3) like this post show (link: http://www.first8.nl/blog/programmatically-adding-users-in-keycloak/ <http://www.first8.nl/blog/programmatically-adding-users-in-keycloak/> ), but no success yet! ;( 



The Steps: 

1 - Add dependence on pom.xml like:

<dependency>
    <groupId>org.keycloak</groupId>
    <artifactId>keycloak-admin-client</artifactId>
    <version>1.8.0.CR3</version>
</dependency>

2 - Implement the method body like:


public User save(User user) {
    Keycloak kc = Keycloak.getInstance("http://localhost:8080/auth", "forum", ?admin", ?admin", "security-admin-console");

    CredentialRepresentation credential = new CredentialRepresentation();
    credential.setType(CredentialRepresentation.PASSWORD);
    credential.setValue(user.getPassword());
    UserRepresentation newUser = new UserRepresentation();
    newUser.setUsername(user.getLogin());
    newUser.setFirstName(user.getName());
    newUser.setCredentials(Arrays.asList(credential));

    kc.realm("forum").users().create(newUser);

    User saved = repository.save(user);
    savedUser.fire(saved);
    return saved;
}


When I run the app, the exception thrown is: 

20:46:03,583 DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (default task-14) Sending request: POST /auth/realms/forum/protocol/openid-connect/token HTTP/1.1
20:46:03,584 DEBUG [org.apache.http.wire] (default task-14)  >> "POST /auth/realms/forum/protocol/openid-connect/token HTTP/1.1[\r][\n]"
20:46:03,585 DEBUG [org.apache.http.wire] (default task-14)  >> "Accept: application/json[\r][\n]"
20:46:03,587 DEBUG [org.apache.http.wire] (default task-14)  >> "Accept-Encoding: gzip, deflate[\r][\n]"
20:46:03,589 DEBUG [org.apache.http.wire] (default task-14)  >> "Content-Type: application/x-www-form-urlencoded[\r][\n]"
20:46:03,591 DEBUG [org.apache.http.wire] (default task-14)  >> "Content-Length: 82[\r][\n]"
20:46:03,592 DEBUG [org.apache.http.wire] (default task-14)  >> "Host: localhost:8080[\r][\n]"
20:46:03,594 DEBUG [org.apache.http.wire] (default task-14)  >> "Connection: Keep-Alive[\r][\n]"
20:46:03,596 DEBUG [org.apache.http.wire] (default task-14)  >> "[\r][\n]"
20:46:03,598 DEBUG [org.apache.http.headers] (default task-14) >> POST /auth/realms/forum/protocol/openid-connect/token HTTP/1.1
20:46:03,599 DEBUG [org.apache.http.headers] (default task-14) >> Accept: application/json
20:46:03,601 DEBUG [org.apache.http.headers] (default task-14) >> Accept-Encoding: gzip, deflate
20:46:03,602 DEBUG [org.apache.http.headers] (default task-14) >> Content-Type: application/x-www-form-urlencoded
20:46:03,604 DEBUG [org.apache.http.headers] (default task-14) >> Content-Length: 82
20:46:03,605 DEBUG [org.apache.http.headers] (default task-14) >> Host: localhost:8080
20:46:03,606 DEBUG [org.apache.http.headers] (default task-14) >> Connection: Keep-Alive
20:46:03,610 DEBUG [org.apache.http.wire] (default task-14)  >> "grant_type=password&username=admin&password=admin&client_id=security-admin-console"
20:46:03,612 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-15) RESTEASY002315: PathInfo: /realms/forum/protocol/openid-connect/token
20:46:03,614 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-15) AUTHENTICATE CLIENT
20:46:03,614 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-15) client authenticator: client-secret
20:46:03,614 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-15) client authenticator SUCCESS: client-secret
20:46:03,614 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-15) Client security-admin-console authenticated by client-secret
20:46:03,615 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-15) AUTHENTICATE ONLY
20:46:03,615 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) processFlow
20:46:03,615 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) check execution: direct-grant-validate-username requirement: REQUIRED
20:46:03,616 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) authenticator: direct-grant-validate-username
20:46:03,616 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) invoke authenticator.authenticate
20:46:03,617 FINE  [org.mongodb.driver.protocol.query] (default task-15) Sending query of namespace forum.users on connection [connectionId{localValue:2, serverValue:184}] to server 127.0.0.1:27017
20:46:03,617 FINE  [org.mongodb.driver.protocol.query] (default task-15) Query completed
20:46:03,618 WARN  [org.keycloak.events] (default task-15) type=LOGIN_ERROR, realmId=forum, clientId=security-admin-console, userId=null, ipAddress=127.0.0.1, error=invalid_user_credentials, auth_method=openid-connect, grant_type=password, client_auth_method=client-secret, username=admin
20:46:03,619 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) authenticator FAILED: direct-grant-validate-username
20:46:03,624 DEBUG [org.apache.http.wire] (default task-14)  << "HTTP/1.1 401 Unauthorized[\r][\n]"
20:46:03,627 DEBUG [org.apache.http.wire] (default task-14)  << "Connection: keep-alive[\r][\n]"
20:46:03,629 DEBUG [org.apache.http.wire] (default task-14)  << "X-Powered-By: Undertow/1[\r][\n]"
20:46:03,631 DEBUG [org.apache.http.wire] (default task-14)  << "Server: WildFly/10[\r][\n]"
20:46:03,632 DEBUG [org.apache.http.wire] (default task-14)  << "Transfer-Encoding: chunked[\r][\n]"
20:46:03,634 DEBUG [org.apache.http.wire] (default task-14)  << "Content-Type: application/json[\r][\n]"
20:46:03,636 DEBUG [org.apache.http.wire] (default task-14)  << "Date: Wed, 10 Feb 2016 23:46:03 GMT[\r][\n]"
20:46:03,637 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
20:46:03,639 DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (default task-14) Receiving response: HTTP/1.1 401 Unauthorized
20:46:03,640 DEBUG [org.apache.http.headers] (default task-14) << HTTP/1.1 401 Unauthorized
20:46:03,642 DEBUG [org.apache.http.headers] (default task-14) << Connection: keep-alive
20:46:03,643 DEBUG [org.apache.http.headers] (default task-14) << X-Powered-By: Undertow/1
20:46:03,645 DEBUG [org.apache.http.headers] (default task-14) << Server: WildFly/10
20:46:03,646 DEBUG [org.apache.http.headers] (default task-14) << Transfer-Encoding: chunked
20:46:03,647 DEBUG [org.apache.http.headers] (default task-14) << Content-Type: application/json
20:46:03,649 DEBUG [org.apache.http.headers] (default task-14) << Date: Wed, 10 Feb 2016 23:46:03 GMT
20:46:03,651 DEBUG [org.apache.http.impl.client.DefaultHttpClient] (default task-14) Connection can be kept alive indefinitely
20:46:03,653 DEBUG [org.apache.http.impl.client.DefaultHttpClient] (default task-14) Authentication required
20:46:03,654 DEBUG [org.apache.http.impl.client.DefaultHttpClient] (default task-14) localhost:8080 requested authentication
20:46:03,656 DEBUG [org.apache.http.impl.client.DefaultHttpClient] (default task-14) Response contains no authentication challenges
20:46:03,665 DEBUG [org.apache.http.wire] (default task-14)  << "48[\r][\n]"
20:46:03,667 DEBUG [org.apache.http.wire] (default task-14)  << "{"error_description":"Invalid user credentials","error":"invalid_grant"}"
20:46:03,668 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
20:46:03,670 DEBUG [org.apache.http.wire] (default task-14)  << "0[\r][\n]"
20:46:03,671 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
20:46:03,673 DEBUG [org.apache.http.impl.conn.BasicClientConnectionManager] (default task-14) Releasing connection org.apache.http.impl.conn.ManagedClientConnectionImpl at 1d6c4f71
20:46:03,675 DEBUG [org.apache.http.impl.conn.BasicClientConnectionManager] (default task-14) Connection can be kept alive indefinitely
20:46:11,315 DEBUG [org.jboss.as.jpa] (default task-14) default task-14:transaction scoped EntityManager [forum.war#ForumPU]: closing entity managersession
20:46:11,315 DEBUG [org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl] (default task-14) Initiating JDBC connection release from afterTransaction
20:46:11,316 ERROR [org.jboss.as.ejb3.invocation] (default task-14) WFLYEJB0034: EJB Invocation failed on component UserRestEndpoint for method public javax.ws.rs.core.Response br.com.projetolead.forum.integration.rest.UserRestEndpoint.save(br.com.projetolead.forum.model.User,javax.servlet.http.HttpServletRequest) throws java.io.IOException: javax.ejb.EJBException: javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)


------

but, when I change the user to charles (no admin user. login: charles, password: java) the error is: 

------

20:41:18,314 DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (default task-14) Sending request: POST /auth/realms/forum/protocol/openid-connect/token HTTP/1.1
20:41:18,315 DEBUG [org.apache.http.wire] (default task-14)  >> "POST /auth/realms/forum/protocol/openid-connect/token HTTP/1.1[\r][\n]"
20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "Accept: application/json[\r][\n]"
20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "Accept-Encoding: gzip, deflate[\r][\n]"
20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "Content-Type: application/x-www-form-urlencoded[\r][\n]"
20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "Content-Length: 83[\r][\n]"
20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "Host: localhost:8080[\r][\n]"
20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "Connection: Keep-Alive[\r][\n]"
20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "[\r][\n]"
20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >> POST /auth/realms/forum/protocol/openid-connect/token HTTP/1.1
20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >> Accept: application/json
20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >> Accept-Encoding: gzip, deflate
20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >> Content-Type: application/x-www-form-urlencoded
20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >> Content-Length: 83
20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >> Host: localhost:8080
20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >> Connection: Keep-Alive
20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "grant_type=password&username=charles&password=java&client_id=security-admin-console"
20:41:18,318 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-15) RESTEASY002315: PathInfo: /realms/forum/protocol/openid-connect/token
20:41:18,320 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-15) AUTHENTICATE CLIENT
20:41:18,320 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-15) client authenticator: client-secret
20:41:18,320 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-15) client authenticator SUCCESS: client-secret
20:41:18,320 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-15) Client security-admin-console authenticated by client-secret
20:41:18,321 DEBUG [org.keycloak.authentication.AuthenticationProcessor] (default task-15) AUTHENTICATE ONLY
20:41:18,321 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) processFlow
20:41:18,321 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) check execution: direct-grant-validate-username requirement: REQUIRED
20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) authenticator: direct-grant-validate-username
20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) invoke authenticator.authenticate
20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) authenticator SUCCESS: direct-grant-validate-username
20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) check execution: direct-grant-validate-password requirement: REQUIRED
20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) authenticator: direct-grant-validate-password
20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) invoke authenticator.authenticate
20:41:18,323 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) authenticator SUCCESS: direct-grant-validate-password
20:41:18,323 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) check execution: direct-grant-validate-otp requirement: OPTIONAL
20:41:18,323 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) authenticator: direct-grant-validate-otp
20:41:18,323 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) invoke authenticator.authenticate
20:41:18,323 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow] (default task-15) authenticator ATTEMPTED: direct-grant-validate-otp
20:41:18,360 DEBUG [org.keycloak.events] (default task-15) type=LOGIN, realmId=forum, clientId=security-admin-console, userId=f785e600-124c-4e26-914e-2c4f6ec9c95b, ipAddress=127.0.0.1, auth_method=openid-connect, token_id=4dd8bbcb-e771-4652-8711-b2c0937bb8fe, grant_type=password, refresh_token_type=Refresh, refresh_token_id=c0e58e55-9edc-4940-9ff4-52a5a5a9f577, client_auth_method=client-secret, username=charles
20:41:18,363 DEBUG [org.apache.http.wire] (default task-14)  << "HTTP/1.1 200 OK[\r][\n]"
20:41:18,363 DEBUG [org.apache.http.wire] (default task-14)  << "Connection: keep-alive[\r][\n]"
20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  << "X-Powered-By: Undertow/1[\r][\n]"
20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  << "Server: WildFly/10[\r][\n]"
20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  << "Transfer-Encoding: chunked[\r][\n]"
20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  << "Content-Type: application/json[\r][\n]"
20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  << "Date: Wed, 10 Feb 2016 23:41:18 GMT[\r][\n]"
20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
20:41:18,364 DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (default task-14) Receiving response: HTTP/1.1 200 OK
20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) << HTTP/1.1 200 OK
20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) << Connection: keep-alive
20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) << X-Powered-By: Undertow/1
20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) << Server: WildFly/10
20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) << Transfer-Encoding: chunked
20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) << Content-Type: application/json
20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) << Date: Wed, 10 Feb 2016 23:41:18 GMT
20:41:18,364 DEBUG [org.apache.http.impl.client.DefaultHttpClient] (default task-14) Connection can be kept alive indefinitely
20:41:18,386 DEBUG [org.apache.http.wire] (default task-14)  << "0ed6[\r][\n]"
20:41:18,386 DEBUG [org.apache.http.wire] (default task-14)  << "{"access_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI0ZGQ4YmJjYi1lNzcxLTQ2NTItODcxMS1iMmMwOTM3YmI4ZmUiLCJleHAiOjE0NTUxNDc5NzgsIm5iZiI6MCwiaWF0IjoxNDU1MTQ3Njc4LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZm9ydW0iLCJhdWQiOiJzZWN1cml0eS1hZG1pbi1jb25zb2xlIiwic3ViIjoiZjc4NWU2MDAtMTI0Yy00ZTI2LTkxNGUtMmM0ZjZlYzljOTViIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoic2VjdXJpdHktYWRtaW4tY29uc29sZSIsInNlc3Npb25fc3RhdGUiOiIyYzkwMDMzOS1mNjNhLTQ4MGItYjJiZS0wZjZmNDlkNDc3MmYiLCJjbGllbnRfc2Vzc2lvbiI6IjE4YTlhNDQ1LTVkMWMtNGYyZi1iNmYxLTI0NDdkZGQzYzAxNSIsImFsbG93ZWQtb3JpZ2lucyI6W10sInJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctaWRlbnRpdHktcHJvdmlkZXJzIiwidmlldy1yZWFsbSIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhbG0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsIm1hbmFnZS1jbGllbnRzIl19fSwibmFtZSI6IkNoYXJsZXMgUXVlaXJveiIsInByZWZlcnJlZF91c2VybmFtZSI6ImNoYXJsZXMiLCJnaXZlbl9uYW1lIjoiQ2hhcmxlcyIsImxvY2FsZSI6InB0LUJSIiwiZmFtaWx5X25hbWUiOiJRdWVpcm96IiwiZW1haWwiOiJjaGFybGVzQGRhemVuLmNvbSJ9.bDRa_LxZeClP3k8GpcZPabZFcZA2oizTWdv-11xsUOutGx6zcP50EogkCfgFOyIsF0LCmTFOoqgBIS1XA8lFAImmCmxad6kOi7Jv1vxt-7YvxauxQdppDmKa10QTV-Za46QQEMyEjxT6o3AuCi-clxUUfLmKE7PVXmZeB07ejABoEKRZhEJVDHo3u-O1G_hjtwuH1DDkwLpgsEWBRYJ-_Dh-vKupgXxuckduelhbasLdiSXhJwdmVfY2Johfyk6WxVEViuigoLi8qe6y0KNbcyt3Vtf_t_9y7dvyGZZaM_9WLzwr29yR-91uM0rcr0V_B3W0MAwSXLFV5c1nEn03Pg","expires_in":300,"refresh_expires_in":1800,"refresh_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMGU1OGU1NS05ZWRjLTQ5NDAtOWZmNC01MmE1YTVhOWY1NzciLCJleHAiOjE0NTUxNDk0NzgsIm5iZiI6MCwiaWF0IjoxNDU1MTQ3Njc4LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZm9ydW0iLCJhdWQiOm51bGwsInN1YiI6ImY3ODVlNjAwLTEyNGMtNGUyNi05MTRlLTJjNGY2ZWM5Yzk1YiIsInR5cCI6IlJlZnJlc2giLCJhenAiOiJzZWN1cml0eS1hZG1pbi1jb25zb2xlIiwic2Vzc2lvbl9zdGF0ZSI6IjJjOTAwMzM5LWY2M2EtNDgwYi1iMmJlLTBmNmY0OWQ0NzcyZiIsImNsaWVudF9zZXNzaW9uIjoiMThhOWE0NDUtNWQxYy00ZjJmLWI2ZjEtMjQ0N2RkZDNjMDE1IiwicmVzb3VyY2VfYWNjZXNzIjp7InJlYWxtLW1hbmFnZW1lbnQiOnsicm9sZXMiOlsidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJ2aWV3LXJlYWxtIiwibWFuYWdlLWlkZW50aXR5LXByb3ZpZGVycyIsImltcGVyc29uYXRpb24iLCJyZWFsbS1hZG1pbiIsImNyZWF0ZS1jbGllbnQiLCJtYW5hZ2UtdXNlcnMiLCJtYW5hZ2UtZXZlbnRzIiwibWFuYWdlLXJlYWxtIiwidmlldy1ldmVudHMiLCJ2aWV3LXVzZXJzIiwidmlldy1jbGllbnRzIiwibWFuYWdlLWNsaWVudHMiXX19fQ.MPwbo7nnYspbbgAzWt2Z5ozWaMpP0ONI5WKAR-A8GkrrjYXTyJZk9mDLxHxUVaINboesSAhTd_RO4-g0k6yK8YOQLetztdl-YJxIUnVZQmCFdPwBOkty2Azmcib7mNI2eJWvUdFAIvpRhWt-2_P03DXAE0sAN4oS48HocQxKD2ZMHkB_rDWwKX313l_wFxUkW5T9tOv93jMHFx8k6dGV5GWVEH6-fuw4K5k-zUGRxKrBsQaCxJrpmjxXsx2gFqoYgU8PnRk2ReqblEIxC4fQfMk0SsW0Hm77_I0YaPMPW-yn4eULm31yYqnWOphZhtNmybMgi2Y8iJ_Q2yqCU2iJkw","token_type":"bearer","id_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5YWM5M2UxNy1jMGJiLTQyZDYtYWM2Mi1kYmVhNWU0NmJmMWQiLCJleHAiOjE0NTUxNDc5NzgsIm5iZiI6MCwiaWF0IjoxNDU1MTQ3Njc4LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZm9ydW0iLCJhdWQiOiJzZWN1cml0eS1hZG1pbi1jb25zb2xlIiwic3ViIjoiZjc4NWU2MDAtMTI0Yy00ZTI2LTkxNGUtMmM0ZjZlYzljOTViIiwidHlwIjoiSUQiLCJhenAiOiJzZWN1cml0eS1hZG1pbi1jb25zb2xlIiwic2Vzc2lvbl9zdGF0ZSI6IjJjOTAwMzM5LWY2M2EtNDgwYi1iMmJlLTBmNmY0OWQ0NzcyZiIsIm5hbWUiOiJDaGFybGVzIFF1ZWlyb3oiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJjaGFybGVzIiwiZ2l2ZW5fbmFtZSI6IkNoYXJsZXMiLCJsb2NhbGUiOiJwdC1CUiIsImZhbWlseV9uYW1lIjoiUXVlaXJveiIsImVtYWlsIjoiY2hhcmxlc0BkYXplbi5jb20ifQ.YxeYJ9cKFyDRQ1YyJbwflQSr-n8l9nW1ORsvQbWo1XYfd6UqiUJlSsygIg4JqFIJGfCU_X8DJcV5HmdOtt90IHqW0_Oc6P8ZvVA1UdGEcoWlVBi88Hd_dIGC3WgyaE4WdOW1KC6nh3Eba2KmdUPQQ3xRKYXd9-pxmE2DwDrHZtONd8EaqTeK4J8vE34Jr_BQyNdv9yGztUh73AGVXAeVk4MqKBRAVmcod_eYOpaaf2OfQwaHQZpskwVqrEIIffyXmIMwD1MbmIP4tMPdMnNBK7bzNO-Qx7VTgWOuTu-VRQQoH0-fXetJdxKb5O1_2G7qCi_CYLeolh2DbIWswM6bag","not-before-policy":0,"session-state":"2c900339-f63a-480b-b2be-0f6f49d4772f"}"
20:41:18,409 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
20:41:18,409 DEBUG [org.apache.http.wire] (default task-14)  << "0[\r][\n]"
20:41:18,409 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
20:41:18,409 DEBUG [org.apache.http.impl.conn.BasicClientConnectionManager] (default task-14) Releasing connection org.apache.http.impl.conn.ManagedClientConnectionImpl at 24993c5f
20:41:18,409 DEBUG [org.apache.http.impl.conn.BasicClientConnectionManager] (default task-14) Connection can be kept alive indefinitely
20:41:18,413 DEBUG [org.jboss.as.jpa] (default task-14) default task-14:transaction scoped EntityManager [forum.war#ForumPU]: closing entity managersession
20:41:18,414 DEBUG [org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl] (default task-14) Initiating JDBC connection release from afterTransaction
20:41:18,414 ERROR [org.jboss.as.ejb3.invocation] (default task-14) WFLYEJB0034: EJB Invocation failed on component UserRestEndpoint for method public javax.ws.rs.core.Response br.com.projetolead.forum.integration.rest.UserRestEndpoint.save(br.com.projetolead.forum.model.User,javax.servlet.http.HttpServletRequest) throws java.io.IOException: javax.ejb.EJBException: javax.ws.rs.client.ResponseProcessingException: javax.ws.rs.ProcessingException: com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "access_token" (class org.keycloak.representations.AccessTokenResponse), not marked as ignorable (9 known properties: "notBeforePolicy", "otherClaims", "tokenType", "token", "expiresIn", "sessionState", "refreshExpiresIn", "idToken", "refreshToken"])
 at [Source: org.apache.http.conn.EofSensorInputStream at 5af6ffba; line: 1, column: 18] (through reference chain: org.keycloak.representations.AccessTokenResponse["access_token?])

------


Where is the problem? 
Atenciosamente,

Charles Queiroz 

Dazen? IT Services
Technology - Software Development 
charles at dazen.com.br <mailto:charles at dazen.com.br>
Fortaleza - CE
Phone: +55 85 9933 1585 

Twitter: @CharlesQueiiroz


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/82b5ebf1/attachment-0001.html 

From bburke at redhat.com  Wed Feb 10 19:26:53 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Feb 2016 19:26:53 -0500
Subject: [keycloak-user] NullPointerException during deployment
In-Reply-To: <CAEBys6+VE-Ni16t_P+nZp-Fo_p4fvJwr0Sq5vc5VZZ--yxGmBw@mail.gmail.com>
References: <CAEBys6+VE-Ni16t_P+nZp-Fo_p4fvJwr0Sq5vc5VZZ--yxGmBw@mail.gmail.com>
Message-ID: <56BBD54D.8080004@redhat.com>

Its a scheduled bug.  Fixed in master.

On 2/10/2016 3:23 PM, Renann Prado wrote:
> I've been following keycloak guide, but I'm facing the below exception.
> I'm trying to secure a WAR that is inside of an EAR, I've tried to add 
> below two dependencies in my pom.xml.
> What am I missing?
>
> *Wildfly version: *10.0.0.Final
> *Keycloak version: *1.9.0.CR1
>
> *Dependencies (tried in EAR and in WAR, no luck):*
>
> <dependency>
>     <groupId>org.keycloak</groupId>
>     <artifactId>keycloak-core</artifactId>
>     <version>1.9.0.CR1</version>
>     <scope>provided</scope>
> </dependency>
> <dependency>
>     <groupId>org.keycloak</groupId>
> <artifactId>keycloak-adapter-core</artifactId>
>     <version>1.9.0.CR1</version>
>     <scope>provided</scope>
> </dependency>
> *
> *
> *Subsystem configuration:*
> *
> *
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>     <secure-deployment name="Test-web-1.0-SNAPSHOT.war">
>         <realm>TestRealm</realm>
> <resource>test-resource</resource>
> <realm-public-key>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmpxbZQMAf2NPcWCbdVWfu3JKEZ5PHuL+a5JTzyuln/wXpfhGPyCDS8rYDj2tf5lA8WQYoV8M5ip3DbCdL43wsW8/oJM/UOKn7mwy2x0OdW40bw1c8b1D6FveliIXwtovyw0EGCFn67qLdtHPLAlVvv5UXPIPFCakzdx1xS/6zgZ1uF2fzwLZpLh21M9XYNHQk6ui047+13Uf5H5yYQNLin8WluZ4JLfO8teVV9ARTqezVoZ5/+SNH4Mw+N1i7sGr13mzl51XvpFmm10Yx0dNiuy+WPA9xv1eNWcWgQWXxCEzDBenn59pmZ9JnTpoOqvZknmBGqyQPDqN9tJIWnWZKQIDAQAB</realm-public-key>
>         <auth-server-url>http://localhost:8082/auth</auth-server-url>
> <ssl-required>none</ssl-required>
>         <credential name="secret">password</credential>
>     </secure-deployment>
> </subsystem>
>
> *Exception*
>
>
> 8:13:18,779 ERROR [org.jboss.msc.service.fail] (MSC service thread 
> 1-3) MSC000001: Failed to start service 
> jboss.deployment.unit."Test-ear.ear".DEPENDENCIES: 
> org.jboss.msc.service.StartException in service 
> jboss.deployment.unit."Test-ear.ear".DEPENDENCIES: WFLYSRV0153: Failed 
> to process phase DEPENDENCIES of deployment "Test-ear.ear"
> at 
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 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)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at 
> org.keycloak.subsystem.adapter.extension.KeycloakDependencyProcessor.deploy(KeycloakDependencyProcessor.java:52)
> at 
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
>
> 18:13:18,784 ERROR [org.jboss.as.controller.management-operation] 
> (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") 
> failed - address: ([("deployment" => "Test-ear.ear")]) - failure 
> description: {"WFLYCTL0080: Failed services" => 
> {"jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES" => 
> "org.jboss.msc.service.StartException in service 
> jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES: WFLYSRV0153: 
> Failed to process phase DEPENDENCIES of deployment \"Test-ear.ear\"
>     Caused by: java.lang.NullPointerException"}}
> 18:13:18,786 ERROR [org.jboss.as.server] (management-handler-thread - 
> 2) WFLYSRV0021: Deploy of deployment "Test-ear.ear" was rolled back 
> with the following failure message:
> {"WFLYCTL0080: Failed services" => 
> {"jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES" => 
> "org.jboss.msc.service.StartException in service 
> jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES: WFLYSRV0153: 
> Failed to process phase DEPENDENCIES of deployment \"Test-ear.ear\"
>     Caused by: java.lang.NullPointerException"}}
>
> Renann Prado
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/4a352daa/attachment.html 

From prado.renann at gmail.com  Wed Feb 10 19:30:47 2016
From: prado.renann at gmail.com (Renann Prado)
Date: Wed, 10 Feb 2016 22:30:47 -0200
Subject: [keycloak-user] NullPointerException during deployment
In-Reply-To: <56BBD54D.8080004@redhat.com>
References: <CAEBys6+VE-Ni16t_P+nZp-Fo_p4fvJwr0Sq5vc5VZZ--yxGmBw@mail.gmail.com>
	<56BBD54D.8080004@redhat.com>
Message-ID: <CAEBys6LUVAS+mqcCnCCx+nV8E1C-wU3TNaeFx8bFphfM3psmaw@mail.gmail.com>

I changed to 1.8.1.Final and it worked!
Now my only problem is that, for some reason, I do not get redirected to
the login page when I access a protected resource.
I'm watching your tutorial right now to try to understand why it isn't
working.

Thanks
On Feb 10, 2016 22:27, "Bill Burke" <bburke at redhat.com> wrote:

> Its a scheduled bug.  Fixed in master.
>
> On 2/10/2016 3:23 PM, Renann Prado wrote:
>
> I've been following keycloak guide, but I'm facing the below exception.
> I'm trying to secure a WAR that is inside of an EAR, I've tried to add
> below two dependencies in my pom.xml.
> What am I missing?
>
> *Wildfly version: *10.0.0.Final
> *Keycloak version: *1.9.0.CR1
>
> *Dependencies (tried in EAR and in WAR, no luck):*
>
> <dependency>
>     <groupId>org.keycloak</groupId>
>     <artifactId>keycloak-core</artifactId>
>     <version>1.9.0.CR1</version>
>     <scope>provided</scope>
> </dependency>
> <dependency>
>     <groupId>org.keycloak</groupId>
>     <artifactId>keycloak-adapter-core</artifactId>
>     <version>1.9.0.CR1</version>
>     <scope>provided</scope>
> </dependency>
>
> *Subsystem configuration:*
>
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>     <secure-deployment name="Test-web-1.0-SNAPSHOT.war">
>         <realm>TestRealm</realm>
>         <resource>test-resource</resource>
>
> <realm-public-key>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmpxbZQMAf2NPcWCbdVWfu3JKEZ5PHuL+a5JTzyuln/wXpfhGPyCDS8rYDj2tf5lA8WQYoV8M5ip3DbCdL43wsW8/oJM/UOKn7mwy2x0OdW40bw1c8b1D6FveliIXwtovyw0EGCFn67qLdtHPLAlVvv5UXPIPFCakzdx1xS/6zgZ1uF2fzwLZpLh21M9XYNHQk6ui047+13Uf5H5yYQNLin8WluZ4JLfO8teVV9ARTqezVoZ5/+SNH4Mw+N1i7sGr13mzl51XvpFmm10Yx0dNiuy+WPA9xv1eNWcWgQWXxCEzDBenn59pmZ9JnTpoOqvZknmBGqyQPDqN9tJIWnWZKQIDAQAB</realm-public-key>
>         <auth-server-url>http://localhost:8082/auth</auth-server-url>
>         <ssl-required>none</ssl-required>
>         <credential name="secret">password</credential>
>     </secure-deployment>
> </subsystem>
>
> *Exception*
>
>
> 8:13:18,779 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3)
> MSC000001: Failed to start service
> jboss.deployment.unit."Test-ear.ear".DEPENDENCIES:
> org.jboss.msc.service.StartException in service
> jboss.deployment.unit."Test-ear.ear".DEPENDENCIES: WFLYSRV0153: Failed to
> process phase DEPENDENCIES of deployment "Test-ear.ear"
> at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 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)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at
> org.keycloak.subsystem.adapter.extension.KeycloakDependencyProcessor.deploy(KeycloakDependencyProcessor.java:52)
> at
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
>
> 18:13:18,784 ERROR [org.jboss.as.controller.management-operation]
> (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed -
> address: ([("deployment" => "Test-ear.ear")]) - failure description:
> {"WFLYCTL0080: Failed services" =>
> {"jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES" =>
> "org.jboss.msc.service.StartException in service
> jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES: WFLYSRV0153: Failed to
> process phase DEPENDENCIES of deployment \"Test-ear.ear\"
>     Caused by: java.lang.NullPointerException"}}
> 18:13:18,786 ERROR [org.jboss.as.server] (management-handler-thread - 2)
> WFLYSRV0021: Deploy of deployment "Test-ear.ear" was rolled back with the
> following failure message:
> {"WFLYCTL0080: Failed services" =>
> {"jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES" =>
> "org.jboss.msc.service.StartException in service
> jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES: WFLYSRV0153: Failed to
> process phase DEPENDENCIES of deployment \"Test-ear.ear\"
>     Caused by: java.lang.NullPointerException"}}
>
> Renann Prado
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160210/17986825/attachment-0001.html 

From bburke at redhat.com  Wed Feb 10 20:03:49 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Feb 2016 20:03:49 -0500
Subject: [keycloak-user] NullPointerException during deployment
In-Reply-To: <CAEBys6LUVAS+mqcCnCCx+nV8E1C-wU3TNaeFx8bFphfM3psmaw@mail.gmail.com>
References: <CAEBys6+VE-Ni16t_P+nZp-Fo_p4fvJwr0Sq5vc5VZZ--yxGmBw@mail.gmail.com>
	<56BBD54D.8080004@redhat.com>
	<CAEBys6LUVAS+mqcCnCCx+nV8E1C-wU3TNaeFx8bFphfM3psmaw@mail.gmail.com>
Message-ID: <56BBDDF5.2030008@redhat.com>

Yes, this is because the error was introduced in 1.9.RC1.

Tutorials are a bit ancient.  We'll be updating them soon....but if you 
download the demo distribution, there are tons of examples.

On 2/10/2016 7:30 PM, Renann Prado wrote:
>
> I changed to 1.8.1.Final and it worked!
> Now my only problem is that, for some reason, I do not get redirected 
> to the login page when I access a protected resource.
> I'm watching your tutorial right now to try to understand why it isn't 
> working.
>
> Thanks
>
> On Feb 10, 2016 22:27, "Bill Burke" <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Its a scheduled bug. Fixed in master.
>
>     On 2/10/2016 3:23 PM, Renann Prado wrote:
>>     I've been following keycloak guide, but I'm facing the below
>>     exception.
>>     I'm trying to secure a WAR that is inside of an EAR, I've tried
>>     to add below two dependencies in my pom.xml.
>>     What am I missing?
>>
>>     *Wildfly version: *10.0.0.Final
>>     *Keycloak version: *1.9.0.CR1
>>
>>     *Dependencies (tried in EAR and in WAR, no luck):*
>>
>>     <dependency>
>>         <groupId>org.keycloak</groupId>
>>     <artifactId>keycloak-core</artifactId>
>>         <version>1.9.0.CR1</version>
>>         <scope>provided</scope>
>>     </dependency>
>>     <dependency>
>>         <groupId>org.keycloak</groupId>
>>     <artifactId>keycloak-adapter-core</artifactId>
>>         <version>1.9.0.CR1</version>
>>         <scope>provided</scope>
>>     </dependency>
>>     *
>>     *
>>     *Subsystem configuration:*
>>     *
>>     *
>>     <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>         <secure-deployment name="Test-web-1.0-SNAPSHOT.war">
>>             <realm>TestRealm</realm>
>>     <resource>test-resource</resource>
>>     <realm-public-key>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmpxbZQMAf2NPcWCbdVWfu3JKEZ5PHuL+a5JTzyuln/wXpfhGPyCDS8rYDj2tf5lA8WQYoV8M5ip3DbCdL43wsW8/oJM/UOKn7mwy2x0OdW40bw1c8b1D6FveliIXwtovyw0EGCFn67qLdtHPLAlVvv5UXPIPFCakzdx1xS/6zgZ1uF2fzwLZpLh21M9XYNHQk6ui047+13Uf5H5yYQNLin8WluZ4JLfO8teVV9ARTqezVoZ5/+SNH4Mw+N1i7sGr13mzl51XvpFmm10Yx0dNiuy+WPA9xv1eNWcWgQWXxCEzDBenn59pmZ9JnTpoOqvZknmBGqyQPDqN9tJIWnWZKQIDAQAB</realm-public-key>
>>             <auth-server-url>http://localhost:8082/auth</auth-server-url>
>>     <ssl-required>none</ssl-required>
>>             <credential name="secret">password</credential>
>>         </secure-deployment>
>>     </subsystem>
>>
>>     *Exception*
>>
>>
>>     8:13:18,779 ERROR [org.jboss.msc.service.fail] (MSC service
>>     thread 1-3) MSC000001: Failed to start service
>>     jboss.deployment.unit."Test-ear.ear".DEPENDENCIES:
>>     org.jboss.msc.service.StartException in service
>>     jboss.deployment.unit."Test-ear.ear".DEPENDENCIES: WFLYSRV0153:
>>     Failed to process phase DEPENDENCIES of deployment "Test-ear.ear"
>>     at
>>     org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
>>     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)
>>     at
>>     java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>     at java.lang.Thread.run(Thread.java:745)
>>     Caused by: java.lang.NullPointerException
>>     at
>>     org.keycloak.subsystem.adapter.extension.KeycloakDependencyProcessor.deploy(KeycloakDependencyProcessor.java:52)
>>     at
>>     org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
>>     ... 5 more
>>
>>     18:13:18,784 ERROR [org.jboss.as.controller.management-operation]
>>     (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy")
>>     failed - address: ([("deployment" => "Test-ear.ear")]) - failure
>>     description: {"WFLYCTL0080: Failed services" =>
>>     {"jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES" =>
>>     "org.jboss.msc.service.StartException in service
>>     jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES: WFLYSRV0153:
>>     Failed to process phase DEPENDENCIES of deployment \"Test-ear.ear\"
>>         Caused by: java.lang.NullPointerException"}}
>>     18:13:18,786 ERROR [org.jboss.as.server]
>>     (management-handler-thread - 2) WFLYSRV0021: Deploy of deployment
>>     "Test-ear.ear" was rolled back with the following failure message:
>>     {"WFLYCTL0080: Failed services" =>
>>     {"jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES" =>
>>     "org.jboss.msc.service.StartException in service
>>     jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES: WFLYSRV0153:
>>     Failed to process phase DEPENDENCIES of deployment \"Test-ear.ear\"
>>         Caused by: java.lang.NullPointerException"}}
>>
>>     Renann Prado
>>
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160210/25e15cf5/attachment.html 

From chenkeong.yap at izeno.com  Wed Feb 10 20:15:21 2016
From: chenkeong.yap at izeno.com (chenkeong.yap at izeno.com)
Date: Thu, 11 Feb 2016 09:15:21 +0800
Subject: [keycloak-user] ldap federation provider
Message-ID: <5EB73BCF-AC62-460F-8F45-9A784EE5311B@izeno.com>

hi guys,

please assist to clarify. after adding ldap federation provider, is the password stored in keycloak database? if yes, is there anyway to prevent sync of password?

Regards,
CK Yap

From jean.merelis at gmail.com  Wed Feb 10 22:27:40 2016
From: jean.merelis at gmail.com (Jeandeson O. Merelis)
Date: Thu, 11 Feb 2016 01:27:40 -0200
Subject: [keycloak-user] angularjs ng2 sample
In-Reply-To: <CAJgngAefaZXHwG3peZZx0v_7Jg+aWYX4oO1BqhKf1JWRQvEjdA@mail.gmail.com>
References: <61D077C6283D454FAFD06F6AC4AB74D723D7B263@DEFTHW99EZ1MSX.ww931.my-it-solutions.net>
	<CAJgngAefaZXHwG3peZZx0v_7Jg+aWYX4oO1BqhKf1JWRQvEjdA@mail.gmail.com>
Message-ID: <CAAjz7KLBgfF4u7vXxmV87qPqW4bMQhJOdMhXSAMcz9Q7e79b5Q@mail.gmail.com>

I sent a pull request with angular2 example. It works the same way of
example angular-product-app, except for http interceptors, this should be
improved in the future.

2016-02-10 8:03 GMT-02:00 Stian Thorgersen <sthorger at redhat.com>:

> The main issue with Angular is that Keycloak and the Route provider
> conflicts with each other, which causes a endless redirect loop. Current
> work around we have is to make sure Keycloak is fully initialized before
> Angular is bootstrap. The proper solution would be to have a Angular
> library for Keycloak that can handle this.
>
> We have not had time to look at that, nor have we looked at Angular2 at
> all. So it would be a while until we would get to this, unless someone from
> the community wants to contribute it.
>
> On 10 February 2016 at 10:56, Matuszak, Eduard <eduard.matuszak at atos.net>
> wrote:
>
>> Hello
>>
>> We are adviced to implement the GUI of a new project with angularjs ng2.
>> There is an inspiring sample (
>> https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app)
>> for using keycloak.js-library in colaboration with the older angular
>> version. Do you intend to publish a comparable example based on ng2 in the
>> near future? This would be very helpful.
>>
>> Thanks in advance for your feedback, Eduard Matuszak
>>
>> *Dr. Eduard Matuszak*
>>
>> Worldline, an atos company
>> T  +49 (211)399 398 63
>> M +49 (163)166 23 67
>> F +49(211) 399 22 430
>> *eduard.matuszak at atos.net* <eduard.matuszak at atos.net>
>> Max-Stromeyer-Stra?e 116
>> 78467 Konstanz
>> Germany
>> *de.worldline.com* <http://worldline.com/de/1/Home.html>
>> *worldline.jobs.de* <http://worldline.jobs.de>
>> *facebook.com/WorldlineKarriere*
>> <http://www.facebook.com/WorldlineKarriere>
>>
>>
>> Worldline GmbH
>> Gesch?ftsf?hrer: Wolf Kunisch
>> Aufsichtsratsvorsitzender: Christophe Duquenne
>> Sitz der Gesellschaft: Frankfurt/Main
>> Handelsregister: Frankfurt/Main HRB 40 417
>>
>> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
>> This e-mail and the documents attached are confidential and intended
>> solely for the addressee; it may also be privileged. If you receive this
>> e-mail by error, please notify the sender immediately and destroy it. As
>> its integrity cannot be secured on the internet, the Atos group liability
>> cannot be triggered for the message content. Although the sender endeavors
>> to maintain a computer virus-free network, the sender does not warrant that
>> this transmission is virus-free and shall not be liable for any damages
>> resulting from any virus transmitted.
>> * * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>



-- 
Jeandeson O. Merelis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/e95d4963/attachment-0001.html 

From michael.anthon at infoview.com.au  Wed Feb 10 23:42:00 2016
From: michael.anthon at infoview.com.au (Michael Anthon)
Date: Thu, 11 Feb 2016 04:42:00 +0000
Subject: [keycloak-user] Issues with password reset link expiration
In-Reply-To: <CAJgngAd3NNYUXRaWYnf7rpKFxMzCLvVHGVXrmvjMUUxzFz2RzQ@mail.gmail.com>
References: <e3c4dce4db8649958379bf11260f79d1@HsteqMX04.nexonhosted.local>
	<CAJgngAdk_iN2vcR0i5t-3wriOe3xgQWAxPGWf1_D3sR62_s8JQ@mail.gmail.com>
	<56BB40F0.1080204@redhat.com>
	<CAJgngAfiUdD6TJviSRf3j8erStY3atLzk3ygFEXCgwst+wnu-Q@mail.gmail.com>
	<56BB4614.8090509@redhat.com>
	<CAJgngAd3NNYUXRaWYnf7rpKFxMzCLvVHGVXrmvjMUUxzFz2RzQ@mail.gmail.com>
Message-ID: <e2031b62eb4f4212b440b371f09b430d@HsteqMX04.nexonhosted.local>

Thanks for the replies, I forgot to mention we are currently on 1.6.1.Final however we do have a test setup where we can run an upgrade and check this out.

Will try that and report back and/or create a ticket as required.

Cheers,
Michael

From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: Thursday, 11 February 2016 12:26 AM
To: Bill Burke <bburke at redhat.com>; Michael Anthon <michael.anthon at infoview.com.au>
Cc: keycloak-user <keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Issues with password reset link expiration

Michael,

Can you confirm if this issue still exists on 1.9.0.CR1 and if it does create a JIRA issue?

On 10 February 2016 at 15:15, Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>> wrote:
I think this may have been fixed in 1.9 with the flow changes I made.  I don't have time to try it out right now though.

On 2/10/2016 8:58 AM, Stian Thorgersen wrote:
It's not about the error message though. It should be possible to open the link multiple times as long as the form is not submitted.

On 10 February 2016 at 14:53, Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>> wrote:
We changed the "error" message in I think 1.9?  Maybe 1.8 to say "You clicked on a stale link.  Maybe you have already verified your email?"  I'll look into improving this I guess.

On 2/10/2016 4:21 AM, Stian Thorgersen wrote:
It should be possible to open the link multiple times, but only submit the password reset once. If that's not the case (sounds like it is) feel free to create a JIRA issue to report this as a bug.

On 10 February 2016 at 05:24, Michael Anthon <michael.anthon at infoview.com.au<mailto:michael.anthon at infoview.com.au>> wrote:
We are having issues with some users when they are attempting to use the password reset feature.  It does work for most users however for some they always end up at an error page saying "WE'RE SORRY ... An error occurred, please login again through your application"

What I have been able to determine so far is that for the affected users we are seeing a double hit on that URL in the server logs and from what I understand, these reset URLs are invalidated as soon as they are accessed.

So here's the state of play
* works for most users
* some users hitting the reset URL twice
* URL is only valid for the first access (I'm not 100% sure about this, can someone confirm please?)
* URL is only valid for 30 minutes (but is being accessed within a few minutes of generation)
* affected users are mostly using Outlook
* some people tend to double click links in emails but I've verified with a reliable user that they are only clicking the link once
* having the affected person send themselves another reset email and then copy and paste the URL from the mail client usually resolves this problem

And questions
* is this an issue anyone else has noticed with Outlook, doesn't affect ALL Outlook users, just some
* is there a way to prevent the URL from being invalidated on initial access
* is it feasible to change the behavior so that the URL is only invalidated when the password is changed
* any other thoughts on how to avoid this issue?

Thanks and Regards,

Michael Anthon
InfoView Technologies Pty Ltd
12/15 Adelaide St, Brisbane Qld 4000
P O Box 15478, City East, Brisbane Qld 4000
PH:          +61 7 3014 2204<tel:%2B61%207%203014%202204>
F:             +61 7 3014 2200<tel:%2B61%207%203014%202200>
M:           +61 408 768 055<tel:%2B61%20408%20768%20055>
michael.anthon at infoview.com.au<mailto:michael.anthon at infoview.com.au>

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of InfoView Technologies Pty Ltd.


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



_______________________________________________

keycloak-user mailing list

keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>

https://lists.jboss.org/mailman/listinfo/keycloak-user


--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com

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




--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/82fb9cfb/attachment.html 

From darkness.renann at gmail.com  Thu Feb 11 01:33:10 2016
From: darkness.renann at gmail.com (Renann Prado)
Date: Thu, 11 Feb 2016 04:33:10 -0200
Subject: [keycloak-user] What's the point of creating roles per realm and
	client?
Message-ID: <CAEBys6K-BacvNLaFCvPviagCSpRjoTwURuWMzHJr3B4b0PhGSA@mail.gmail.com>

I'm pretty new to keycloak. Amazing application btw.
It's working very well, however I found strange/confusing that I have to
create roles in the level of the realm, then per client and then assign to
each user.
What I mean is: why don't we have the roles created in the level of the
realm and then we just assign per application user or is there an option to
make that happen?
Otherwise I have to keep creating roles for all clients, then assigning for
all users. In my case there aren't many users/roles/applications, so it's
fine. But it would be nice to know how to do that.

Thanks

Renann Prado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/946ef4cb/attachment-0001.html 

From darkness.renann at gmail.com  Thu Feb 11 02:38:18 2016
From: darkness.renann at gmail.com (Renann Prado)
Date: Thu, 11 Feb 2016 05:38:18 -0200
Subject: [keycloak-user] How do I set session variable upon first API hit?
Message-ID: <CAEBys6KzAL5eGOJUaBgRB6swk7_khd5F4rSEfttgp70fYyYomw@mail.gmail.com>

Basically I have some session variables that should be set upon first hit
in the API (using bearer token). The requirement is that session variables
will be dynamically loaded from the database and put into the http session
before I actually process the request, so I can use the variables to
process it.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/8cd10ac2/attachment.html 

From sthorger at redhat.com  Thu Feb 11 03:18:22 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 11 Feb 2016 09:18:22 +0100
Subject: [keycloak-user] Create user + keycloak-admin-client
In-Reply-To: <DB042FAE-0A0D-4938-8460-C60E3F537E09@dazen.com.br>
References: <DB042FAE-0A0D-4938-8460-C60E3F537E09@dazen.com.br>
Message-ID: <CAJgngAdv3hvFY=edkvpAppThNy6tY-c5VVh2KnE+FSkrhJJnRA@mail.gmail.com>

The realm you pass into Keycloak.getInstance is the realm you are
authenticating the user with. Is your admin user in the master realm? If so
use "master" there instead of "forum".

The other issue you are seeing is related to the version of Jackson you are
using. In 1.9.0.CR1 we upgraded to Jackson2 (fasterxml), in 1.8.0 we
required Jackson1. Take a look at the admin-client example it shows how to
exclude Jackson2 and include Jackson1 instead. Or you can upgrade to
1.9.0.CR1.


On 11 February 2016 at 00:49, Charles Queiroz <charles at dazen.com.br> wrote:

> Hi folks,
>
> I?m trying programmatically add user in keycloak server using the admin
> client (version 1.8.0.RC3) like this post show (link:
> http://www.first8.nl/blog/programmatically-adding-users-in-keycloak/ ),
> but no success yet! ;(
>
>
>
> The Steps:
>
> 1 - Add dependence on pom.xml like:
>
> <dependency>
>     <groupId>org.keycloak</groupId>
>     <artifactId>keycloak-admin-client</artifactId>
>     <version>1.8.0.CR3</version>
> </dependency>
>
>
> 2 - Implement the method body like:
>
>
> public User save(User user) {
>     Keycloak kc = Keycloak.getInstance("http://localhost:8080/auth", "forum", ?admin", ?admin", "security-admin-console");
>
>     CredentialRepresentation credential = new CredentialRepresentation();
>     credential.setType(CredentialRepresentation.PASSWORD);
>     credential.setValue(user.getPassword());
>     UserRepresentation newUser = new UserRepresentation();
>     newUser.setUsername(user.getLogin());
>     newUser.setFirstName(user.getName());
>     newUser.setCredentials(Arrays.asList(credential));
>
>     kc.realm("forum").users().create(newUser);
>
>     User saved = repository.save(user);
>     savedUser.fire(saved);
>     return saved;
> }
>
>
> When I run the app, the exception thrown is:
>
> 20:46:03,583 DEBUG [org.apache.http.impl.conn.DefaultClientConnection]
> (default task-14) Sending request: POST
> /auth/realms/forum/protocol/openid-connect/token HTTP/1.1
> 20:46:03,584 DEBUG [org.apache.http.wire] (default task-14)  >> "POST
> /auth/realms/forum/protocol/openid-connect/token HTTP/1.1[\r][\n]"
> 20:46:03,585 DEBUG [org.apache.http.wire] (default task-14)  >> "Accept:
> application/json[\r][\n]"
> 20:46:03,587 DEBUG [org.apache.http.wire] (default task-14)  >>
> "Accept-Encoding: gzip, deflate[\r][\n]"
> 20:46:03,589 DEBUG [org.apache.http.wire] (default task-14)  >>
> "Content-Type: application/x-www-form-urlencoded[\r][\n]"
> 20:46:03,591 DEBUG [org.apache.http.wire] (default task-14)  >>
> "Content-Length: 82[\r][\n]"
> 20:46:03,592 DEBUG [org.apache.http.wire] (default task-14)  >> "Host:
> localhost:8080[\r][\n]"
> 20:46:03,594 DEBUG [org.apache.http.wire] (default task-14)  >>
> "Connection: Keep-Alive[\r][\n]"
> 20:46:03,596 DEBUG [org.apache.http.wire] (default task-14)  >> "[\r][\n]"
> 20:46:03,598 DEBUG [org.apache.http.headers] (default task-14) >> POST
> /auth/realms/forum/protocol/openid-connect/token HTTP/1.1
> 20:46:03,599 DEBUG [org.apache.http.headers] (default task-14) >> Accept:
> application/json
> 20:46:03,601 DEBUG [org.apache.http.headers] (default task-14) >>
> Accept-Encoding: gzip, deflate
> 20:46:03,602 DEBUG [org.apache.http.headers] (default task-14) >>
> Content-Type: application/x-www-form-urlencoded
> 20:46:03,604 DEBUG [org.apache.http.headers] (default task-14) >>
> Content-Length: 82
> 20:46:03,605 DEBUG [org.apache.http.headers] (default task-14) >> Host:
> localhost:8080
> 20:46:03,606 DEBUG [org.apache.http.headers] (default task-14) >>
> Connection: Keep-Alive
> 20:46:03,610 DEBUG [org.apache.http.wire] (default task-14)  >>
> "grant_type=password&username=admin&password=admin&client_id=security-admin-console"
> 20:46:03,612 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
> task-15) RESTEASY002315: PathInfo:
> /realms/forum/protocol/openid-connect/token
> 20:46:03,614 DEBUG [org.keycloak.authentication.AuthenticationProcessor]
> (default task-15) AUTHENTICATE CLIENT
> 20:46:03,614 DEBUG [org.keycloak.authentication.AuthenticationProcessor]
> (default task-15) client authenticator: client-secret
> 20:46:03,614 DEBUG [org.keycloak.authentication.AuthenticationProcessor]
> (default task-15) client authenticator SUCCESS: client-secret
> 20:46:03,614 DEBUG [org.keycloak.authentication.AuthenticationProcessor]
> (default task-15) Client security-admin-console authenticated by
> client-secret
> 20:46:03,615 DEBUG [org.keycloak.authentication.AuthenticationProcessor]
> (default task-15) AUTHENTICATE ONLY
> 20:46:03,615 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) processFlow
> 20:46:03,615 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) check execution: direct-grant-validate-username
> requirement: REQUIRED
> 20:46:03,616 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) authenticator: direct-grant-validate-username
> 20:46:03,616 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) invoke authenticator.authenticate
> 20:46:03,617 FINE  [org.mongodb.driver.protocol.query] (default task-15)
> Sending query of namespace forum.users on connection
> [connectionId{localValue:2, serverValue:184}] to server 127.0.0.1:27017
> 20:46:03,617 FINE  [org.mongodb.driver.protocol.query] (default task-15)
> Query completed
> 20:46:03,618 WARN  [org.keycloak.events] (default task-15)
> type=LOGIN_ERROR, realmId=forum, clientId=security-admin-console,
> userId=null, ipAddress=127.0.0.1, error=invalid_user_credentials,
> auth_method=openid-connect, grant_type=password,
> client_auth_method=client-secret, username=admin
> 20:46:03,619 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) authenticator FAILED: direct-grant-validate-username
> 20:46:03,624 DEBUG [org.apache.http.wire] (default task-14)  << "HTTP/1.1
> 401 Unauthorized[\r][\n]"
> 20:46:03,627 DEBUG [org.apache.http.wire] (default task-14)  <<
> "Connection: keep-alive[\r][\n]"
> 20:46:03,629 DEBUG [org.apache.http.wire] (default task-14)  <<
> "X-Powered-By: Undertow/1[\r][\n]"
> 20:46:03,631 DEBUG [org.apache.http.wire] (default task-14)  << "Server:
> WildFly/10[\r][\n]"
> 20:46:03,632 DEBUG [org.apache.http.wire] (default task-14)  <<
> "Transfer-Encoding: chunked[\r][\n]"
> 20:46:03,634 DEBUG [org.apache.http.wire] (default task-14)  <<
> "Content-Type: application/json[\r][\n]"
> 20:46:03,636 DEBUG [org.apache.http.wire] (default task-14)  << "Date:
> Wed, 10 Feb 2016 23:46:03 GMT[\r][\n]"
> 20:46:03,637 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
> 20:46:03,639 DEBUG [org.apache.http.impl.conn.DefaultClientConnection]
> (default task-14) Receiving response: HTTP/1.1 401 Unauthorized
> 20:46:03,640 DEBUG [org.apache.http.headers] (default task-14) << HTTP/1.1
> 401 Unauthorized
> 20:46:03,642 DEBUG [org.apache.http.headers] (default task-14) <<
> Connection: keep-alive
> 20:46:03,643 DEBUG [org.apache.http.headers] (default task-14) <<
> X-Powered-By: Undertow/1
> 20:46:03,645 DEBUG [org.apache.http.headers] (default task-14) << Server:
> WildFly/10
> 20:46:03,646 DEBUG [org.apache.http.headers] (default task-14) <<
> Transfer-Encoding: chunked
> 20:46:03,647 DEBUG [org.apache.http.headers] (default task-14) <<
> Content-Type: application/json
> 20:46:03,649 DEBUG [org.apache.http.headers] (default task-14) << Date:
> Wed, 10 Feb 2016 23:46:03 GMT
> 20:46:03,651 DEBUG [org.apache.http.impl.client.DefaultHttpClient]
> (default task-14) Connection can be kept alive indefinitely
> 20:46:03,653 DEBUG [org.apache.http.impl.client.DefaultHttpClient]
> (default task-14) Authentication required
> 20:46:03,654 DEBUG [org.apache.http.impl.client.DefaultHttpClient]
> (default task-14) localhost:8080 requested authentication
> 20:46:03,656 DEBUG [org.apache.http.impl.client.DefaultHttpClient]
> (default task-14) Response contains no authentication challenges
> 20:46:03,665 DEBUG [org.apache.http.wire] (default task-14)  <<
> "48[\r][\n]"
> 20:46:03,667 DEBUG [org.apache.http.wire] (default task-14)  <<
> "{"error_description":"Invalid user credentials","error":"invalid_grant"}"
> 20:46:03,668 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
> 20:46:03,670 DEBUG [org.apache.http.wire] (default task-14)  << "0[\r][\n]"
> 20:46:03,671 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
> 20:46:03,673 DEBUG
> [org.apache.http.impl.conn.BasicClientConnectionManager] (default task-14)
> Releasing connection
> org.apache.http.impl.conn.ManagedClientConnectionImpl at 1d6c4f71
> 20:46:03,675 DEBUG
> [org.apache.http.impl.conn.BasicClientConnectionManager] (default task-14)
> Connection can be kept alive indefinitely
> 20:46:11,315 DEBUG [org.jboss.as.jpa] (default task-14) default
> task-14:transaction scoped EntityManager [forum.war#ForumPU]: closing
> entity managersession
> 20:46:11,315 DEBUG
> [org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl]
> (default task-14) Initiating JDBC connection release from afterTransaction
> 20:46:11,316 ERROR [org.jboss.as.ejb3.invocation] (default task-14)
> WFLYEJB0034: EJB Invocation failed on component UserRestEndpoint for method
> public javax.ws.rs.core.Response
> br.com.projetolead.forum.integration.rest.UserRestEndpoint.save(br.com.projetolead.forum.model.User,javax.servlet.http.HttpServletRequest)
> throws java.io.IOException: javax.ejb.EJBException:
> javax.ws.rs.NotAuthorizedException: HTTP 401 Unauthorized
> at
> org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
>
>
> ------
>
> but, when I change the user to charles (no admin user. login: charles,
> password: java) the error is:
>
> ------
>
> 20:41:18,314 DEBUG [org.apache.http.impl.conn.DefaultClientConnection]
> (default task-14) Sending request: POST
> /auth/realms/forum/protocol/openid-connect/token HTTP/1.1
> 20:41:18,315 DEBUG [org.apache.http.wire] (default task-14)  >> "POST
> /auth/realms/forum/protocol/openid-connect/token HTTP/1.1[\r][\n]"
> 20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "Accept:
> application/json[\r][\n]"
> 20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >>
> "Accept-Encoding: gzip, deflate[\r][\n]"
> 20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >>
> "Content-Type: application/x-www-form-urlencoded[\r][\n]"
> 20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >>
> "Content-Length: 83[\r][\n]"
> 20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "Host:
> localhost:8080[\r][\n]"
> 20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >>
> "Connection: Keep-Alive[\r][\n]"
> 20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >> "[\r][\n]"
> 20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >> POST
> /auth/realms/forum/protocol/openid-connect/token HTTP/1.1
> 20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >> Accept:
> application/json
> 20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >>
> Accept-Encoding: gzip, deflate
> 20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >>
> Content-Type: application/x-www-form-urlencoded
> 20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >>
> Content-Length: 83
> 20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >> Host:
> localhost:8080
> 20:41:18,316 DEBUG [org.apache.http.headers] (default task-14) >>
> Connection: Keep-Alive
> 20:41:18,316 DEBUG [org.apache.http.wire] (default task-14)  >>
> "grant_type=password&username=charles&password=java&client_id=security-admin-console"
> 20:41:18,318 DEBUG [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
> task-15) RESTEASY002315: PathInfo:
> /realms/forum/protocol/openid-connect/token
> 20:41:18,320 DEBUG [org.keycloak.authentication.AuthenticationProcessor]
> (default task-15) AUTHENTICATE CLIENT
> 20:41:18,320 DEBUG [org.keycloak.authentication.AuthenticationProcessor]
> (default task-15) client authenticator: client-secret
> 20:41:18,320 DEBUG [org.keycloak.authentication.AuthenticationProcessor]
> (default task-15) client authenticator SUCCESS: client-secret
> 20:41:18,320 DEBUG [org.keycloak.authentication.AuthenticationProcessor]
> (default task-15) Client security-admin-console authenticated by
> client-secret
> 20:41:18,321 DEBUG [org.keycloak.authentication.AuthenticationProcessor]
> (default task-15) AUTHENTICATE ONLY
> 20:41:18,321 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) processFlow
> 20:41:18,321 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) check execution: direct-grant-validate-username
> requirement: REQUIRED
> 20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) authenticator: direct-grant-validate-username
> 20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) invoke authenticator.authenticate
> 20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) authenticator SUCCESS: direct-grant-validate-username
> 20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) check execution: direct-grant-validate-password
> requirement: REQUIRED
> 20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) authenticator: direct-grant-validate-password
> 20:41:18,322 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) invoke authenticator.authenticate
> 20:41:18,323 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) authenticator SUCCESS: direct-grant-validate-password
> 20:41:18,323 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) check execution: direct-grant-validate-otp requirement:
> OPTIONAL
> 20:41:18,323 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) authenticator: direct-grant-validate-otp
> 20:41:18,323 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) invoke authenticator.authenticate
> 20:41:18,323 DEBUG [org.keycloak.authentication.DefaultAuthenticationFlow]
> (default task-15) authenticator ATTEMPTED: direct-grant-validate-otp
> 20:41:18,360 DEBUG [org.keycloak.events] (default task-15) type=LOGIN,
> realmId=forum, clientId=security-admin-console,
> userId=f785e600-124c-4e26-914e-2c4f6ec9c95b, ipAddress=127.0.0.1,
> auth_method=openid-connect, token_id=4dd8bbcb-e771-4652-8711-b2c0937bb8fe,
> grant_type=password, refresh_token_type=Refresh,
> refresh_token_id=c0e58e55-9edc-4940-9ff4-52a5a5a9f577,
> client_auth_method=client-secret, username=charles
> 20:41:18,363 DEBUG [org.apache.http.wire] (default task-14)  << "HTTP/1.1
> 200 OK[\r][\n]"
> 20:41:18,363 DEBUG [org.apache.http.wire] (default task-14)  <<
> "Connection: keep-alive[\r][\n]"
> 20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  <<
> "X-Powered-By: Undertow/1[\r][\n]"
> 20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  << "Server:
> WildFly/10[\r][\n]"
> 20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  <<
> "Transfer-Encoding: chunked[\r][\n]"
> 20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  <<
> "Content-Type: application/json[\r][\n]"
> 20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  << "Date:
> Wed, 10 Feb 2016 23:41:18 GMT[\r][\n]"
> 20:41:18,364 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
> 20:41:18,364 DEBUG [org.apache.http.impl.conn.DefaultClientConnection]
> (default task-14) Receiving response: HTTP/1.1 200 OK
> 20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) << HTTP/1.1
> 200 OK
> 20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) <<
> Connection: keep-alive
> 20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) <<
> X-Powered-By: Undertow/1
> 20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) << Server:
> WildFly/10
> 20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) <<
> Transfer-Encoding: chunked
> 20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) <<
> Content-Type: application/json
> 20:41:18,364 DEBUG [org.apache.http.headers] (default task-14) << Date:
> Wed, 10 Feb 2016 23:41:18 GMT
> 20:41:18,364 DEBUG [org.apache.http.impl.client.DefaultHttpClient]
> (default task-14) Connection can be kept alive indefinitely
> 20:41:18,386 DEBUG [org.apache.http.wire] (default task-14)  <<
> "0ed6[\r][\n]"
> 20:41:18,386 DEBUG [org.apache.http.wire] (default task-14)  <<
> "{"access_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI0ZGQ4YmJjYi1lNzcxLTQ2NTItODcxMS1iMmMwOTM3YmI4ZmUiLCJleHAiOjE0NTUxNDc5NzgsIm5iZiI6MCwiaWF0IjoxNDU1MTQ3Njc4LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZm9ydW0iLCJhdWQiOiJzZWN1cml0eS1hZG1pbi1jb25zb2xlIiwic3ViIjoiZjc4NWU2MDAtMTI0Yy00ZTI2LTkxNGUtMmM0ZjZlYzljOTViIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoic2VjdXJpdHktYWRtaW4tY29uc29sZSIsInNlc3Npb25fc3RhdGUiOiIyYzkwMDMzOS1mNjNhLTQ4MGItYjJiZS0wZjZmNDlkNDc3MmYiLCJjbGllbnRfc2Vzc2lvbiI6IjE4YTlhNDQ1LTVkMWMtNGYyZi1iNmYxLTI0NDdkZGQzYzAxNSIsImFsbG93ZWQtb3JpZ2lucyI6W10sInJlc291cmNlX2FjY2VzcyI6eyJyZWFsbS1tYW5hZ2VtZW50Ijp7InJvbGVzIjpbInZpZXctaWRlbnRpdHktcHJvdmlkZXJzIiwidmlldy1yZWFsbSIsIm1hbmFnZS1pZGVudGl0eS1wcm92aWRlcnMiLCJpbXBlcnNvbmF0aW9uIiwicmVhbG0tYWRtaW4iLCJjcmVhdGUtY2xpZW50IiwibWFuYWdlLXVzZXJzIiwibWFuYWdlLWV2ZW50cyIsIm1hbmFnZS1yZWFsbSIsInZpZXctZXZlbnRzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsIm1hbmFnZS1jbGllbnRzIl19fSwibmFtZSI6IkNoYXJsZXMgUXVlaXJveiIsInByZWZlcnJlZF91c2VybmFtZSI6ImNoYXJsZXMiLCJnaXZlbl9uYW1lIjoiQ2hhcmxlcyIsImxvY2FsZSI6InB0LUJSIiwiZmFtaWx5X25hbWUiOiJRdWVpcm96IiwiZW1haWwiOiJjaGFybGVzQGRhemVuLmNvbSJ9.bDRa_LxZeClP3k8GpcZPabZFcZA2oizTWdv-11xsUOutGx6zcP50EogkCfgFOyIsF0LCmTFOoqgBIS1XA8lFAImmCmxad6kOi7Jv1vxt-7YvxauxQdppDmKa10QTV-Za46QQEMyEjxT6o3AuCi-clxUUfLmKE7PVXmZeB07ejABoEKRZhEJVDHo3u-O1G_hjtwuH1DDkwLpgsEWBRYJ-_Dh-vKupgXxuckduelhbasLdiSXhJwdmVfY2Johfyk6WxVEViuigoLi8qe6y0KNbcyt3Vtf_t_9y7dvyGZZaM_9WLzwr29yR-91uM0rcr0V_B3W0MAwSXLFV5c1nEn03Pg","expires_in":300,"refresh_expires_in":1800,"refresh_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMGU1OGU1NS05ZWRjLTQ5NDAtOWZmNC01MmE1YTVhOWY1NzciLCJleHAiOjE0NTUxNDk0NzgsIm5iZiI6MCwiaWF0IjoxNDU1MTQ3Njc4LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZm9ydW0iLCJhdWQiOm51bGwsInN1YiI6ImY3ODVlNjAwLTEyNGMtNGUyNi05MTRlLTJjNGY2ZWM5Yzk1YiIsInR5cCI6IlJlZnJlc2giLCJhenAiOiJzZWN1cml0eS1hZG1pbi1jb25zb2xlIiwic2Vzc2lvbl9zdGF0ZSI6IjJjOTAwMzM5LWY2M2EtNDgwYi1iMmJlLTBmNmY0OWQ0NzcyZiIsImNsaWVudF9zZXNzaW9uIjoiMThhOWE0NDUtNWQxYy00ZjJmLWI2ZjEtMjQ0N2RkZDNjMDE1IiwicmVzb3VyY2VfYWNjZXNzIjp7InJlYWxtLW1hbmFnZW1lbnQiOnsicm9sZXMiOlsidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJ2aWV3LXJlYWxtIiwibWFuYWdlLWlkZW50aXR5LXByb3ZpZGVycyIsImltcGVyc29uYXRpb24iLCJyZWFsbS1hZG1pbiIsImNyZWF0ZS1jbGllbnQiLCJtYW5hZ2UtdXNlcnMiLCJtYW5hZ2UtZXZlbnRzIiwibWFuYWdlLXJlYWxtIiwidmlldy1ldmVudHMiLCJ2aWV3LXVzZXJzIiwidmlldy1jbGllbnRzIiwibWFuYWdlLWNsaWVudHMiXX19fQ.MPwbo7nnYspbbgAzWt2Z5ozWaMpP0ONI5WKAR-A8GkrrjYXTyJZk9mDLxHxUVaINboesSAhTd_RO4-g0k6yK8YOQLetztdl-YJxIUnVZQmCFdPwBOkty2Azmcib7mNI2eJWvUdFAIvpRhWt-2_P03DXAE0sAN4oS48HocQxKD2ZMHkB_rDWwKX313l_wFxUkW5T9tOv93jMHFx8k6dGV5GWVEH6-fuw4K5k-zUGRxKrBsQaCxJrpmjxXsx2gFqoYgU8PnRk2ReqblEIxC4fQfMk0SsW0Hm77_I0YaPMPW-yn4eULm31yYqnWOphZhtNmybMgi2Y8iJ_Q2yqCU2iJkw","token_type":"bearer","id_token":"eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5YWM5M2UxNy1jMGJiLTQyZDYtYWM2Mi1kYmVhNWU0NmJmMWQiLCJleHAiOjE0NTUxNDc5NzgsIm5iZiI6MCwiaWF0IjoxNDU1MTQ3Njc4LCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZm9ydW0iLCJhdWQiOiJzZWN1cml0eS1hZG1pbi1jb25zb2xlIiwic3ViIjoiZjc4NWU2MDAtMTI0Yy00ZTI2LTkxNGUtMmM0ZjZlYzljOTViIiwidHlwIjoiSUQiLCJhenAiOiJzZWN1cml0eS1hZG1pbi1jb25zb2xlIiwic2Vzc2lvbl9zdGF0ZSI6IjJjOTAwMzM5LWY2M2EtNDgwYi1iMmJlLTBmNmY0OWQ0NzcyZiIsIm5hbWUiOiJDaGFybGVzIFF1ZWlyb3oiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJjaGFybGVzIiwiZ2l2ZW5fbmFtZSI6IkNoYXJsZXMiLCJsb2NhbGUiOiJwdC1CUiIsImZhbWlseV9uYW1lIjoiUXVlaXJveiIsImVtYWlsIjoiY2hhcmxlc0BkYXplbi5jb20ifQ.YxeYJ9cKFyDRQ1YyJbwflQSr-n8l9nW1ORsvQbWo1XYfd6UqiUJlSsygIg4JqFIJGfCU_X8DJcV5HmdOtt90IHqW0_Oc6P8ZvVA1UdGEcoWlVBi88Hd_dIGC3WgyaE4WdOW1KC6nh3Eba2KmdUPQQ3xRKYXd9-pxmE2DwDrHZtONd8EaqTeK4J8vE34Jr_BQyNdv9yGztUh73AGVXAeVk4MqKBRAVmcod_eYOpaaf2OfQwaHQZpskwVqrEIIffyXmIMwD1MbmIP4tMPdMnNBK7bzNO-Qx7VTgWOuTu-VRQQoH0-fXetJdxKb5O1_2G7qCi_CYLeolh2DbIWswM6bag","not-before-policy":0,"session-state":"2c900339-f63a-480b-b2be-0f6f49d4772f"}"
> 20:41:18,409 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
> 20:41:18,409 DEBUG [org.apache.http.wire] (default task-14)  << "0[\r][\n]"
> 20:41:18,409 DEBUG [org.apache.http.wire] (default task-14)  << "[\r][\n]"
> 20:41:18,409 DEBUG
> [org.apache.http.impl.conn.BasicClientConnectionManager] (default task-14)
> Releasing connection
> org.apache.http.impl.conn.ManagedClientConnectionImpl at 24993c5f
> 20:41:18,409 DEBUG
> [org.apache.http.impl.conn.BasicClientConnectionManager] (default task-14)
> Connection can be kept alive indefinitely
> 20:41:18,413 DEBUG [org.jboss.as.jpa] (default task-14) default
> task-14:transaction scoped EntityManager [forum.war#ForumPU]: closing
> entity managersession
> 20:41:18,414 DEBUG
> [org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl]
> (default task-14) Initiating JDBC connection release from afterTransaction
> 20:41:18,414 ERROR [org.jboss.as.ejb3.invocation] (default task-14)
> WFLYEJB0034: EJB Invocation failed on component UserRestEndpoint for method
> public javax.ws.rs.core.Response
> br.com.projetolead.forum.integration.rest.UserRestEndpoint.save(br.com.projetolead.forum.model.User,javax.servlet.http.HttpServletRequest)
> throws java.io.IOException: javax.ejb.EJBException:
> javax.ws.rs.client.ResponseProcessingException:
> javax.ws.rs.ProcessingException:
> com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException:
> Unrecognized field "access_token" (class
> org.keycloak.representations.AccessTokenResponse), not marked as ignorable
> (9 known properties: "notBeforePolicy", "otherClaims", "tokenType",
> "token", "expiresIn", "sessionState", "refreshExpiresIn", "idToken",
> "refreshToken"])
>  at [Source: org.apache.http.conn.EofSensorInputStream at 5af6ffba; line: 1,
> column: 18] (through reference chain:
> org.keycloak.representations.AccessTokenResponse["access_token?])
>
> ------
>
>
> Where is the problem?
>
> Atenciosamente,
>
> *Charles Queiroz *
> ------------------------------
>
> *Dazen?* *IT Services*
> *Technology - Software Development *
> charles at dazen.com.br
> Fortaleza - CE
> Phone: +55 85 9933 1585
>
> Twitter: @CharlesQueiiroz
>
>
> _______________________________________________
> 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/20160211/af76a807/attachment-0001.html 

From sthorger at redhat.com  Thu Feb 11 03:22:03 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 11 Feb 2016 09:22:03 +0100
Subject: [keycloak-user] What's the point of creating roles per realm
	and client?
In-Reply-To: <CAEBys6K-BacvNLaFCvPviagCSpRjoTwURuWMzHJr3B4b0PhGSA@mail.gmail.com>
References: <CAEBys6K-BacvNLaFCvPviagCSpRjoTwURuWMzHJr3B4b0PhGSA@mail.gmail.com>
Message-ID: <CAJgngAfnSuMSL8SDOEP3DdNU0c8zg7R2dn06UtsohJoHyYeF6Q@mail.gmail.com>

Realm roles vs client roles are there to give you an option. You can use
one or both, it's up to you.

In general realm roles would be roles that are global to your organization
(for example sales, admin, etc..). While client roles would be roles that
are specific to the client.

On 11 February 2016 at 07:33, Renann Prado <darkness.renann at gmail.com>
wrote:

> I'm pretty new to keycloak. Amazing application btw.
> It's working very well, however I found strange/confusing that I have to
> create roles in the level of the realm, then per client and then assign to
> each user.
> What I mean is: why don't we have the roles created in the level of the
> realm and then we just assign per application user or is there an option to
> make that happen?
> Otherwise I have to keep creating roles for all clients, then assigning
> for all users. In my case there aren't many users/roles/applications, so
> it's fine. But it would be nice to know how to do that.
>
> Thanks
>
> Renann Prado
>
> _______________________________________________
> 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/20160211/a884965a/attachment.html 

From sthorger at redhat.com  Thu Feb 11 03:24:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 11 Feb 2016 09:24:39 +0100
Subject: [keycloak-user] How do I set session variable upon first API
	hit?
In-Reply-To: <CAEBys6KzAL5eGOJUaBgRB6swk7_khd5F4rSEfttgp70fYyYomw@mail.gmail.com>
References: <CAEBys6KzAL5eGOJUaBgRB6swk7_khd5F4rSEfttgp70fYyYomw@mail.gmail.com>
Message-ID: <CAJgngAe3bXP-OLvMYHBYvA3iEKnPzzdJMfjhqKUQXmoxtjP-7Q@mail.gmail.com>

Assuming you're talking about an JEE application, why not just use a
servlet filter? Make it take a peek in the http session to check if the
variables are set, if not load from database and add them.

On 11 February 2016 at 08:38, Renann Prado <darkness.renann at gmail.com>
wrote:

> Basically I have some session variables that should be set upon first hit
> in the API (using bearer token). The requirement is that session variables
> will be dynamically loaded from the database and put into the http session
> before I actually process the request, so I can use the variables to
> process it.
>
> Thanks
>
> _______________________________________________
> 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/20160211/e93d363a/attachment.html 

From mposolda at redhat.com  Thu Feb 11 03:26:13 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 11 Feb 2016 09:26:13 +0100
Subject: [keycloak-user] ldap federation provider
In-Reply-To: <5EB73BCF-AC62-460F-8F45-9A784EE5311B@izeno.com>
References: <5EB73BCF-AC62-460F-8F45-9A784EE5311B@izeno.com>
Message-ID: <56BC45A5.9080008@redhat.com>

Depends on EDIT_MODE you choose. After you add LDAP federation provider, 
then with all 3 modes, you are able to authenticate existing LDAP users 
with existing LDAP passwords. But when you're update password through 
Keycloak admin console or account management then:
- if edit mode is READABLE, password update from Keycloak is not allowed 
and it will fail with "User is read only"
- if edit mode is WRITABLE, password will be updated in LDAP. So during 
next password checks, Keycloak will still use LDAP to authenticate user 
against. Also all your apps integrated directly with LDAP should be able 
to see newly updated password in LDAP.
- if edit mode is UNSYNCED, password will be updated in Keycloak DB, but 
not in LDAP. Next password checks from Keycloak will use Keycloak DB and 
hence new password. But your apps integrated directly with LDAP will 
still see the old password.

Marek

On 11/02/16 02:15, chenkeong.yap at izeno.com wrote:
> hi guys,
>
> please assist to clarify. after adding ldap federation provider, is the password stored in keycloak database? if yes, is there anyway to prevent sync of password?
>
> Regards,
> CK Yap
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From bmcwhirt at redhat.com  Thu Feb 11 05:27:22 2016
From: bmcwhirt at redhat.com (Bob McWhirter)
Date: Thu, 11 Feb 2016 10:27:22 +0000
Subject: [keycloak-user] NullPointerException during deployment
In-Reply-To: <56BBDDF5.2030008@redhat.com>
References: <CAEBys6+VE-Ni16t_P+nZp-Fo_p4fvJwr0Sq5vc5VZZ--yxGmBw@mail.gmail.com>
	<56BBD54D.8080004@redhat.com>
	<CAEBys6LUVAS+mqcCnCCx+nV8E1C-wU3TNaeFx8bFphfM3psmaw@mail.gmail.com>
	<56BBDDF5.2030008@redhat.com>
Message-ID: <CA+45JvEiC81Ekf+2UYA_oYYshruxbj3xyJnoCspRnNJS1NBKAg@mail.gmail.com>

For reference:

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

On Thu, Feb 11, 2016 at 1:03 AM, Bill Burke <bburke at redhat.com> wrote:

> Yes, this is because the error was introduced in 1.9.RC1.
>
> Tutorials are a bit ancient.  We'll be updating them soon....but if you
> download the demo distribution, there are tons of examples.
>
>
> On 2/10/2016 7:30 PM, Renann Prado wrote:
>
> I changed to 1.8.1.Final and it worked!
> Now my only problem is that, for some reason, I do not get redirected to
> the login page when I access a protected resource.
> I'm watching your tutorial right now to try to understand why it isn't
> working.
>
> Thanks
> On Feb 10, 2016 22:27, "Bill Burke" < <bburke at redhat.com>bburke at redhat.com>
> wrote:
>
>> Its a scheduled bug.  Fixed in master.
>>
>> On 2/10/2016 3:23 PM, Renann Prado wrote:
>>
>> I've been following keycloak guide, but I'm facing the below exception.
>> I'm trying to secure a WAR that is inside of an EAR, I've tried to add
>> below two dependencies in my pom.xml.
>> What am I missing?
>>
>> *Wildfly version: *10.0.0.Final
>> *Keycloak version: *1.9.0.CR1
>>
>> *Dependencies (tried in EAR and in WAR, no luck):*
>>
>> <dependency>
>>     <groupId>org.keycloak</groupId>
>>     <artifactId>keycloak-core</artifactId>
>>     <version>1.9.0.CR1</version>
>>     <scope>provided</scope>
>> </dependency>
>> <dependency>
>>     <groupId>org.keycloak</groupId>
>>     <artifactId>keycloak-adapter-core</artifactId>
>>     <version>1.9.0.CR1</version>
>>     <scope>provided</scope>
>> </dependency>
>>
>> *Subsystem configuration:*
>>
>> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>     <secure-deployment name="Test-web-1.0-SNAPSHOT.war">
>>         <realm>TestRealm</realm>
>>         <resource>test-resource</resource>
>>
>> <realm-public-key>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmpxbZQMAf2NPcWCbdVWfu3JKEZ5PHuL+a5JTzyuln/wXpfhGPyCDS8rYDj2tf5lA8WQYoV8M5ip3DbCdL43wsW8/oJM/UOKn7mwy2x0OdW40bw1c8b1D6FveliIXwtovyw0EGCFn67qLdtHPLAlVvv5UXPIPFCakzdx1xS/6zgZ1uF2fzwLZpLh21M9XYNHQk6ui047+13Uf5H5yYQNLin8WluZ4JLfO8teVV9ARTqezVoZ5/+SNH4Mw+N1i7sGr13mzl51XvpFmm10Yx0dNiuy+WPA9xv1eNWcWgQWXxCEzDBenn59pmZ9JnTpoOqvZknmBGqyQPDqN9tJIWnWZKQIDAQAB</realm-public-key>
>>         <auth-server-url> <http://localhost:8082/auth>
>> http://localhost:8082/auth</auth-server-url>
>>         <ssl-required>none</ssl-required>
>>         <credential name="secret">password</credential>
>>     </secure-deployment>
>> </subsystem>
>>
>> *Exception*
>>
>>
>> 8:13:18,779 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3)
>> MSC000001: Failed to start service
>> jboss.deployment.unit."Test-ear.ear".DEPENDENCIES:
>> org.jboss.msc.service.StartException in service
>> jboss.deployment.unit."Test-ear.ear".DEPENDENCIES: WFLYSRV0153: Failed to
>> process phase DEPENDENCIES of deployment "Test-ear.ear"
>> at
>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
>> 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)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:745)
>> Caused by: java.lang.NullPointerException
>> at
>> org.keycloak.subsystem.adapter.extension.KeycloakDependencyProcessor.deploy(KeycloakDependencyProcessor.java:52)
>> at
>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
>> ... 5 more
>>
>> 18:13:18,784 ERROR [org.jboss.as.controller.management-operation]
>> (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed -
>> address: ([("deployment" => "Test-ear.ear")]) - failure description:
>> {"WFLYCTL0080: Failed services" =>
>> {"jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES" =>
>> "org.jboss.msc.service.StartException in service
>> jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES: WFLYSRV0153: Failed to
>> process phase DEPENDENCIES of deployment \"Test-ear.ear\"
>>     Caused by: java.lang.NullPointerException"}}
>> 18:13:18,786 ERROR [org.jboss.as.server] (management-handler-thread - 2)
>> WFLYSRV0021: Deploy of deployment "Test-ear.ear" was rolled back with the
>> following failure message:
>> {"WFLYCTL0080: Failed services" =>
>> {"jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES" =>
>> "org.jboss.msc.service.StartException in service
>> jboss.deployment.unit.\"Test-ear.ear\".DEPENDENCIES: WFLYSRV0153: Failed to
>> process phase DEPENDENCIES of deployment \"Test-ear.ear\"
>>     Caused by: java.lang.NullPointerException"}}
>>
>> Renann Prado
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.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 Hathttp://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/20160211/7ae2ec4e/attachment-0001.html 

From jayblanc at gmail.com  Thu Feb 11 06:19:53 2016
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Thu, 11 Feb 2016 11:19:53 +0000
Subject: [keycloak-user] trouble acting as SP with testshib.org IdP
In-Reply-To: <CAC_FVB6HywJ-2pxmXy8zTASwqO8KgTEajzbva8NJ43r6gk+Aqg@mail.gmail.com>
References: <CAC_FVB7XdAzxSOCX4Dsq0gz4M+xiwChSiwdYjOhXqVLB7mREbQ@mail.gmail.com>
	<CAPNq5vbz4j5JGBP9S-FO4Pagy4402YSLJD2BkgN5Erecfxv0SQ@mail.gmail.com>
	<CAC_FVB6HywJ-2pxmXy8zTASwqO8KgTEajzbva8NJ43r6gk+Aqg@mail.gmail.com>
Message-ID: <CAPNq5va7BGjPzYU+sQncvvQkXrqBFhEaZ_MEGs1EDyiN1CAAGQ@mail.gmail.com>

I'm able to reproduce your bug.
Making authentication using debug mode a break point in
AssertionUtil.getAssertion() show that the IdP refuse to use unencrypted
response :

StatusType [statusCode=StatusCodeType
[value=urn:oasis:names:tc:SAML:2.0:status:Responder, statusCode=null],
statusMessage=Unable to encrypt assertion, statusDetail=null]

By the way, when I try to use the Want AuthnRequests Signed= true, I can't
upload the configuration to the testshib site because it considere the file
as not wellformed !!

I'm sorry, but it seems that the configuration os the testshib is very well
coupled to shibboleth... Maybe you could try with your own instance of an
IdP.

Best regards, J?r?me.

Le mer. 10 f?vr. 2016 ? 17:03, Steve Nolen <technolengy at gmail.com> a ?crit :

> Hi J?r?me,
>
> Thanks for the help! I swapped the NameId in keycloak for this broker to
> unspecified (I uploaded my sp metadata to testshib.org again as well just
> in case) and am still receiving the same error.
>
> On Wed, Feb 10, 2016 at 1:10 AM J?r?me Blanchard <jayblanc at gmail.com>
> wrote:
>
>> Hi Steve,
>>
>> I'm using Keycloak as a shibboleth SP in a federation (Renater) and It's
>> working fine. The problem you encounter comes from the fact that you ask
>> for a persistent nameId in the config of your SP and, according to the
>> provider details, it's only able to send transient nameId.
>> Feel the parameter of nameId to undefined and check the authentication
>> again.
>>
>> Best regards, J?r?me.
>>
>> Le mer. 10 f?vr. 2016 ? 03:57, Steve Nolen <technolengy at gmail.com> a
>> ?crit :
>>
>>> Hi!
>>>
>>> First of all, keycloak is legitimately awesome!
>>>
>>> I was attempting to test the use of keycloak as a shibboleth SP today
>>> (testing against the testshib.org test IdP) and am having some trouble.
>>>
>>> Keycloak Version: 1.9.0CR1 (using it on openshift currently)
>>>
>>> Both sides seem to be set up as they should (I used the testshib
>>> endpoint to import the settings to keycloak). I'm able to take the redirect
>>> over to idp.testshib but on logging in I get a 500 Internal Server Error
>>> from keycloak.  The message is "No Assertion from response" (stack trace
>>> below).
>>>
>>> Any thoughts on what might be missing?
>>>
>>> ==== stack trace ====
>>> http://pastebin.com/3tsApUKK
>>>
>>> ==== broker details ====
>>>
>>> https://keycloak-technolengy.rhcloud.com/auth/realms/technolengy/broker/testshib.org/endpoint/descriptor
>>>
>>> ==== provider details ====
>>> https://www.testshib.org/metadata/testshib-providers.xml
>>>
>>> Thank you!
>>> Steve
>>>
>> _______________________________________________
>>> 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/20160211/eea1c3ae/attachment.html 

From kga.official at gmail.com  Thu Feb 11 06:29:27 2016
From: kga.official at gmail.com (Akshay Kini)
Date: Thu, 11 Feb 2016 16:59:27 +0530
Subject: [keycloak-user] Keycloak as a SAML SP: Is it possible to configure
 Keycloak to use RSA-SHA256 as the algorithm to sign assertions.
Message-ID: <CAFtx=Tk2X-uQDuFbO5f_rEHRHkdNLPE7ArtMW3uLc-Q0_FJwgg@mail.gmail.com>

Hi Folks,

We are using Keycloak as a SAML SP.

I notice that SAML Assertions are signed using rsa-sha1, could we configure
it to use RSA-SHA256?

Thanks,
Regards,
Akshay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/943c29b8/attachment.html 

From prado.renann at gmail.com  Thu Feb 11 07:04:33 2016
From: prado.renann at gmail.com (Renann Prado)
Date: Thu, 11 Feb 2016 10:04:33 -0200
Subject: [keycloak-user] How do I set session variable upon first API
	hit?
In-Reply-To: <CAEBys6KRNbnhNK1pe82tR8mSoLxO=iP26PJa07oDx07kamxW4A@mail.gmail.com>
References: <CAEBys6KzAL5eGOJUaBgRB6swk7_khd5F4rSEfttgp70fYyYomw@mail.gmail.com>
	<CAJgngAe3bXP-OLvMYHBYvA3iEKnPzzdJMfjhqKUQXmoxtjP-7Q@mail.gmail.com>
	<CAEBys6KRNbnhNK1pe82tR8mSoLxO=iP26PJa07oDx07kamxW4A@mail.gmail.com>
Message-ID: <CAEBys6JGhBQAkQuuuGsWi=iKQpA-LZyLuq3nCzOoMsHec3ZoGQ@mail.gmail.com>

On Feb 11, 2016 10:03, "Renann Prado" <prado.renann at gmail.com> wrote:

> Yes, it is a JEE application and I am using standard adapter.
> I thought about creating a servlet filter, but is this the right approach
> to take?
>
> Thanks
> On Feb 11, 2016 06:24, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>
>> Assuming you're talking about an JEE application, why not just use a
>> servlet filter? Make it take a peek in the http session to check if the
>> variables are set, if not load from database and add them.
>>
>> On 11 February 2016 at 08:38, Renann Prado <darkness.renann at gmail.com>
>> wrote:
>>
>>> Basically I have some session variables that should be set upon first
>>> hit in the API (using bearer token). The requirement is that session
>>> variables will be dynamically loaded from the database and put into the
>>> http session before I actually process the request, so I can use the
>>> variables to process it.
>>>
>>> Thanks
>>>
>>> _______________________________________________
>>> 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/20160211/43d80814/attachment.html 

From leo.nunes at gjccorp.com.br  Thu Feb 11 08:09:56 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Thu, 11 Feb 2016 13:09:56 +0000
Subject: [keycloak-user] Failed to make identity provider oauth callback:
 javax.net.ssl.SSLHandshakeException
Message-ID: <D2E21C82.26535%leo.nunes@ojc.com.br>

Hi, i'm getting the error below when I try to login with Facebook.
I've followed the instructions at http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore and http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337

I was able to login with Facebook when trying at localhost. But at our development server we are getting this error.

We are using EAP in domain mode.

The truststore I placed inside of keycloak-server.json
"truststore": {
        "file": {
            "file": "/home/soa/jboss/ssl/keycloak.jks",
            "password": "keycloak123",
            "hostname-verification-policy": "ANY",
            "disabled": false
        }
    }


#######

ERRO:


2016-02-11 10:44:53,927 ERROR [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (ajp-/192.168.162.73:8008-1) Failed to make identity provider oauth callback: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937) [jsse.jar:1.8.0_45]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) [jsse.jar:1.8.0_45]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) [jsse.jar:1.8.0_45]
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478) [jsse.jar:1.8.0_45]
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212) [jsse.jar:1.8.0_45]
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969) [jsse.jar:1.8.0_45]
at sun.security.ssl.Handshaker.process_record(Handshaker.java:904) [jsse.jar:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050) [jsse.jar:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363) [jsse.jar:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391) [jsse.jar:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375) [jsse.jar:1.8.0_45]
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563) [rt.jar:1.8.0_45]
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) [rt.jar:1.8.0_45]
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282) [rt.jar:1.8.0_45]
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257) [rt.jar:1.8.0_45]
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250) [rt.jar:1.8.0_45]
at org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
at org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61) [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387) [rt.jar:1.8.0_45]
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292) [rt.jar:1.8.0_45]
at sun.security.validator.Validator.validate(Validator.java:260) [rt.jar:1.8.0_45]
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) [jsse.jar:1.8.0_45]
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229) [jsse.jar:1.8.0_45]
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124) [jsse.jar:1.8.0_45]
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460) [jsse.jar:1.8.0_45]
... 50 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145) [rt.jar:1.8.0_45]
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131) [rt.jar:1.8.0_45]
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280) [rt.jar:1.8.0_45]
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382) [rt.jar:1.8.0_45]
... 56 more





--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/f26bd6c2/attachment-0001.html 

From prado.renann at gmail.com  Thu Feb 11 08:16:29 2016
From: prado.renann at gmail.com (Renann Prado)
Date: Thu, 11 Feb 2016 11:16:29 -0200
Subject: [keycloak-user] User-Federation
In-Reply-To: <E4193CB0-4921-45BD-AA73-8BA39AF8D3C0@carbonite.com>
References: <CADW1CM8kNr=WkTSm4jp_BZm4Bdm6JSJhSLgPvhLQxDSmrC653A@mail.gmail.com>
	<E4193CB0-4921-45BD-AA73-8BA39AF8D3C0@carbonite.com>
Message-ID: <CAEBys6KM1-n6wFqTJAAqb_aYaQdZwuiaUz2AspF5d-8Za=E9wQ@mail.gmail.com>

Is there any recommended way to make sure these endpoints won't be spammed
by an attacker? Looks like these endpoints need to be open to anyone.

Thanks
On Feb 3, 2016 11:18, "Reed Lewis" <RLewis at carbonite.com> wrote:

> If you use the federation provider listed here:
>
> [0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
> [1]: https://github.com/Smartling/keycloak-user-migration-provider
>
> You can specify a URL that will be called when a user needs to be
> validated.
>
> There are three requests that need to be implemented in your sever.
>
> GET <baseURL>/api/users/<username>/
> If the user exists, it should return a 200 with a json object with the
> return type ?application/json? with the following fields:
> username
> email
> emailVerified
> firstName
> lastName
> roles [?user?]
>
> If the user does not exist, return a 404
>
> HEAD <baseURL>/api/users/<username>/
> Always return 200
>
> POST <baseURL>/api/users/<username>/
> The password is posted to you in a json object.
> Return 200 if the password is OK, 401 if not.  In both cases return no
> data.
>
> I wrote a small python module which implements these methods which works
> quite well.
>
> Reed
>
> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stuart Jacobs <
> stuart.jacobs at symbiotics.co.za>
> Date: Wednesday, February 3, 2016 at 2:40 AM
> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: [keycloak-user] User-Federation
>
> Hi Everyone,
>
> I have an application that runs on a postgresql database, keycloak has
> been configured and has created all the required tables/columns in my
> schema using liquibase on start up of the keycloak server.
>
> I need to authenticate users using the projects existing user table
> obtaining the username and password from this table.
>
> I have had a look at the federation provider project under the example
> projects but this still eludes me as to how I change the keycloak mapping
> to use my own tables in postgress?
>
> Can someone please point me in the right direction or if someone has
> implemented such a solution please share how you have done it?
>
> Thanks everyone.
>
>   Regards,
>   Stuart Jacobs
>
>
>
>
>
>
>
> www.symbiotics.co.za
>
> ********************************************************************************
> This email and any accompanying attachments may contain confidential and
> proprietary information. This information is private and protected by law
> and, accordingly, if you are not the intended recipient, you are requested
> to delete this entire communication immediately and are notified that any
> disclosure, copying or distribution of or taking any action based on this
> information is prohibited.
>
> Emails cannot be guaranteed to be secure or free of errors or viruses. The
> sender does not accept any liability or responsibility for any
> interception, corruption, destruction, loss, late arrival or incompleteness
> of or tampering or interference with any of the information contained in
> this email or for its incorrect delivery or non-delivery for whatsoever
> reason or for its effect on any electronic device of the recipient.
>
> ********************************************************************************
>
>
> _______________________________________________
> 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/20160211/d777c2bf/attachment.html 

From prado.renann at gmail.com  Thu Feb 11 08:17:14 2016
From: prado.renann at gmail.com (Renann Prado)
Date: Thu, 11 Feb 2016 11:17:14 -0200
Subject: [keycloak-user] User-Federation
In-Reply-To: <CAEBys6KM1-n6wFqTJAAqb_aYaQdZwuiaUz2AspF5d-8Za=E9wQ@mail.gmail.com>
References: <CADW1CM8kNr=WkTSm4jp_BZm4Bdm6JSJhSLgPvhLQxDSmrC653A@mail.gmail.com>
	<E4193CB0-4921-45BD-AA73-8BA39AF8D3C0@carbonite.com>
	<CAEBys6KM1-n6wFqTJAAqb_aYaQdZwuiaUz2AspF5d-8Za=E9wQ@mail.gmail.com>
Message-ID: <CAEBys6+i6jFdycaCg-rf9vC=T7chbrkKeWsfAbNvC2tidKdhZw@mail.gmail.com>

Everyone*
On Feb 11, 2016 11:16, "Renann Prado" <prado.renann at gmail.com> wrote:

> Is there any recommended way to make sure these endpoints won't be spammed
> by an attacker? Looks like these endpoints need to be open to anyone.
>
> Thanks
> On Feb 3, 2016 11:18, "Reed Lewis" <RLewis at carbonite.com> wrote:
>
>> If you use the federation provider listed here:
>>
>> [0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
>> [1]: https://github.com/Smartling/keycloak-user-migration-provider
>>
>> You can specify a URL that will be called when a user needs to be
>> validated.
>>
>> There are three requests that need to be implemented in your sever.
>>
>> GET <baseURL>/api/users/<username>/
>> If the user exists, it should return a 200 with a json object with the
>> return type ?application/json? with the following fields:
>> username
>> email
>> emailVerified
>> firstName
>> lastName
>> roles [?user?]
>>
>> If the user does not exist, return a 404
>>
>> HEAD <baseURL>/api/users/<username>/
>> Always return 200
>>
>> POST <baseURL>/api/users/<username>/
>> The password is posted to you in a json object.
>> Return 200 if the password is OK, 401 if not.  In both cases return no
>> data.
>>
>> I wrote a small python module which implements these methods which works
>> quite well.
>>
>> Reed
>>
>> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stuart Jacobs
>> <stuart.jacobs at symbiotics.co.za>
>> Date: Wednesday, February 3, 2016 at 2:40 AM
>> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>> Subject: [keycloak-user] User-Federation
>>
>> Hi Everyone,
>>
>> I have an application that runs on a postgresql database, keycloak has
>> been configured and has created all the required tables/columns in my
>> schema using liquibase on start up of the keycloak server.
>>
>> I need to authenticate users using the projects existing user table
>> obtaining the username and password from this table.
>>
>> I have had a look at the federation provider project under the example
>> projects but this still eludes me as to how I change the keycloak mapping
>> to use my own tables in postgress?
>>
>> Can someone please point me in the right direction or if someone has
>> implemented such a solution please share how you have done it?
>>
>> Thanks everyone.
>>
>>   Regards,
>>   Stuart Jacobs
>>
>>
>>
>>
>>
>>
>>
>> www.symbiotics.co.za
>>
>> ********************************************************************************
>> This email and any accompanying attachments may contain confidential and
>> proprietary information. This information is private and protected by law
>> and, accordingly, if you are not the intended recipient, you are requested
>> to delete this entire communication immediately and are notified that any
>> disclosure, copying or distribution of or taking any action based on this
>> information is prohibited.
>>
>> Emails cannot be guaranteed to be secure or free of errors or viruses.
>> The sender does not accept any liability or responsibility for any
>> interception, corruption, destruction, loss, late arrival or incompleteness
>> of or tampering or interference with any of the information contained in
>> this email or for its incorrect delivery or non-delivery for whatsoever
>> reason or for its effect on any electronic device of the recipient.
>>
>> ********************************************************************************
>>
>>
>> _______________________________________________
>> 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/20160211/6164ad32/attachment.html 

From bburke at redhat.com  Thu Feb 11 09:06:49 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 11 Feb 2016 09:06:49 -0500
Subject: [keycloak-user] Keycloak as a SAML SP: Is it possible to
 configure Keycloak to use RSA-SHA256 as the algorithm to sign assertions.
In-Reply-To: <CAFtx=Tk2X-uQDuFbO5f_rEHRHkdNLPE7ArtMW3uLc-Q0_FJwgg@mail.gmail.com>
References: <CAFtx=Tk2X-uQDuFbO5f_rEHRHkdNLPE7ArtMW3uLc-Q0_FJwgg@mail.gmail.com>
Message-ID: <56BC9579.8080102@redhat.com>

Where?  Keycloak Saml SP?  Keycloak Server interaction with an 
app/client?  Or Keycloak Server acting as an SP in a broker scenario?

They all *should* support plugging in the algorithm.  Did you configure 
this correctly?

On 2/11/2016 6:29 AM, Akshay Kini wrote:
> Hi Folks,
>
> We are using Keycloak as a SAML SP.
>
> I notice that SAML Assertions are signed using rsa-sha1, could we 
> configure it to use RSA-SHA256?
>
> Thanks,
> Regards,
> Akshay
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/573d1ced/attachment-0001.html 

From sthorger at redhat.com  Thu Feb 11 09:23:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 11 Feb 2016 15:23:39 +0100
Subject: [keycloak-user] Failed to make identity provider oauth
	callback: javax.net.ssl.SSLHandshakeException
In-Reply-To: <D2E21C82.26535%leo.nunes@ojc.com.br>
References: <D2E21C82.26535%leo.nunes@ojc.com.br>
Message-ID: <CAJgngAfV0HFHT=_rBYe0XQHNeBwKTTrm10gUU=xd24=pAq2KvQ@mail.gmail.com>

Does it work if you don't specify the truststore? That will use the default
truststore provided by the JDK.

Also, does your truststore contain the required CA certs? For Facebook to
work it'll have to contain the required CA's for their certs

On 11 February 2016 at 14:09, LEONARDO NUNES <leo.nunes at gjccorp.com.br>
wrote:

> Hi, i'm getting the error below when I try to login with Facebook.
> I've followed the instructions at
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore
>  and
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337
>
> I was able to login with Facebook when trying at localhost. But at our
> development server we are getting this error.
>
> We are using EAP in domain mode.
>
> The truststore I placed inside of keycloak-server.json
> "truststore": {
>         "file": {
>             "file": "/home/soa/jboss/ssl/keycloak.jks",
>             "password": "keycloak123",
>             "hostname-verification-policy": "ANY",
>             "disabled": false
>         }
>     }
>
>
> #######
>
> ERRO:
>
>
> 2016-02-11 10:44:53,927 ERROR
> [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider]
> (ajp-/192.168.162.73:8008-1) Failed to make identity provider oauth
> callback: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> [jsse.jar:1.8.0_45]
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
> [jsse.jar:1.8.0_45]
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> [jsse.jar:1.8.0_45]
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> [jsse.jar:1.8.0_45]
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
> [jsse.jar:1.8.0_45]
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
> [jsse.jar:1.8.0_45]
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
> [jsse.jar:1.8.0_45]
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
> [jsse.jar:1.8.0_45]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
> [jsse.jar:1.8.0_45]
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
> [jsse.jar:1.8.0_45]
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
> [jsse.jar:1.8.0_45]
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
> [jsse.jar:1.8.0_45]
> at
> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
> [rt.jar:1.8.0_45]
> at
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
> [rt.jar:1.8.0_45]
> at
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282)
> [rt.jar:1.8.0_45]
> at
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257)
> [rt.jar:1.8.0_45]
> at
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
> [rt.jar:1.8.0_45]
> at
> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
> at
> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.8.0_45]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [rt.jar:1.8.0_45]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_45]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
> at
> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
> at
> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
> at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at
> org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> Caused by: sun.security.validator.ValidatorException: PKIX path building
> failed: sun.security.provider.certpath.SunCertPathBuilderException: unable
> to find valid certification path to requested target
> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
> [rt.jar:1.8.0_45]
> at
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
> [rt.jar:1.8.0_45]
> at sun.security.validator.Validator.validate(Validator.java:260)
> [rt.jar:1.8.0_45]
> at
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> [jsse.jar:1.8.0_45]
> at
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> [jsse.jar:1.8.0_45]
> at
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> [jsse.jar:1.8.0_45]
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
> [jsse.jar:1.8.0_45]
> ... 50 more
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException:
> unable to find valid certification path to requested target
> at
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
> [rt.jar:1.8.0_45]
> at
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
> [rt.jar:1.8.0_45]
> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
> [rt.jar:1.8.0_45]
> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
> [rt.jar:1.8.0_45]
> ... 56 more
>
>
>
>
>
> --
> Leonardo Nunes
> ------------------------------
>
>
> *Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem,
> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar
> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por
> engano, por favor avise imediatamente o remetente, respondendo o e-mail e
> em seguida apague-o. Agradecemos sua coopera??o. This message may contain
> confidential and/or privileged information. If you are not the addressee or
> authorized to receive this for the addressee, you must not use, copy,
> disclose or take any action based on this message or any information
> herein. If you have received this message in error, please advise the
> sender immediately by reply e-mail and delete this message. Thank you for
> your cooperation*
>
> _______________________________________________
> 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/20160211/b21c30fb/attachment.html 

From RLewis at carbonite.com  Thu Feb 11 09:35:31 2016
From: RLewis at carbonite.com (Reed Lewis)
Date: Thu, 11 Feb 2016 14:35:31 +0000
Subject: [keycloak-user] User-Federation
In-Reply-To: <CAEBys6+i6jFdycaCg-rf9vC=T7chbrkKeWsfAbNvC2tidKdhZw@mail.gmail.com>
References: <CADW1CM8kNr=WkTSm4jp_BZm4Bdm6JSJhSLgPvhLQxDSmrC653A@mail.gmail.com>
	<E4193CB0-4921-45BD-AA73-8BA39AF8D3C0@carbonite.com>
	<CAEBys6KM1-n6wFqTJAAqb_aYaQdZwuiaUz2AspF5d-8Za=E9wQ@mail.gmail.com>
	<CAEBys6+i6jFdycaCg-rf9vC=T7chbrkKeWsfAbNvC2tidKdhZw@mail.gmail.com>
Message-ID: <81B2EA95-4A60-4992-ADF0-17AD754D1E46@carbonite.com>

The endpoint that is used by the federation provider is only called from Keycloak, so you can run it on localhost on the keycloak machine if that is going to work for you.

OTOH, if you need to run it on a different machine, you can lock down the endpoint to only be accessible from the Keycloak server.

End users never call the endpoint I documented.

Reed

From: <darkness.renann at gmail.com<mailto:darkness.renann at gmail.com>> on behalf of Renann Prado <prado.renann at gmail.com<mailto:prado.renann at gmail.com>>
Date: Thursday, February 11, 2016 at 8:17 AM
To: Reed Lewis <RLewis at carbonite.com<mailto:RLewis at carbonite.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>, Stuart Jacobs <stuart.jacobs at symbiotics.co.za<mailto:stuart.jacobs at symbiotics.co.za>>
Subject: Re: [keycloak-user] User-Federation


Everyone*

On Feb 11, 2016 11:16, "Renann Prado" <prado.renann at gmail.com<mailto:prado.renann at gmail.com>> wrote:

Is there any recommended way to make sure these endpoints won't be spammed by an attacker? Looks like these endpoints need to be open to anyone.

Thanks

On Feb 3, 2016 11:18, "Reed Lewis" <RLewis at carbonite.com<mailto:RLewis at carbonite.com>> wrote:
If you use the federation provider listed here:

[0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
[1]: https://github.com/Smartling/keycloak-user-migration-provider

You can specify a URL that will be called when a user needs to be validated.

There are three requests that need to be implemented in your sever.

GET <baseURL>/api/users/<username>/
If the user exists, it should return a 200 with a json object with the return type ?application/json? with the following fields:
username
email
emailVerified
firstName
lastName
roles [?user?]

If the user does not exist, return a 404

HEAD <baseURL>/api/users/<username>/
Always return 200

POST <baseURL>/api/users/<username>/
The password is posted to you in a json object.
Return 200 if the password is OK, 401 if not.  In both cases return no data.

I wrote a small python module which implements these methods which works quite well.

Reed

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Stuart Jacobs <stuart.jacobs at symbiotics.co.za<mailto:stuart.jacobs at symbiotics.co.za>>
Date: Wednesday, February 3, 2016 at 2:40 AM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: [keycloak-user] User-Federation

Hi Everyone,

I have an application that runs on a postgresql database, keycloak has been configured and has created all the required tables/columns in my schema using liquibase on start up of the keycloak server.

I need to authenticate users using the projects existing user table obtaining the username and password from this table.

I have had a look at the federation provider project under the example projects but this still eludes me as to how I change the keycloak mapping to use my own tables in postgress?

Can someone please point me in the right direction or if someone has implemented such a solution please share how you have done it?

Thanks everyone.

  Regards,
  Stuart Jacobs





[http://symbiotics.co.za/website/image/ir.attachment/1578_e14aa73/datas]

www.symbiotics.co.za<http://www.symbiotics.co.za>
********************************************************************************
This email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited.

Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient.

********************************************************************************

_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/89e94a0e/attachment-0001.html 

From technolengy at gmail.com  Thu Feb 11 11:04:20 2016
From: technolengy at gmail.com (Steve Nolen)
Date: Thu, 11 Feb 2016 16:04:20 +0000
Subject: [keycloak-user] trouble acting as SP with testshib.org IdP
In-Reply-To: <CAPNq5va7BGjPzYU+sQncvvQkXrqBFhEaZ_MEGs1EDyiN1CAAGQ@mail.gmail.com>
References: <CAC_FVB7XdAzxSOCX4Dsq0gz4M+xiwChSiwdYjOhXqVLB7mREbQ@mail.gmail.com>
	<CAPNq5vbz4j5JGBP9S-FO4Pagy4402YSLJD2BkgN5Erecfxv0SQ@mail.gmail.com>
	<CAC_FVB6HywJ-2pxmXy8zTASwqO8KgTEajzbva8NJ43r6gk+Aqg@mail.gmail.com>
	<CAPNq5va7BGjPzYU+sQncvvQkXrqBFhEaZ_MEGs1EDyiN1CAAGQ@mail.gmail.com>
Message-ID: <CAC_FVB5aGGT6bBP7ZOt55W7w484tiOiwGoUhxJKyqfu3B0hrmw@mail.gmail.com>

Hi J?r?me!

Thanks so much for the details!

Perhaps the issue when uploading was actually the other issue I stumbled
upon in this endeavor! When attempting to upload the keycloak sp metadata
to testshib.org, I received a malformed metadata error, the testshib.org
folks noted that the SingleLogoutService element must come before the
NameID element (they also suggested to remove the newline&whitespace from
NameID, which existed in my keycloak sp metadata).

Once I modified those I was able to upload at least.  I suppose the
ordering/newline issues may be a fixable issue for keycloak.

As for the signing issue, I think I'll give up on using the testshib
instance (I did try to re-upload with your authn suggestion after fixing
the SingleLogoutService and NameID issues I mentioned above) and did
receive an invalid metadata error.  I appreciate your help though, and I'm
sure that integrating with a univ IdP as I intend to will be a bit easier!


On Thu, Feb 11, 2016 at 3:20 AM J?r?me Blanchard <jayblanc at gmail.com> wrote:

> I'm able to reproduce your bug.
> Making authentication using debug mode a break point in
> AssertionUtil.getAssertion() show that the IdP refuse to use unencrypted
> response :
>
> StatusType [statusCode=StatusCodeType
> [value=urn:oasis:names:tc:SAML:2.0:status:Responder, statusCode=null],
> statusMessage=Unable to encrypt assertion, statusDetail=null]
>
> By the way, when I try to use the Want AuthnRequests Signed= true, I can't
> upload the configuration to the testshib site because it considere the file
> as not wellformed !!
>
> I'm sorry, but it seems that the configuration os the testshib is very
> well coupled to shibboleth... Maybe you could try with your own instance of
> an IdP.
>
> Best regards, J?r?me.
>
> Le mer. 10 f?vr. 2016 ? 17:03, Steve Nolen <technolengy at gmail.com> a
> ?crit :
>
>> Hi J?r?me,
>>
>> Thanks for the help! I swapped the NameId in keycloak for this broker to
>> unspecified (I uploaded my sp metadata to testshib.org again as well
>> just in case) and am still receiving the same error.
>>
>> On Wed, Feb 10, 2016 at 1:10 AM J?r?me Blanchard <jayblanc at gmail.com>
>> wrote:
>>
>>> Hi Steve,
>>>
>>> I'm using Keycloak as a shibboleth SP in a federation (Renater) and It's
>>> working fine. The problem you encounter comes from the fact that you ask
>>> for a persistent nameId in the config of your SP and, according to the
>>> provider details, it's only able to send transient nameId.
>>> Feel the parameter of nameId to undefined and check the authentication
>>> again.
>>>
>>> Best regards, J?r?me.
>>>
>>> Le mer. 10 f?vr. 2016 ? 03:57, Steve Nolen <technolengy at gmail.com> a
>>> ?crit :
>>>
>>>> Hi!
>>>>
>>>> First of all, keycloak is legitimately awesome!
>>>>
>>>> I was attempting to test the use of keycloak as a shibboleth SP today
>>>> (testing against the testshib.org test IdP) and am having some trouble.
>>>>
>>>> Keycloak Version: 1.9.0CR1 (using it on openshift currently)
>>>>
>>>> Both sides seem to be set up as they should (I used the testshib
>>>> endpoint to import the settings to keycloak). I'm able to take the redirect
>>>> over to idp.testshib but on logging in I get a 500 Internal Server Error
>>>> from keycloak.  The message is "No Assertion from response" (stack trace
>>>> below).
>>>>
>>>> Any thoughts on what might be missing?
>>>>
>>>> ==== stack trace ====
>>>> http://pastebin.com/3tsApUKK
>>>>
>>>> ==== broker details ====
>>>>
>>>> https://keycloak-technolengy.rhcloud.com/auth/realms/technolengy/broker/testshib.org/endpoint/descriptor
>>>>
>>>> ==== provider details ====
>>>> https://www.testshib.org/metadata/testshib-providers.xml
>>>>
>>>> Thank you!
>>>> Steve
>>>>
>>> _______________________________________________
>>>> 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/20160211/bd8dd90c/attachment.html 

From jayblanc at gmail.com  Thu Feb 11 11:14:37 2016
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Thu, 11 Feb 2016 16:14:37 +0000
Subject: [keycloak-user] trouble acting as SP with testshib.org IdP
In-Reply-To: <CAC_FVB5aGGT6bBP7ZOt55W7w484tiOiwGoUhxJKyqfu3B0hrmw@mail.gmail.com>
References: <CAC_FVB7XdAzxSOCX4Dsq0gz4M+xiwChSiwdYjOhXqVLB7mREbQ@mail.gmail.com>
	<CAPNq5vbz4j5JGBP9S-FO4Pagy4402YSLJD2BkgN5Erecfxv0SQ@mail.gmail.com>
	<CAC_FVB6HywJ-2pxmXy8zTASwqO8KgTEajzbva8NJ43r6gk+Aqg@mail.gmail.com>
	<CAPNq5va7BGjPzYU+sQncvvQkXrqBFhEaZ_MEGs1EDyiN1CAAGQ@mail.gmail.com>
	<CAC_FVB5aGGT6bBP7ZOt55W7w484tiOiwGoUhxJKyqfu3B0hrmw@mail.gmail.com>
Message-ID: <CAPNq5vZL-WSOVzJCj4jAvB0CSnBWHCvENfBDNQijaQBxa+Xmmg@mail.gmail.com>

Hi Steve,

I spent some time in order to integrate into Renater federation (french
research shibbolet federation) because keycloak does not handle the
discovery service that parse the WAYF...
So I have develop a small apps to parse this file and synchronize my 250
IdP into keycloak !! I also customize the template in order to build a
choice list taking info from my discovery app.
Next step for me is to fork the saml provider of keycloak to built a
dedicated shibboleth one.
You probably faced some issues about transient nameid because shibboleth
federation does not give a persistent nameId but a transient one and
because keycloak need to associate the IdP/nameId to a real keycloak
account, transient nameid result in new account for each new shibboleth IdP
session...
You have to rely on an attribute eduPersonTargetedID but this attribute is
a complex type and keycloak SAML attribute parser can't handle it
correctly. I have make a small patch also to avoid problem with that and to
ensure the mapping between this attribute and the nameID.

By the way, I'm intrested if you succeed in order to share some tips and to
enlarge knowledge base about those aspects around Shibboleth and keycloak.

Best regards, J?r?me.

Le jeu. 11 f?vr. 2016 ? 17:04, Steve Nolen <technolengy at gmail.com> a ?crit :

> Hi J?r?me!
>
> Thanks so much for the details!
>
> Perhaps the issue when uploading was actually the other issue I stumbled
> upon in this endeavor! When attempting to upload the keycloak sp metadata
> to testshib.org, I received a malformed metadata error, the testshib.org
> folks noted that the SingleLogoutService element must come before the
> NameID element (they also suggested to remove the newline&whitespace from
> NameID, which existed in my keycloak sp metadata).
>
> Once I modified those I was able to upload at least.  I suppose the
> ordering/newline issues may be a fixable issue for keycloak.
>
> As for the signing issue, I think I'll give up on using the testshib
> instance (I did try to re-upload with your authn suggestion after fixing
> the SingleLogoutService and NameID issues I mentioned above) and did
> receive an invalid metadata error.  I appreciate your help though, and I'm
> sure that integrating with a univ IdP as I intend to will be a bit easier!
>
>
> On Thu, Feb 11, 2016 at 3:20 AM J?r?me Blanchard <jayblanc at gmail.com>
> wrote:
>
>> I'm able to reproduce your bug.
>> Making authentication using debug mode a break point in
>> AssertionUtil.getAssertion() show that the IdP refuse to use unencrypted
>> response :
>>
>> StatusType [statusCode=StatusCodeType
>> [value=urn:oasis:names:tc:SAML:2.0:status:Responder, statusCode=null],
>> statusMessage=Unable to encrypt assertion, statusDetail=null]
>>
>> By the way, when I try to use the Want AuthnRequests Signed= true, I
>> can't upload the configuration to the testshib site because it considere
>> the file as not wellformed !!
>>
>> I'm sorry, but it seems that the configuration os the testshib is very
>> well coupled to shibboleth... Maybe you could try with your own instance of
>> an IdP.
>>
>> Best regards, J?r?me.
>>
>> Le mer. 10 f?vr. 2016 ? 17:03, Steve Nolen <technolengy at gmail.com> a
>> ?crit :
>>
>>> Hi J?r?me,
>>>
>>> Thanks for the help! I swapped the NameId in keycloak for this broker to
>>> unspecified (I uploaded my sp metadata to testshib.org again as well
>>> just in case) and am still receiving the same error.
>>>
>>> On Wed, Feb 10, 2016 at 1:10 AM J?r?me Blanchard <jayblanc at gmail.com>
>>> wrote:
>>>
>>>> Hi Steve,
>>>>
>>>> I'm using Keycloak as a shibboleth SP in a federation (Renater) and
>>>> It's working fine. The problem you encounter comes from the fact that you
>>>> ask for a persistent nameId in the config of your SP and, according to the
>>>> provider details, it's only able to send transient nameId.
>>>> Feel the parameter of nameId to undefined and check the authentication
>>>> again.
>>>>
>>>> Best regards, J?r?me.
>>>>
>>>> Le mer. 10 f?vr. 2016 ? 03:57, Steve Nolen <technolengy at gmail.com> a
>>>> ?crit :
>>>>
>>>>> Hi!
>>>>>
>>>>> First of all, keycloak is legitimately awesome!
>>>>>
>>>>> I was attempting to test the use of keycloak as a shibboleth SP today
>>>>> (testing against the testshib.org test IdP) and am having some
>>>>> trouble.
>>>>>
>>>>> Keycloak Version: 1.9.0CR1 (using it on openshift currently)
>>>>>
>>>>> Both sides seem to be set up as they should (I used the testshib
>>>>> endpoint to import the settings to keycloak). I'm able to take the redirect
>>>>> over to idp.testshib but on logging in I get a 500 Internal Server Error
>>>>> from keycloak.  The message is "No Assertion from response" (stack trace
>>>>> below).
>>>>>
>>>>> Any thoughts on what might be missing?
>>>>>
>>>>> ==== stack trace ====
>>>>> http://pastebin.com/3tsApUKK
>>>>>
>>>>> ==== broker details ====
>>>>>
>>>>> https://keycloak-technolengy.rhcloud.com/auth/realms/technolengy/broker/testshib.org/endpoint/descriptor
>>>>>
>>>>> ==== provider details ====
>>>>> https://www.testshib.org/metadata/testshib-providers.xml
>>>>>
>>>>> Thank you!
>>>>> Steve
>>>>>
>>>> _______________________________________________
>>>>> 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/20160211/168882b0/attachment-0001.html 

From technolengy at gmail.com  Thu Feb 11 11:21:14 2016
From: technolengy at gmail.com (Steve Nolen)
Date: Thu, 11 Feb 2016 16:21:14 +0000
Subject: [keycloak-user] trouble acting as SP with testshib.org IdP
In-Reply-To: <CAPNq5vZL-WSOVzJCj4jAvB0CSnBWHCvENfBDNQijaQBxa+Xmmg@mail.gmail.com>
References: <CAC_FVB7XdAzxSOCX4Dsq0gz4M+xiwChSiwdYjOhXqVLB7mREbQ@mail.gmail.com>
	<CAPNq5vbz4j5JGBP9S-FO4Pagy4402YSLJD2BkgN5Erecfxv0SQ@mail.gmail.com>
	<CAC_FVB6HywJ-2pxmXy8zTASwqO8KgTEajzbva8NJ43r6gk+Aqg@mail.gmail.com>
	<CAPNq5va7BGjPzYU+sQncvvQkXrqBFhEaZ_MEGs1EDyiN1CAAGQ@mail.gmail.com>
	<CAC_FVB5aGGT6bBP7ZOt55W7w484tiOiwGoUhxJKyqfu3B0hrmw@mail.gmail.com>
	<CAPNq5vZL-WSOVzJCj4jAvB0CSnBWHCvENfBDNQijaQBxa+Xmmg@mail.gmail.com>
Message-ID: <CAC_FVB5GSSM_PGBYCWPUHy_SPJ_aO=z-yyy3O2WQ1-BLfGsCkA@mail.gmail.com>

Sounds like you've got quite some experience with this!! I would certainly
be happy to share any steps/procedure I use when I'm successful!

> Next step for me is to fork the saml provider of keycloak to built a
dedicated shibboleth one.
This is good news as well.  I've noticed that a very large percentage of
people creating SPs for shibboleth tend to use the standard shibd/apache
setup so as to avoid touching shibboleth as much as possible.  It would be
fantastic to be able use keycloak in place of that where possible!

On Thu, Feb 11, 2016 at 8:14 AM J?r?me Blanchard <jayblanc at gmail.com> wrote:

> Hi Steve,
>
> I spent some time in order to integrate into Renater federation (french
> research shibbolet federation) because keycloak does not handle the
> discovery service that parse the WAYF...
> So I have develop a small apps to parse this file and synchronize my 250
> IdP into keycloak !! I also customize the template in order to build a
> choice list taking info from my discovery app.
> Next step for me is to fork the saml provider of keycloak to built a
> dedicated shibboleth one.
> You probably faced some issues about transient nameid because shibboleth
> federation does not give a persistent nameId but a transient one and
> because keycloak need to associate the IdP/nameId to a real keycloak
> account, transient nameid result in new account for each new shibboleth IdP
> session...
> You have to rely on an attribute eduPersonTargetedID but this attribute is
> a complex type and keycloak SAML attribute parser can't handle it
> correctly. I have make a small patch also to avoid problem with that and to
> ensure the mapping between this attribute and the nameID.
>
> By the way, I'm intrested if you succeed in order to share some tips and
> to enlarge knowledge base about those aspects around Shibboleth and
> keycloak.
>
> Best regards, J?r?me.
>
> Le jeu. 11 f?vr. 2016 ? 17:04, Steve Nolen <technolengy at gmail.com> a
> ?crit :
>
>> Hi J?r?me!
>>
>> Thanks so much for the details!
>>
>> Perhaps the issue when uploading was actually the other issue I stumbled
>> upon in this endeavor! When attempting to upload the keycloak sp metadata
>> to testshib.org, I received a malformed metadata error, the testshib.org
>> folks noted that the SingleLogoutService element must come before the
>> NameID element (they also suggested to remove the newline&whitespace from
>> NameID, which existed in my keycloak sp metadata).
>>
>> Once I modified those I was able to upload at least.  I suppose the
>> ordering/newline issues may be a fixable issue for keycloak.
>>
>> As for the signing issue, I think I'll give up on using the testshib
>> instance (I did try to re-upload with your authn suggestion after fixing
>> the SingleLogoutService and NameID issues I mentioned above) and did
>> receive an invalid metadata error.  I appreciate your help though, and I'm
>> sure that integrating with a univ IdP as I intend to will be a bit easier!
>>
>>
>> On Thu, Feb 11, 2016 at 3:20 AM J?r?me Blanchard <jayblanc at gmail.com>
>> wrote:
>>
>>> I'm able to reproduce your bug.
>>> Making authentication using debug mode a break point in
>>> AssertionUtil.getAssertion() show that the IdP refuse to use unencrypted
>>> response :
>>>
>>> StatusType [statusCode=StatusCodeType
>>> [value=urn:oasis:names:tc:SAML:2.0:status:Responder, statusCode=null],
>>> statusMessage=Unable to encrypt assertion, statusDetail=null]
>>>
>>> By the way, when I try to use the Want AuthnRequests Signed= true, I
>>> can't upload the configuration to the testshib site because it considere
>>> the file as not wellformed !!
>>>
>>> I'm sorry, but it seems that the configuration os the testshib is very
>>> well coupled to shibboleth... Maybe you could try with your own instance of
>>> an IdP.
>>>
>>> Best regards, J?r?me.
>>>
>>> Le mer. 10 f?vr. 2016 ? 17:03, Steve Nolen <technolengy at gmail.com> a
>>> ?crit :
>>>
>>>> Hi J?r?me,
>>>>
>>>> Thanks for the help! I swapped the NameId in keycloak for this broker
>>>> to unspecified (I uploaded my sp metadata to testshib.org again as
>>>> well just in case) and am still receiving the same error.
>>>>
>>>> On Wed, Feb 10, 2016 at 1:10 AM J?r?me Blanchard <jayblanc at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Steve,
>>>>>
>>>>> I'm using Keycloak as a shibboleth SP in a federation (Renater) and
>>>>> It's working fine. The problem you encounter comes from the fact that you
>>>>> ask for a persistent nameId in the config of your SP and, according to the
>>>>> provider details, it's only able to send transient nameId.
>>>>> Feel the parameter of nameId to undefined and check the authentication
>>>>> again.
>>>>>
>>>>> Best regards, J?r?me.
>>>>>
>>>>> Le mer. 10 f?vr. 2016 ? 03:57, Steve Nolen <technolengy at gmail.com> a
>>>>> ?crit :
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> First of all, keycloak is legitimately awesome!
>>>>>>
>>>>>> I was attempting to test the use of keycloak as a shibboleth SP today
>>>>>> (testing against the testshib.org test IdP) and am having some
>>>>>> trouble.
>>>>>>
>>>>>> Keycloak Version: 1.9.0CR1 (using it on openshift currently)
>>>>>>
>>>>>> Both sides seem to be set up as they should (I used the testshib
>>>>>> endpoint to import the settings to keycloak). I'm able to take the redirect
>>>>>> over to idp.testshib but on logging in I get a 500 Internal Server Error
>>>>>> from keycloak.  The message is "No Assertion from response" (stack trace
>>>>>> below).
>>>>>>
>>>>>> Any thoughts on what might be missing?
>>>>>>
>>>>>> ==== stack trace ====
>>>>>> http://pastebin.com/3tsApUKK
>>>>>>
>>>>>> ==== broker details ====
>>>>>>
>>>>>> https://keycloak-technolengy.rhcloud.com/auth/realms/technolengy/broker/testshib.org/endpoint/descriptor
>>>>>>
>>>>>> ==== provider details ====
>>>>>> https://www.testshib.org/metadata/testshib-providers.xml
>>>>>>
>>>>>> Thank you!
>>>>>> Steve
>>>>>>
>>>>> _______________________________________________
>>>>>> 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/20160211/85e4d8cc/attachment.html 

From srossillo at smartling.com  Thu Feb 11 11:51:54 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Thu, 11 Feb 2016 11:51:54 -0500
Subject: [keycloak-user] User-Federation
In-Reply-To: <81B2EA95-4A60-4992-ADF0-17AD754D1E46@carbonite.com>
References: <CADW1CM8kNr=WkTSm4jp_BZm4Bdm6JSJhSLgPvhLQxDSmrC653A@mail.gmail.com>
	<E4193CB0-4921-45BD-AA73-8BA39AF8D3C0@carbonite.com>
	<CAEBys6KM1-n6wFqTJAAqb_aYaQdZwuiaUz2AspF5d-8Za=E9wQ@mail.gmail.com>
	<CAEBys6+i6jFdycaCg-rf9vC=T7chbrkKeWsfAbNvC2tidKdhZw@mail.gmail.com>
	<81B2EA95-4A60-4992-ADF0-17AD754D1E46@carbonite.com>
Message-ID: <4B71E2D9-755C-40C4-8C4B-DC516C9CF11E@smartling.com>

Hi,

The example omits securing the endpoints for simplicity demonstrating the concepts. I?d suggest using some type of security though on the legacy system if the endpoints are publicly accessible though.

Best,
Scott

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Feb 11, 2016, at 9:35 AM, Reed Lewis <RLewis at carbonite.com> wrote:
> 
> The endpoint that is used by the federation provider is only called from Keycloak, so you can run it on localhost on the keycloak machine if that is going to work for you.
> 
> OTOH, if you need to run it on a different machine, you can lock down the endpoint to only be accessible from the Keycloak server.
> 
> End users never call the endpoint I documented.
> 
> Reed
> 
> From: <darkness.renann at gmail.com <mailto:darkness.renann at gmail.com>> on behalf of Renann Prado <prado.renann at gmail.com <mailto:prado.renann at gmail.com>>
> Date: Thursday, February 11, 2016 at 8:17 AM
> To: Reed Lewis <RLewis at carbonite.com <mailto:RLewis at carbonite.com>>
> Cc: "keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>>, Stuart Jacobs <stuart.jacobs at symbiotics.co.za <mailto:stuart.jacobs at symbiotics.co.za>>
> Subject: Re: [keycloak-user] User-Federation
> 
> Everyone*
> 
> On Feb 11, 2016 11:16, "Renann Prado" <prado.renann at gmail.com <mailto:prado.renann at gmail.com>> wrote:
> Is there any recommended way to make sure these endpoints won't be spammed by an attacker? Looks like these endpoints need to be open to anyone.
> 
> Thanks
> 
> On Feb 3, 2016 11:18, "Reed Lewis" <RLewis at carbonite.com <mailto:RLewis at carbonite.com>> wrote:
> If you use the federation provider listed here:
> 
> [0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/ <http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/>
> [1]: https://github.com/Smartling/keycloak-user-migration-provider <https://github.com/Smartling/keycloak-user-migration-provider>
> 
> You can specify a URL that will be called when a user needs to be validated.
> 
> There are three requests that need to be implemented in your sever.
> 
> GET <baseURL>/api/users/<username>/
> If the user exists, it should return a 200 with a json object with the return type ?application/json? with the following fields:
> username
> email
> emailVerified
> firstName
> lastName
> roles [?user?]
> 
> If the user does not exist, return a 404 
> 
> HEAD <baseURL>/api/users/<username>/
> Always return 200
> 
> POST <baseURL>/api/users/<username>/
> The password is posted to you in a json object.
> Return 200 if the password is OK, 401 if not.  In both cases return no data.
> 
> I wrote a small python module which implements these methods which works quite well.
> 
> Reed
> 
> From: <keycloak-user-bounces at lists.jboss.org <mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Stuart Jacobs <stuart.jacobs at symbiotics.co.za <mailto:stuart.jacobs at symbiotics.co.za>>
> Date: Wednesday, February 3, 2016 at 2:40 AM
> To: "keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>>
> Subject: [keycloak-user] User-Federation
> 
> Hi Everyone,
> 
> I have an application that runs on a postgresql database, keycloak has been configured and has created all the required tables/columns in my schema using liquibase on start up of the keycloak server.
> 
> I need to authenticate users using the projects existing user table obtaining the username and password from this table.
> 
> I have had a look at the federation provider project under the example projects but this still eludes me as to how I change the keycloak mapping to use my own tables in postgress?
> 
> Can someone please point me in the right direction or if someone has implemented such a solution please share how you have done it?
> 
> Thanks everyone. 
> 
>   Regards,
>   Stuart Jacobs
> 
> 
> 
> 
> 
> 
> 
> www.symbiotics.co.za <http://www.symbiotics.co.za/>
> ********************************************************************************
> This email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited. 
> 
> Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient. 
> 
> ********************************************************************************
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user <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/20160211/25c7c0e5/attachment-0001.html 

From bburke at redhat.com  Thu Feb 11 11:57:02 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 11 Feb 2016 11:57:02 -0500
Subject: [keycloak-user] trouble acting as SP with testshib.org IdP
In-Reply-To: <CAC_FVB5GSSM_PGBYCWPUHy_SPJ_aO=z-yyy3O2WQ1-BLfGsCkA@mail.gmail.com>
References: <CAC_FVB7XdAzxSOCX4Dsq0gz4M+xiwChSiwdYjOhXqVLB7mREbQ@mail.gmail.com>
	<CAPNq5vbz4j5JGBP9S-FO4Pagy4402YSLJD2BkgN5Erecfxv0SQ@mail.gmail.com>
	<CAC_FVB6HywJ-2pxmXy8zTASwqO8KgTEajzbva8NJ43r6gk+Aqg@mail.gmail.com>
	<CAPNq5va7BGjPzYU+sQncvvQkXrqBFhEaZ_MEGs1EDyiN1CAAGQ@mail.gmail.com>
	<CAC_FVB5aGGT6bBP7ZOt55W7w484tiOiwGoUhxJKyqfu3B0hrmw@mail.gmail.com>
	<CAPNq5vZL-WSOVzJCj4jAvB0CSnBWHCvENfBDNQijaQBxa+Xmmg@mail.gmail.com>
	<CAC_FVB5GSSM_PGBYCWPUHy_SPJ_aO=z-yyy3O2WQ1-BLfGsCkA@mail.gmail.com>
Message-ID: <56BCBD5E.7010704@redhat.com>

Just create a detailed jira on how we can make this easier.

On 2/11/2016 11:21 AM, Steve Nolen wrote:
> Sounds like you've got quite some experience with this!! I would 
> certainly be happy to share any steps/procedure I use when I'm 
> successful!
>
> > Next step for me is to fork the saml provider of keycloak to built a dedicated shibboleth one.
> This is good news as well. I've noticed that a very large percentage 
> of people creating SPs for shibboleth tend to use the standard 
> shibd/apache setup so as to avoid touching shibboleth as much as 
> possible.  It would be fantastic to be able use keycloak in place of 
> that where possible!
>
> On Thu, Feb 11, 2016 at 8:14 AM J?r?me Blanchard <jayblanc at gmail.com 
> <mailto:jayblanc at gmail.com>> wrote:
>
>     Hi Steve,
>
>     I spent some time in order to integrate into Renater federation
>     (french research shibbolet federation) because keycloak does not
>     handle the discovery service that parse the WAYF...
>     So I have develop a small apps to parse this file and synchronize
>     my 250 IdP into keycloak !! I also customize the template in order
>     to build a choice list taking info from my discovery app.
>     Next step for me is to fork the saml provider of keycloak to built
>     a dedicated shibboleth one.
>     You probably faced some issues about transient nameid because
>     shibboleth federation does not give a persistent nameId but a
>     transient one and because keycloak need to associate the
>     IdP/nameId to a real keycloak account, transient nameid result in
>     new account for each new shibboleth IdP session...
>     You have to rely on an attribute eduPersonTargetedID but this
>     attribute is a complex type and keycloak SAML attribute parser
>     can't handle it correctly. I have make a small patch also to avoid
>     problem with that and to ensure the mapping between this attribute
>     and the nameID.
>
>     By the way, I'm intrested if you succeed in order to share some
>     tips and to enlarge knowledge base about those aspects around
>     Shibboleth and keycloak.
>
>     Best regards, J?r?me.
>
>     Le jeu. 11 f?vr. 2016 ? 17:04, Steve Nolen <technolengy at gmail.com
>     <mailto:technolengy at gmail.com>> a ?crit :
>
>         Hi J?r?me!
>
>         Thanks so much for the details!
>
>         Perhaps the issue when uploading was actually the other issue
>         I stumbled upon in this endeavor! When attempting to upload
>         the keycloak sp metadata to testshib.org
>         <http://testshib.org>, I received a malformed metadata error,
>         the testshib.org <http://testshib.org> folks noted that the
>         SingleLogoutService element must come before the NameID
>         element (they also suggested to remove the newline&whitespace
>         from NameID, which existed in my keycloak sp metadata).
>
>         Once I modified those I was able to upload at least.  I
>         suppose the ordering/newline issues may be a fixable issue for
>         keycloak.
>
>         As for the signing issue, I think I'll give up on using the
>         testshib instance (I did try to re-upload with your authn
>         suggestion after fixing the SingleLogoutService and NameID
>         issues I mentioned above) and did receive an invalid metadata
>         error.  I appreciate your help though, and I'm sure that
>         integrating with a univ IdP as I intend to will be a bit easier!
>
>
>         On Thu, Feb 11, 2016 at 3:20 AM J?r?me Blanchard
>         <jayblanc at gmail.com <mailto:jayblanc at gmail.com>> wrote:
>
>             I'm able to reproduce your bug.
>             Making authentication using debug mode a break point in
>             AssertionUtil.getAssertion() show that the IdP refuse to
>             use unencrypted response :
>
>             StatusType [statusCode=StatusCodeType
>             [value=urn:oasis:names:tc:SAML:2.0:status:Responder,
>             statusCode=null], statusMessage=Unable to encrypt
>             assertion, statusDetail=null]
>
>             By the way, when I try to use the Want AuthnRequests
>             Signed= true, I can't upload the configuration to the
>             testshib site because it considere the file as not
>             wellformed !!
>
>             I'm sorry, but it seems that the configuration os the
>             testshib is very well coupled to shibboleth... Maybe you
>             could try with your own instance of an IdP.
>
>             Best regards, J?r?me.
>
>             Le mer. 10 f?vr. 2016 ? 17:03, Steve Nolen
>             <technolengy at gmail.com <mailto:technolengy at gmail.com>> a
>             ?crit :
>
>                 Hi J?r?me,
>
>                 Thanks for the help! I swapped the NameId in keycloak
>                 for this broker to unspecified (I uploaded my sp
>                 metadata to testshib.org <http://testshib.org> again
>                 as well just in case) and am still receiving the same
>                 error.
>
>                 On Wed, Feb 10, 2016 at 1:10 AM J?r?me Blanchard
>                 <jayblanc at gmail.com <mailto:jayblanc at gmail.com>> wrote:
>
>                     Hi Steve,
>
>                     I'm using Keycloak as a shibboleth SP in a
>                     federation (Renater) and It's working fine. The
>                     problem you encounter comes from the fact that you
>                     ask for a persistent nameId in the config of your
>                     SP and, according to the provider details, it's
>                     only able to send transient nameId.
>                     Feel the parameter of nameId to undefined and
>                     check the authentication again.
>
>                     Best regards, J?r?me.
>
>                     Le mer. 10 f?vr. 2016 ? 03:57, Steve Nolen
>                     <technolengy at gmail.com
>                     <mailto:technolengy at gmail.com>> a ?crit :
>
>                         Hi!
>
>                         First of all, keycloak is legitimately awesome!
>
>                         I was attempting to test the use of keycloak
>                         as a shibboleth SP today (testing against the
>                         testshib.org <http://testshib.org> test IdP)
>                         and am having some trouble.
>
>                         Keycloak Version: 1.9.0CR1 (using it on
>                         openshift currently)
>
>                         Both sides seem to be set up as they should (I
>                         used the testshib endpoint to import the
>                         settings to keycloak). I'm able to take the
>                         redirect over to idp.testshib but on logging
>                         in I get a 500 Internal Server Error from
>                         keycloak.  The message is "No Assertion from
>                         response" (stack trace below).
>
>                         Any thoughts on what might be missing?
>
>                         ==== stack trace ====
>                         http://pastebin.com/3tsApUKK
>
>                         ==== broker details ====
>                         https://keycloak-technolengy.rhcloud.com/auth/realms/technolengy/broker/testshib.org/endpoint/descriptor
>
>                         ==== provider details ====
>                         https://www.testshib.org/metadata/testshib-providers.xml
>
>                         Thank you!
>                         Steve
>
>                         _______________________________________________
>                         keycloak-user mailing list
>                         keycloak-user at lists.jboss.org
>                         <mailto:keycloak-user at lists.jboss.org>
>                         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/15f08aeb/attachment-0001.html 

From akaya at expedia.com  Fri Feb 12 01:08:16 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Fri, 12 Feb 2016 06:08:16 +0000
Subject: [keycloak-user] Extending Themes via SPI
Message-ID: <D2E3B3EF.2772%akaya@expedia.com>

Hi all,

In regards to Extending Themes via SPI all I found is this documentation:
http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html and
<http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450>
http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450
I found it a little less describing.

When I implement those two classes, where do I put the new implemented classes? How do I deploy them?
Can I also use Spring mvc and JSP and few maven dependencies instead of freemarker?

I also tried to find an example to extend theme using SPI but there seems to be none. It would be really nice if you could provide a sample hello world.

Thank you very much,
Sarp Kaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/851f029d/attachment.html 

From mposolda at redhat.com  Fri Feb 12 02:07:05 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Feb 2016 08:07:05 +0100
Subject: [keycloak-user] Failed to make identity provider oauth
 callback: javax.net.ssl.SSLHandshakeException
In-Reply-To: <CAJgngAfV0HFHT=_rBYe0XQHNeBwKTTrm10gUU=xd24=pAq2KvQ@mail.gmail.com>
References: <D2E21C82.26535%leo.nunes@ojc.com.br>
	<CAJgngAfV0HFHT=_rBYe0XQHNeBwKTTrm10gUU=xd24=pAq2KvQ@mail.gmail.com>
Message-ID: <56BD8499.4060007@redhat.com>

Facebook certificate should be signed by trusted authority, so it works 
with default JDK truststore. At least for me it always works.

Shouldn't truststore SPI use both provided file + default JDK truststore 
by default? We may have flag to disable default JDK truststore, but not 
sure if it's ever needed. Also shouldn't we rewrite SimpleHTTP to use 
Apache HTTP client provided by HttpClientProvider SPI?

Marek

On 11/02/16 15:23, Stian Thorgersen wrote:
> Does it work if you don't specify the truststore? That will use the 
> default truststore provided by the JDK.
>
> Also, does your truststore contain the required CA certs? For Facebook 
> to work it'll have to contain the required CA's for their certs
>
> On 11 February 2016 at 14:09, LEONARDO NUNES <leo.nunes at gjccorp.com.br 
> <mailto:leo.nunes at gjccorp.com.br>> wrote:
>
>     Hi, i'm getting the error below when I try to login with Facebook.
>     I've followed the instructions at
>     http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore and
>     http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337
>
>     I was able to login with Facebook when trying at localhost. But at
>     our development server we are getting this error.
>
>     We are using EAP in domain mode.
>
>     The truststore I placed inside of keycloak-server.json
>     "truststore": {
>             "file": {
>                 "file": "/home/soa/jboss/ssl/keycloak.jks",
>                 "password": "keycloak123",
>                 "hostname-verification-policy": "ANY",
>                 "disabled": false
>             }
>         }
>
>
>     #######
>
>     ERRO:
>
>
>     2016-02-11 10:44:53,927 ERROR
>     [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider]
>     (ajp-/192.168.162.73:8008-1) Failed to make identity provider
>     oauth callback: javax.net.ssl.SSLHandshakeException:
>     sun.security.validator.ValidatorException: PKIX path building
>     failed:
>     sun.security.provider.certpath.SunCertPathBuilderException: unable
>     to find valid certification path to requested target
>     at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>     [jsse.jar:1.8.0_45]
>     at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
>     [jsse.jar:1.8.0_45]
>     at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>     [jsse.jar:1.8.0_45]
>     at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>     [jsse.jar:1.8.0_45]
>     at
>     sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
>     [jsse.jar:1.8.0_45]
>     at
>     sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
>     [jsse.jar:1.8.0_45]
>     at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
>     [jsse.jar:1.8.0_45]
>     at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
>     [jsse.jar:1.8.0_45]
>     at
>     sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
>     [jsse.jar:1.8.0_45]
>     at
>     sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
>     [jsse.jar:1.8.0_45]
>     at
>     sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
>     [jsse.jar:1.8.0_45]
>     at
>     sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
>     [jsse.jar:1.8.0_45]
>     at
>     sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
>     [rt.jar:1.8.0_45]
>     at
>     sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>     [rt.jar:1.8.0_45]
>     at
>     sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282)
>     [rt.jar:1.8.0_45]
>     at
>     sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257)
>     [rt.jar:1.8.0_45]
>     at
>     sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
>     [rt.jar:1.8.0_45]
>     at
>     org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
>     at
>     org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     [rt.jar:1.8.0_45]
>     at
>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     [rt.jar:1.8.0_45]
>     at
>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     [rt.jar:1.8.0_45]
>     at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
>     at
>     org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at
>     org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
>     [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>     [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
>     at
>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>     [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
>     at
>     org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
>     at
>     org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
>     at
>     org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
>     [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
>     at
>     org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at
>     org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
>     [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>     at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
>     Caused by: sun.security.validator.ValidatorException: PKIX path
>     building failed:
>     sun.security.provider.certpath.SunCertPathBuilderException: unable
>     to find valid certification path to requested target
>     at
>     sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
>     [rt.jar:1.8.0_45]
>     at
>     sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
>     [rt.jar:1.8.0_45]
>     at sun.security.validator.Validator.validate(Validator.java:260)
>     [rt.jar:1.8.0_45]
>     at
>     sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>     [jsse.jar:1.8.0_45]
>     at
>     sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>     [jsse.jar:1.8.0_45]
>     at
>     sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
>     [jsse.jar:1.8.0_45]
>     at
>     sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
>     [jsse.jar:1.8.0_45]
>     ... 50 more
>     Caused by:
>     sun.security.provider.certpath.SunCertPathBuilderException: unable
>     to find valid certification path to requested target
>     at
>     sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
>     [rt.jar:1.8.0_45]
>     at
>     sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
>     [rt.jar:1.8.0_45]
>     at
>     java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>     [rt.jar:1.8.0_45]
>     at
>     sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
>     [rt.jar:1.8.0_45]
>     ... 56 more
>
>
>
>
>
>     -- 
>     Leonardo Nunes
>     ------------------------------------------------------------------------
>     /Esta mensagem pode conter informa??o confidencial e/ou
>     privilegiada. Se voc? n?o for o destinat?rio ou a pessoa
>     autorizada a receber esta mensagem, n?o poder? usar, copiar ou
>     divulgar as informa??es nela contidas ou tomar qualquer a??o
>     baseada nessas informa??es. Se voc? recebeu esta mensagem por
>     engano, por favor avise imediatamente o remetente, respondendo o
>     e-mail e em seguida apague-o. Agradecemos sua coopera??o.
>
>     This message may contain confidential and/or privileged
>     information. If you are not the addressee or authorized to receive
>     this for the addressee, you must not use, copy, disclose or take
>     any action based on this message or any information herein. If you
>     have received this message in error, please advise the sender
>     immediately by reply e-mail and delete this message. Thank you for
>     your cooperation/
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/311f1688/attachment-0001.html 

From michael.anthon at infoview.com.au  Fri Feb 12 02:44:22 2016
From: michael.anthon at infoview.com.au (Michael Anthon)
Date: Fri, 12 Feb 2016 07:44:22 +0000
Subject: [keycloak-user] Issues with password reset link expiration
In-Reply-To: <e2031b62eb4f4212b440b371f09b430d@HsteqMX04.nexonhosted.local>
References: <e3c4dce4db8649958379bf11260f79d1@HsteqMX04.nexonhosted.local>
	<CAJgngAdk_iN2vcR0i5t-3wriOe3xgQWAxPGWf1_D3sR62_s8JQ@mail.gmail.com>
	<56BB40F0.1080204@redhat.com>
	<CAJgngAfiUdD6TJviSRf3j8erStY3atLzk3ygFEXCgwst+wnu-Q@mail.gmail.com>
	<56BB4614.8090509@redhat.com>
	<CAJgngAd3NNYUXRaWYnf7rpKFxMzCLvVHGVXrmvjMUUxzFz2RzQ@mail.gmail.com>
	<e2031b62eb4f4212b440b371f09b430d@HsteqMX04.nexonhosted.local>
Message-ID: <9e3ecfb853ce42809eb3db603544d406@HsteqMX04.nexonhosted.local>

We have verified that the behavior is correct in 1.9.0.CR1.

Cheers,
Michael

From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Michael Anthon
Sent: Thursday, 11 February 2016 2:42 PM
To: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Issues with password reset link expiration

Thanks for the replies, I forgot to mention we are currently on 1.6.1.Final however we do have a test setup where we can run an upgrade and check this out.

Will try that and report back and/or create a ticket as required.

Cheers,
Michael

From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: Thursday, 11 February 2016 12:26 AM
To: Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>>; Michael Anthon <michael.anthon at infoview.com.au<mailto:michael.anthon at infoview.com.au>>
Cc: keycloak-user <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Issues with password reset link expiration

Michael,

Can you confirm if this issue still exists on 1.9.0.CR1 and if it does create a JIRA issue?

On 10 February 2016 at 15:15, Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>> wrote:
I think this may have been fixed in 1.9 with the flow changes I made.  I don't have time to try it out right now though.

On 2/10/2016 8:58 AM, Stian Thorgersen wrote:
It's not about the error message though. It should be possible to open the link multiple times as long as the form is not submitted.

On 10 February 2016 at 14:53, Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>> wrote:
We changed the "error" message in I think 1.9?  Maybe 1.8 to say "You clicked on a stale link.  Maybe you have already verified your email?"  I'll look into improving this I guess.

On 2/10/2016 4:21 AM, Stian Thorgersen wrote:
It should be possible to open the link multiple times, but only submit the password reset once. If that's not the case (sounds like it is) feel free to create a JIRA issue to report this as a bug.

On 10 February 2016 at 05:24, Michael Anthon <michael.anthon at infoview.com.au<mailto:michael.anthon at infoview.com.au>> wrote:
We are having issues with some users when they are attempting to use the password reset feature.  It does work for most users however for some they always end up at an error page saying "WE'RE SORRY ... An error occurred, please login again through your application"

What I have been able to determine so far is that for the affected users we are seeing a double hit on that URL in the server logs and from what I understand, these reset URLs are invalidated as soon as they are accessed.

So here's the state of play
* works for most users
* some users hitting the reset URL twice
* URL is only valid for the first access (I'm not 100% sure about this, can someone confirm please?)
* URL is only valid for 30 minutes (but is being accessed within a few minutes of generation)
* affected users are mostly using Outlook
* some people tend to double click links in emails but I've verified with a reliable user that they are only clicking the link once
* having the affected person send themselves another reset email and then copy and paste the URL from the mail client usually resolves this problem

And questions
* is this an issue anyone else has noticed with Outlook, doesn't affect ALL Outlook users, just some
* is there a way to prevent the URL from being invalidated on initial access
* is it feasible to change the behavior so that the URL is only invalidated when the password is changed
* any other thoughts on how to avoid this issue?

Thanks and Regards,

Michael Anthon
InfoView Technologies Pty Ltd
12/15 Adelaide St, Brisbane Qld 4000
P O Box 15478, City East, Brisbane Qld 4000
PH:          +61 7 3014 2204<tel:%2B61%207%203014%202204>
F:             +61 7 3014 2200<tel:%2B61%207%203014%202200>
M:           +61 408 768 055<tel:%2B61%20408%20768%20055>
michael.anthon at infoview.com.au<mailto:michael.anthon at infoview.com.au>

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of InfoView Technologies Pty Ltd.


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



_______________________________________________

keycloak-user mailing list

keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>

https://lists.jboss.org/mailman/listinfo/keycloak-user


--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com

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



--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/72610803/attachment.html 

From sthorger at redhat.com  Fri Feb 12 02:54:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 08:54:29 +0100
Subject: [keycloak-user] Extending Themes via SPI
In-Reply-To: <D2E3B3EF.2772%akaya@expedia.com>
References: <D2E3B3EF.2772%akaya@expedia.com>
Message-ID: <CAJgngAen9zYDj2XzcNQk4D6YRDb-jhxRXab9WcaFd-CEX8R6Yg@mail.gmail.com>

What are you actually trying to achieve? We mainly support modifying the
FreeMarker templates and stylesheets. Beyond that you may in theory be able
to re-implement it all to replace FreeMarker with something else, but I
don't see why you would want to and it would be a significant amount of
work, and also maintenance.

On 12 February 2016 at 07:08, Sarp Kaya <akaya at expedia.com> wrote:

> Hi all,
>
> In regards to Extending Themes via SPI all I found is this documentation:
>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html
>  and
>
> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450>
>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450
> I found it a little less describing.
>
> When I implement those two classes, where do I put the new implemented
> classes? How do I deploy them?
> Can I also use Spring mvc and JSP and few maven dependencies instead of
> freemarker?
>
> I also tried to find an example to extend theme using SPI but there seems
> to be none. It would be really nice if you could provide a sample hello
> world.
>
> Thank you very much,
> Sarp Kaya
>
> _______________________________________________
> 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/20160212/23596dbf/attachment-0001.html 

From sthorger at redhat.com  Fri Feb 12 02:56:01 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 08:56:01 +0100
Subject: [keycloak-user] Failed to make identity provider oauth
	callback: javax.net.ssl.SSLHandshakeException
In-Reply-To: <56BD8499.4060007@redhat.com>
References: <D2E21C82.26535%leo.nunes@ojc.com.br>
	<CAJgngAfV0HFHT=_rBYe0XQHNeBwKTTrm10gUU=xd24=pAq2KvQ@mail.gmail.com>
	<56BD8499.4060007@redhat.com>
Message-ID: <CAJgngAfNQCxrAiQCod7bFEpYeQtzfxcDcv=GJQB0YMKFW=+EYQ@mail.gmail.com>

On 12 February 2016 at 08:07, Marek Posolda <mposolda at redhat.com> wrote:

> Facebook certificate should be signed by trusted authority, so it works
> with default JDK truststore. At least for me it always works.
>
> Shouldn't truststore SPI use both provided file + default JDK truststore
> by default? We may have flag to disable default JDK truststore, but not
> sure if it's ever needed. Also shouldn't we rewrite SimpleHTTP to use
> Apache HTTP client provided by HttpClientProvider SPI?
>

+1 To both

SimpleHTTP was only introduced when we where talking about having the
social providers a generic library, but now they aren't there's no point to
SimpleHTTP anymore.


>
>
> Marek
>
>
> On 11/02/16 15:23, Stian Thorgersen wrote:
>
> Does it work if you don't specify the truststore? That will use the
> default truststore provided by the JDK.
>
> Also, does your truststore contain the required CA certs? For Facebook to
> work it'll have to contain the required CA's for their certs
>
> On 11 February 2016 at 14:09, LEONARDO NUNES <leo.nunes at gjccorp.com.br>
> wrote:
>
>> Hi, i'm getting the error below when I try to login with Facebook.
>> I've followed the instructions at
>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore>
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore
>>  and
>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337>
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337
>>
>> I was able to login with Facebook when trying at localhost. But at our
>> development server we are getting this error.
>>
>> We are using EAP in domain mode.
>>
>> The truststore I placed inside of keycloak-server.json
>> "truststore": {
>>         "file": {
>>             "file": "/home/soa/jboss/ssl/keycloak.jks",
>>             "password": "keycloak123",
>>             "hostname-verification-policy": "ANY",
>>             "disabled": false
>>         }
>>     }
>>
>>
>> #######
>>
>> ERRO:
>>
>>
>> 2016-02-11 10:44:53,927 ERROR
>> [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider]
>> (ajp-/192.168.162.73:8008-1) Failed to make identity provider oauth
>> callback: javax.net.ssl.SSLHandshakeException:
>> sun.security.validator.ValidatorException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
>> valid certification path to requested target
>> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
>> [rt.jar:1.8.0_45]
>> at
>> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
>> at
>> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [rt.jar:1.8.0_45]
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> [rt.jar:1.8.0_45]
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.8.0_45]
>> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
>> at
>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
>> at
>> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
>> at
>> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
>> [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
>> Caused by: sun.security.validator.ValidatorException: PKIX path building
>> failed: sun.security.provider.certpath.SunCertPathBuilderException: unable
>> to find valid certification path to requested target
>> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
>> [rt.jar:1.8.0_45]
>> at
>> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
>> [rt.jar:1.8.0_45]
>> at sun.security.validator.Validator.validate(Validator.java:260)
>> [rt.jar:1.8.0_45]
>> at
>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
>> [jsse.jar:1.8.0_45]
>> ... 50 more
>> Caused by: sun.security.provider.certpath.SunCertPathBuilderException:
>> unable to find valid certification path to requested target
>> at
>> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
>> [rt.jar:1.8.0_45]
>> at
>> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
>> [rt.jar:1.8.0_45]
>> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>> [rt.jar:1.8.0_45]
>> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
>> [rt.jar:1.8.0_45]
>> ... 56 more
>>
>>
>>
>>
>>
>> --
>> Leonardo Nunes
>> ------------------------------
>>
>>
>> *Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
>> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem,
>> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar
>> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por
>> engano, por favor avise imediatamente o remetente, respondendo o e-mail e
>> em seguida apague-o. Agradecemos sua coopera??o. This message may contain
>> confidential and/or privileged information. If you are not the addressee or
>> authorized to receive this for the addressee, you must not use, copy,
>> disclose or take any action based on this message or any information
>> herein. If you have received this message in error, please advise the
>> sender immediately by reply e-mail and delete this message. Thank you for
>> your cooperation*
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>
> _______________________________________________
> 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/20160212/b9676438/attachment-0001.html 

From sthorger at redhat.com  Fri Feb 12 02:56:20 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 08:56:20 +0100
Subject: [keycloak-user] Issues with password reset link expiration
In-Reply-To: <9e3ecfb853ce42809eb3db603544d406@HsteqMX04.nexonhosted.local>
References: <e3c4dce4db8649958379bf11260f79d1@HsteqMX04.nexonhosted.local>
	<CAJgngAdk_iN2vcR0i5t-3wriOe3xgQWAxPGWf1_D3sR62_s8JQ@mail.gmail.com>
	<56BB40F0.1080204@redhat.com>
	<CAJgngAfiUdD6TJviSRf3j8erStY3atLzk3ygFEXCgwst+wnu-Q@mail.gmail.com>
	<56BB4614.8090509@redhat.com>
	<CAJgngAd3NNYUXRaWYnf7rpKFxMzCLvVHGVXrmvjMUUxzFz2RzQ@mail.gmail.com>
	<e2031b62eb4f4212b440b371f09b430d@HsteqMX04.nexonhosted.local>
	<9e3ecfb853ce42809eb3db603544d406@HsteqMX04.nexonhosted.local>
Message-ID: <CAJgngAdDcXYuDrwzbDEzU8mDLQbUnnieLUM7tyX2b-J+qk6URA@mail.gmail.com>

Great, thanks for the update

On 12 February 2016 at 08:44, Michael Anthon <michael.anthon at infoview.com.au
> wrote:

> We have verified that the behavior is correct in 1.9.0.CR1.
>
>
>
> Cheers,
>
> Michael
>
>
>
> *From:* keycloak-user-bounces at lists.jboss.org [mailto:
> keycloak-user-bounces at lists.jboss.org] *On Behalf Of *Michael Anthon
> *Sent:* Thursday, 11 February 2016 2:42 PM
> *To:* keycloak-user at lists.jboss.org
>
> *Subject:* Re: [keycloak-user] Issues with password reset link expiration
>
>
>
> Thanks for the replies, I forgot to mention we are currently on
> 1.6.1.Final however we do have a test setup where we can run an upgrade and
> check this out.
>
>
>
> Will try that and report back and/or create a ticket as required.
>
>
>
> Cheers,
>
> Michael
>
>
>
> *From:* Stian Thorgersen [mailto:sthorger at redhat.com <sthorger at redhat.com>]
>
> *Sent:* Thursday, 11 February 2016 12:26 AM
> *To:* Bill Burke <bburke at redhat.com>; Michael Anthon <
> michael.anthon at infoview.com.au>
> *Cc:* keycloak-user <keycloak-user at lists.jboss.org>
> *Subject:* Re: [keycloak-user] Issues with password reset link expiration
>
>
>
> Michael,
>
>
>
> Can you confirm if this issue still exists on 1.9.0.CR1 and if it does
> create a JIRA issue?
>
>
>
> On 10 February 2016 at 15:15, Bill Burke <bburke at redhat.com> wrote:
>
> I think this may have been fixed in 1.9 with the flow changes I made.  I
> don't have time to try it out right now though.
>
>
>
> On 2/10/2016 8:58 AM, Stian Thorgersen wrote:
>
> It's not about the error message though. It should be possible to open the
> link multiple times as long as the form is not submitted.
>
>
>
> On 10 February 2016 at 14:53, Bill Burke <bburke at redhat.com> wrote:
>
> We changed the "error" message in I think 1.9?  Maybe 1.8 to say "You
> clicked on a stale link.  Maybe you have already verified your email?"
> I'll look into improving this I guess.
>
>
>
> On 2/10/2016 4:21 AM, Stian Thorgersen wrote:
>
> It should be possible to open the link multiple times, but only submit the
> password reset once. If that's not the case (sounds like it is) feel free
> to create a JIRA issue to report this as a bug.
>
>
>
> On 10 February 2016 at 05:24, Michael Anthon <
> michael.anthon at infoview.com.au> wrote:
>
> We are having issues with some users when they are attempting to use the
> password reset feature.  It does work for most users however for some they
> always end up at an error page saying "WE'RE SORRY ... An error occurred,
> please login again through your application"
>
> What I have been able to determine so far is that for the affected users
> we are seeing a double hit on that URL in the server logs and from what I
> understand, these reset URLs are invalidated as soon as they are accessed.
>
> So here's the state of play
> * works for most users
> * some users hitting the reset URL twice
> * URL is only valid for the first access (I'm not 100% sure about this,
> can someone confirm please?)
> * URL is only valid for 30 minutes (but is being accessed within a few
> minutes of generation)
> * affected users are mostly using Outlook
> * some people tend to double click links in emails but I've verified with
> a reliable user that they are only clicking the link once
> * having the affected person send themselves another reset email and then
> copy and paste the URL from the mail client usually resolves this problem
>
> And questions
> * is this an issue anyone else has noticed with Outlook, doesn't affect
> ALL Outlook users, just some
> * is there a way to prevent the URL from being invalidated on initial
> access
> * is it feasible to change the behavior so that the URL is only
> invalidated when the password is changed
> * any other thoughts on how to avoid this issue?
>
> Thanks and Regards,
>
> Michael Anthon
> InfoView Technologies Pty Ltd
> 12/15 Adelaide St, Brisbane Qld 4000
> P O Box 15478, City East, Brisbane Qld 4000
> PH:          +61 7 3014 2204
> F:             +61 7 3014 2200
> M:           +61 408 768 055
> michael.anthon at infoview.com.au
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material from any
> computer. Any views or opinions expressed in this email are solely those of
> the author and do not necessarily represent those of InfoView Technologies
> Pty Ltd.
>
>
> _______________________________________________
> 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
>
>
>
>
>
> --
>
> 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/20160212/8f47a215/attachment.html 

From sthorger at redhat.com  Fri Feb 12 02:57:13 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 08:57:13 +0100
Subject: [keycloak-user] User-Federation
In-Reply-To: <4B71E2D9-755C-40C4-8C4B-DC516C9CF11E@smartling.com>
References: <CADW1CM8kNr=WkTSm4jp_BZm4Bdm6JSJhSLgPvhLQxDSmrC653A@mail.gmail.com>
	<E4193CB0-4921-45BD-AA73-8BA39AF8D3C0@carbonite.com>
	<CAEBys6KM1-n6wFqTJAAqb_aYaQdZwuiaUz2AspF5d-8Za=E9wQ@mail.gmail.com>
	<CAEBys6+i6jFdycaCg-rf9vC=T7chbrkKeWsfAbNvC2tidKdhZw@mail.gmail.com>
	<81B2EA95-4A60-4992-ADF0-17AD754D1E46@carbonite.com>
	<4B71E2D9-755C-40C4-8C4B-DC516C9CF11E@smartling.com>
Message-ID: <CAJgngAckxNGxNRiWeT5p5zcDzBhRXsPQyTDWjWDnMG=oai593g@mail.gmail.com>

On 11 February 2016 at 17:51, Scott Rossillo <srossillo at smartling.com>
wrote:

> Hi,
>
> The example omits securing the endpoints for simplicity demonstrating the
> concepts. I?d suggest using some type of security though on the legacy
> system if the endpoints are publicly accessible though.
>

There's this thing called Keycloak that may be useful for that ;)


>
> Best,
> Scott
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
> On Feb 11, 2016, at 9:35 AM, Reed Lewis <RLewis at carbonite.com> wrote:
>
> The endpoint that is used by the federation provider is only called from
> Keycloak, so you can run it on localhost on the keycloak machine if that is
> going to work for you.
>
> OTOH, if you need to run it on a different machine, you can lock down the
> endpoint to only be accessible from the Keycloak server.
>
> End users never call the endpoint I documented.
>
> Reed
>
> From: <darkness.renann at gmail.com> on behalf of Renann Prado <
> prado.renann at gmail.com>
> Date: Thursday, February 11, 2016 at 8:17 AM
> To: Reed Lewis <RLewis at carbonite.com>
> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>,
> Stuart Jacobs <stuart.jacobs at symbiotics.co.za>
> Subject: Re: [keycloak-user] User-Federation
>
> Everyone*
> On Feb 11, 2016 11:16, "Renann Prado" <prado.renann at gmail.com> wrote:
>
>> Is there any recommended way to make sure these endpoints won't be
>> spammed by an attacker? Looks like these endpoints need to be open to
>> anyone.
>>
>> Thanks
>> On Feb 3, 2016 11:18, "Reed Lewis" <RLewis at carbonite.com> wrote:
>>
>>> If you use the federation provider listed here:
>>>
>>> [0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
>>> [1]: https://github.com/Smartling/keycloak-user-migration-provider
>>>
>>> You can specify a URL that will be called when a user needs to be
>>> validated.
>>>
>>> There are three requests that need to be implemented in your sever.
>>>
>>> GET <baseURL>/api/users/<username>/
>>> If the user exists, it should return a 200 with a json object with the
>>> return type ?application/json? with the following fields:
>>> username
>>> email
>>> emailVerified
>>> firstName
>>> lastName
>>> roles [?user?]
>>>
>>> If the user does not exist, return a 404
>>>
>>> HEAD <baseURL>/api/users/<username>/
>>> Always return 200
>>>
>>> POST <baseURL>/api/users/<username>/
>>> The password is posted to you in a json object.
>>> Return 200 if the password is OK, 401 if not.  In both cases return no
>>> data.
>>>
>>> I wrote a small python module which implements these methods which works
>>> quite well.
>>>
>>> Reed
>>>
>>> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stuart
>>> Jacobs <stuart.jacobs at symbiotics.co.za>
>>> Date: Wednesday, February 3, 2016 at 2:40 AM
>>> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>>> Subject: [keycloak-user] User-Federation
>>>
>>> Hi Everyone,
>>>
>>> I have an application that runs on a postgresql database, keycloak has
>>> been configured and has created all the required tables/columns in my
>>> schema using liquibase on start up of the keycloak server.
>>>
>>> I need to authenticate users using the projects existing user table
>>> obtaining the username and password from this table.
>>>
>>> I have had a look at the federation provider project under the example
>>> projects but this still eludes me as to how I change the keycloak mapping
>>> to use my own tables in postgress?
>>>
>>> Can someone please point me in the right direction or if someone has
>>> implemented such a solution please share how you have done it?
>>>
>>> Thanks everyone.
>>>
>>>   Regards,
>>>   Stuart Jacobs
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> www.symbiotics.co.za
>>>
>>> ********************************************************************************
>>> This email and any accompanying attachments may contain confidential and
>>> proprietary information. This information is private and protected by law
>>> and, accordingly, if you are not the intended recipient, you are requested
>>> to delete this entire communication immediately and are notified that any
>>> disclosure, copying or distribution of or taking any action based on this
>>> information is prohibited.
>>>
>>> Emails cannot be guaranteed to be secure or free of errors or viruses.
>>> The sender does not accept any liability or responsibility for any
>>> interception, corruption, destruction, loss, late arrival or incompleteness
>>> of or tampering or interference with any of the information contained in
>>> this email or for its incorrect delivery or non-delivery for whatsoever
>>> reason or for its effect on any electronic device of the recipient.
>>>
>>> ********************************************************************************
>>>
>>>
>>> _______________________________________________
>>> 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/20160212/cd72cbf8/attachment-0001.html 

From sthorger at redhat.com  Fri Feb 12 02:58:13 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 08:58:13 +0100
Subject: [keycloak-user] Device tokens with keycloak
In-Reply-To: <BC3430FF-7F33-4F0E-ACAE-66D90FE63673@carboniteinc.com>
References: <BC3430FF-7F33-4F0E-ACAE-66D90FE63673@carboniteinc.com>
Message-ID: <CAJgngAc60kZLce1=4rQ13FKKRcvHyCVoj_nma82ijsAx60viyg@mail.gmail.com>

We don't have anything specific with regards to device tokens. We have
offline tokens for users as well as service accounts, that may cover your
needs. Can you explain your use-case and what you are actually after?

On 11 February 2016 at 00:01, Riddhi Rathod <RRathod at carbonite.com> wrote:

> Does Keycloak have the ability to provide ?device? tokens in addition to
> the user tokens ?
>
> I found discussion link on device registration:
> http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001116.html .
> However, I wanted to know whether or not this feature is supported now?
>
>
> Thank you,
> Riddhi Rathod
>
> _______________________________________________
> 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/20160212/26401598/attachment.html 

From akaya at expedia.com  Fri Feb 12 03:15:02 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Fri, 12 Feb 2016 08:15:02 +0000
Subject: [keycloak-user]  Extending Themes via SPI
In-Reply-To: <D2E3D081.2780%akaya@expedia.com>
References: <D2E3B3EF.2772%akaya@expedia.com>
	<CAJgngAen9zYDj2XzcNQk4D6YRDb-jhxRXab9WcaFd-CEX8R6Yg@mail.gmail.com>
	<D2E3D081.2780%akaya@expedia.com>
Message-ID: <D2E3D193.278A%akaya@expedia.com>


We have internal front end libraries that works with JSP only. From the sounds of SPI, I thought that I could use JSP and our internal libraries instead of FreeMarker templates. Also because our JSP login screen is almost ready it wouldn't take much time to just deploy it (that's what I thought).

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: Friday, February 12, 2016 at 5:54 PM
To: Abdullah Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Extending Themes via SPI

What are you actually trying to achieve? We mainly support modifying the FreeMarker templates and stylesheets. Beyond that you may in theory be able to re-implement it all to replace FreeMarker with something else, but I don't see why you would want to and it would be a significant amount of work, and also maintenance.

On 12 February 2016 at 07:08, Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>> wrote:
Hi all,

In regards to Extending Themes via SPI all I found is this documentation:
http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html and
<http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450>
http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450
I found it a little less describing.

When I implement those two classes, where do I put the new implemented classes? How do I deploy them?
Can I also use Spring mvc and JSP and few maven dependencies instead of freemarker?

I also tried to find an example to extend theme using SPI but there seems to be none. It would be really nice if you could provide a sample hello world.

Thank you very much,
Sarp Kaya

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/8265139f/attachment.html 

From sthorger at redhat.com  Fri Feb 12 03:29:37 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 09:29:37 +0100
Subject: [keycloak-user] Extending Themes via SPI
In-Reply-To: <D2E3D193.278A%akaya@expedia.com>
References: <D2E3B3EF.2772%akaya@expedia.com>
	<CAJgngAen9zYDj2XzcNQk4D6YRDb-jhxRXab9WcaFd-CEX8R6Yg@mail.gmail.com>
	<D2E3D081.2780%akaya@expedia.com> <D2E3D193.278A%akaya@expedia.com>
Message-ID: <CAJgngAcBkFrWj==x5TXxePceYmv3Dy9H0WPOPSpOxrJmjytkKw@mail.gmail.com>

There's a lot more to the login on Keycloak than a simple JSP page used for
JEE form-based authentication. We have user registration, password
recovery, OTP support, remember me, etc, etc..

Take the look and feel (stylesheet) of your JSP login screen and apply it
to Keycloak with a custom theme. That's the simplest, quickest and best
option.

On 12 February 2016 at 09:15, Sarp Kaya <akaya at expedia.com> wrote:

>
> We have internal front end libraries that works with JSP only. From the
> sounds of SPI, I thought that I could use JSP and our internal libraries
> instead of FreeMarker templates. Also because our JSP login screen is
> almost ready it wouldn?t take much time to just deploy it (that?s what I
> thought).
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Reply-To: "stian at redhat.com" <stian at redhat.com>
> Date: Friday, February 12, 2016 at 5:54 PM
> To: Abdullah Sarp Kaya <akaya at expedia.com>
> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Extending Themes via SPI
>
> What are you actually trying to achieve? We mainly support modifying the
> FreeMarker templates and stylesheets. Beyond that you may in theory be able
> to re-implement it all to replace FreeMarker with something else, but I
> don't see why you would want to and it would be a significant amount of
> work, and also maintenance.
>
> On 12 February 2016 at 07:08, Sarp Kaya <akaya at expedia.com> wrote:
>
>> Hi all,
>>
>> In regards to Extending Themes via SPI all I found is this documentation:
>>
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html
>>  and
>>
>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450>
>>
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450
>> I found it a little less describing.
>>
>> When I implement those two classes, where do I put the new implemented
>> classes? How do I deploy them?
>> Can I also use Spring mvc and JSP and few maven dependencies instead of
>> freemarker?
>>
>> I also tried to find an example to extend theme using SPI but there seems
>> to be none. It would be really nice if you could provide a sample hello
>> world.
>>
>> Thank you very much,
>> Sarp Kaya
>>
>> _______________________________________________
>> 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/20160212/e55abce4/attachment.html 

From akaya at expedia.com  Fri Feb 12 03:47:40 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Fri, 12 Feb 2016 08:47:40 +0000
Subject: [keycloak-user] Extending Themes via SPI
In-Reply-To: <CAJgngAcBkFrWj==x5TXxePceYmv3Dy9H0WPOPSpOxrJmjytkKw@mail.gmail.com>
References: <D2E3B3EF.2772%akaya@expedia.com>
	<CAJgngAen9zYDj2XzcNQk4D6YRDb-jhxRXab9WcaFd-CEX8R6Yg@mail.gmail.com>
	<D2E3D081.2780%akaya@expedia.com> <D2E3D193.278A%akaya@expedia.com>
	<CAJgngAcBkFrWj==x5TXxePceYmv3Dy9H0WPOPSpOxrJmjytkKw@mail.gmail.com>
Message-ID: <D2E3D884.2790%akaya@expedia.com>

Okay but what you are saying is done directly on the Keycloak source code which is then built and deployed, rather than extending classes and then deploying directly to a Keycloak instance?

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: Friday, February 12, 2016 at 6:29 PM
To: Abdullah Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Extending Themes via SPI

There's a lot more to the login on Keycloak than a simple JSP page used for JEE form-based authentication. We have user registration, password recovery, OTP support, remember me, etc, etc..

Take the look and feel (stylesheet) of your JSP login screen and apply it to Keycloak with a custom theme. That's the simplest, quickest and best option.

On 12 February 2016 at 09:15, Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>> wrote:

We have internal front end libraries that works with JSP only. From the sounds of SPI, I thought that I could use JSP and our internal libraries instead of FreeMarker templates. Also because our JSP login screen is almost ready it wouldn't take much time to just deploy it (that's what I thought).

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: Friday, February 12, 2016 at 5:54 PM
To: Abdullah Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Extending Themes via SPI

What are you actually trying to achieve? We mainly support modifying the FreeMarker templates and stylesheets. Beyond that you may in theory be able to re-implement it all to replace FreeMarker with something else, but I don't see why you would want to and it would be a significant amount of work, and also maintenance.

On 12 February 2016 at 07:08, Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>> wrote:
Hi all,

In regards to Extending Themes via SPI all I found is this documentation:
http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html and
<http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450>
http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450
I found it a little less describing.

When I implement those two classes, where do I put the new implemented classes? How do I deploy them?
Can I also use Spring mvc and JSP and few maven dependencies instead of freemarker?

I also tried to find an example to extend theme using SPI but there seems to be none. It would be really nice if you could provide a sample hello world.

Thank you very much,
Sarp Kaya

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


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/9f809407/attachment-0001.html 

From sthorger at redhat.com  Fri Feb 12 03:53:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 09:53:56 +0100
Subject: [keycloak-user] Extending Themes via SPI
In-Reply-To: <D2E3D884.2790%akaya@expedia.com>
References: <D2E3B3EF.2772%akaya@expedia.com>
	<CAJgngAen9zYDj2XzcNQk4D6YRDb-jhxRXab9WcaFd-CEX8R6Yg@mail.gmail.com>
	<D2E3D081.2780%akaya@expedia.com> <D2E3D193.278A%akaya@expedia.com>
	<CAJgngAcBkFrWj==x5TXxePceYmv3Dy9H0WPOPSpOxrJmjytkKw@mail.gmail.com>
	<D2E3D884.2790%akaya@expedia.com>
Message-ID: <CAJgngAfBrCv2B_A81Yc3sbBQbWz8O6JrXEa6SUWh8xG91EDDPg@mail.gmail.com>

No, you can create a theme that contains stylesheets and freemarker
templates (if you need to change those) and deploy it to Keycloak. Please
read
http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html
and take a look at the themes examples in our examples download.

On 12 February 2016 at 09:47, Sarp Kaya <akaya at expedia.com> wrote:

> Okay but what you are saying is done directly on the Keycloak source code
> which is then built and deployed, rather than extending classes and then
> deploying directly to a Keycloak instance?
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Reply-To: "stian at redhat.com" <stian at redhat.com>
> Date: Friday, February 12, 2016 at 6:29 PM
>
> To: Abdullah Sarp Kaya <akaya at expedia.com>
> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Extending Themes via SPI
>
> There's a lot more to the login on Keycloak than a simple JSP page used
> for JEE form-based authentication. We have user registration, password
> recovery, OTP support, remember me, etc, etc..
>
> Take the look and feel (stylesheet) of your JSP login screen and apply it
> to Keycloak with a custom theme. That's the simplest, quickest and best
> option.
>
> On 12 February 2016 at 09:15, Sarp Kaya <akaya at expedia.com> wrote:
>
>>
>> We have internal front end libraries that works with JSP only. From the
>> sounds of SPI, I thought that I could use JSP and our internal libraries
>> instead of FreeMarker templates. Also because our JSP login screen is
>> almost ready it wouldn?t take much time to just deploy it (that?s what I
>> thought).
>>
>> From: Stian Thorgersen <sthorger at redhat.com>
>> Reply-To: "stian at redhat.com" <stian at redhat.com>
>> Date: Friday, February 12, 2016 at 5:54 PM
>> To: Abdullah Sarp Kaya <akaya at expedia.com>
>> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>> Subject: Re: [keycloak-user] Extending Themes via SPI
>>
>> What are you actually trying to achieve? We mainly support modifying the
>> FreeMarker templates and stylesheets. Beyond that you may in theory be able
>> to re-implement it all to replace FreeMarker with something else, but I
>> don't see why you would want to and it would be a significant amount of
>> work, and also maintenance.
>>
>> On 12 February 2016 at 07:08, Sarp Kaya <akaya at expedia.com> wrote:
>>
>>> Hi all,
>>>
>>> In regards to Extending Themes via SPI all I found is this documentation:
>>>
>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html
>>>  and
>>>
>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450>
>>>
>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450
>>> I found it a little less describing.
>>>
>>> When I implement those two classes, where do I put the new implemented
>>> classes? How do I deploy them?
>>> Can I also use Spring mvc and JSP and few maven dependencies instead of
>>> freemarker?
>>>
>>> I also tried to find an example to extend theme using SPI but there
>>> seems to be none. It would be really nice if you could provide a sample
>>> hello world.
>>>
>>> Thank you very much,
>>> Sarp Kaya
>>>
>>> _______________________________________________
>>> 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/20160212/dd16d2fc/attachment.html 

From mstrukel at redhat.com  Fri Feb 12 04:04:04 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 12 Feb 2016 10:04:04 +0100
Subject: [keycloak-user] Failed to make identity provider oauth
	callback: javax.net.ssl.SSLHandshakeException
In-Reply-To: <56BD8499.4060007@redhat.com>
References: <D2E21C82.26535%leo.nunes@ojc.com.br>
	<CAJgngAfV0HFHT=_rBYe0XQHNeBwKTTrm10gUU=xd24=pAq2KvQ@mail.gmail.com>
	<56BD8499.4060007@redhat.com>
Message-ID: <CA+1OW+gXfMSC+CiLo3vCSvxt0M5Gt9Qp_9TV7AiWcsfBW+DA9Q@mail.gmail.com>

When using 'truststore' provider it is up to you to make sure to
include all the certificates you trust. Configuration via
-Djavax.net.ssl.trustStore works the same - no automatic inclusion of
cacerts. But it sounds like a good usability feature to add a flag
that would automatically include cacerts as well. The problem is - it
happens occasionally that some CAs turn out not to be trustworthy, and
blindly importing all cacerts exposes you to that risk.

One detail to emphasize, with third party not-self-signed certificates
it's important to include the CA certificate used to create the
specific server certificate, rather than the server certificate
itself. Facebook servers use different short-lived server certificates
- and with two consecutive requests you may be presented with two
different server certificates - but they are all issued by the same
long-lived trusted CA.


On Fri, Feb 12, 2016 at 8:07 AM, Marek Posolda <mposolda at redhat.com> wrote:
> Facebook certificate should be signed by trusted authority, so it works with
> default JDK truststore. At least for me it always works.
>
> Shouldn't truststore SPI use both provided file + default JDK truststore by
> default? We may have flag to disable default JDK truststore, but not sure if
> it's ever needed. Also shouldn't we rewrite SimpleHTTP to use Apache HTTP
> client provided by HttpClientProvider SPI?
>
> Marek
>
>
> On 11/02/16 15:23, Stian Thorgersen wrote:
>
> Does it work if you don't specify the truststore? That will use the default
> truststore provided by the JDK.
>
> Also, does your truststore contain the required CA certs? For Facebook to
> work it'll have to contain the required CA's for their certs
>
> On 11 February 2016 at 14:09, LEONARDO NUNES <leo.nunes at gjccorp.com.br>
> wrote:
>>
>> Hi, i'm getting the error below when I try to login with Facebook.
>> I've followed the instructions at
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore
>> and
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337
>>
>> I was able to login with Facebook when trying at localhost. But at our
>> development server we are getting this error.
>>
>> We are using EAP in domain mode.
>>
>> The truststore I placed inside of keycloak-server.json
>> "truststore": {
>>         "file": {
>>             "file": "/home/soa/jboss/ssl/keycloak.jks",
>>             "password": "keycloak123",
>>             "hostname-verification-policy": "ANY",
>>             "disabled": false
>>         }
>>     }
>>
>>
>> #######
>>
>> ERRO:
>>
>>
>> 2016-02-11 10:44:53,927 ERROR
>> [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider]
>> (ajp-/192.168.162.73:8008-1) Failed to make identity provider oauth
>> callback: javax.net.ssl.SSLHandshakeException:
>> sun.security.validator.ValidatorException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
>> valid certification path to requested target
>> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
>> [rt.jar:1.8.0_45]
>> at
>> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
>> at
>> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [rt.jar:1.8.0_45]
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> [rt.jar:1.8.0_45]
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.8.0_45]
>> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
>> at
>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
>> at
>> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
>> at
>> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
>> [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
>> Caused by: sun.security.validator.ValidatorException: PKIX path building
>> failed: sun.security.provider.certpath.SunCertPathBuilderException: unable
>> to find valid certification path to requested target
>> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
>> [rt.jar:1.8.0_45]
>> at
>> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
>> [rt.jar:1.8.0_45]
>> at sun.security.validator.Validator.validate(Validator.java:260)
>> [rt.jar:1.8.0_45]
>> at
>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
>> [jsse.jar:1.8.0_45]
>> ... 50 more
>> Caused by: sun.security.provider.certpath.SunCertPathBuilderException:
>> unable to find valid certification path to requested target
>> at
>> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
>> [rt.jar:1.8.0_45]
>> at
>> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
>> [rt.jar:1.8.0_45]
>> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>> [rt.jar:1.8.0_45]
>> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
>> [rt.jar:1.8.0_45]
>> ... 56 more
>>
>>
>>
>>
>>
>> --
>> Leonardo Nunes
>> ________________________________
>> Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
>> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem,
>> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar
>> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por
>> engano, por favor avise imediatamente o remetente, respondendo o e-mail e em
>> seguida apague-o. Agradecemos sua coopera??o.
>>
>> This message may contain confidential and/or privileged information. If
>> you are not the addressee or authorized to receive this for the addressee,
>> you must not use, copy, disclose or take any action based on this message or
>> any information herein. If you have received this message in error, please
>> advise the sender immediately by reply e-mail and delete this message. Thank
>> you for your cooperation
>>
>> _______________________________________________
>> 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 sthorger at redhat.com  Fri Feb 12 04:43:18 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 10:43:18 +0100
Subject: [keycloak-user] Failed to make identity provider oauth
	callback: javax.net.ssl.SSLHandshakeException
In-Reply-To: <CA+1OW+gXfMSC+CiLo3vCSvxt0M5Gt9Qp_9TV7AiWcsfBW+DA9Q@mail.gmail.com>
References: <D2E21C82.26535%leo.nunes@ojc.com.br>
	<CAJgngAfV0HFHT=_rBYe0XQHNeBwKTTrm10gUU=xd24=pAq2KvQ@mail.gmail.com>
	<56BD8499.4060007@redhat.com>
	<CA+1OW+gXfMSC+CiLo3vCSvxt0M5Gt9Qp_9TV7AiWcsfBW+DA9Q@mail.gmail.com>
Message-ID: <CAJgngAf4-aAyu_aONLOiYC9Ap0LmAur7U-yn2pP7H4o2LKHsrw@mail.gmail.com>

On 12 February 2016 at 10:04, Marko Strukelj <mstrukel at redhat.com> wrote:

> When using 'truststore' provider it is up to you to make sure to
> include all the certificates you trust. Configuration via
> -Djavax.net.ssl.trustStore works the same - no automatic inclusion of
> cacerts. But it sounds like a good usability feature to add a flag
> that would automatically include cacerts as well. The problem is - it
> happens occasionally that some CAs turn out not to be trustworthy, and
> blindly importing all cacerts exposes you to that risk.
>

How about having a flag that is enabled by default that includes cacerts
from Java? I'd actually think that update from CA certs are more likely
going to happen by updating Java rather than manually maintaining a
truststore.


> One detail to emphasize, with third party not-self-signed certificates
> it's important to include the CA certificate used to create the
> specific server certificate, rather than the server certificate
> itself. Facebook servers use different short-lived server certificates
> - and with two consecutive requests you may be presented with two
> different server certificates - but they are all issued by the same
> long-lived trusted CA.


>
> On Fri, Feb 12, 2016 at 8:07 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
> > Facebook certificate should be signed by trusted authority, so it works
> with
> > default JDK truststore. At least for me it always works.
> >
> > Shouldn't truststore SPI use both provided file + default JDK truststore
> by
> > default? We may have flag to disable default JDK truststore, but not
> sure if
> > it's ever needed. Also shouldn't we rewrite SimpleHTTP to use Apache HTTP
> > client provided by HttpClientProvider SPI?
> >
> > Marek
> >
> >
> > On 11/02/16 15:23, Stian Thorgersen wrote:
> >
> > Does it work if you don't specify the truststore? That will use the
> default
> > truststore provided by the JDK.
> >
> > Also, does your truststore contain the required CA certs? For Facebook to
> > work it'll have to contain the required CA's for their certs
> >
> > On 11 February 2016 at 14:09, LEONARDO NUNES <leo.nunes at gjccorp.com.br>
> > wrote:
> >>
> >> Hi, i'm getting the error below when I try to login with Facebook.
> >> I've followed the instructions at
> >>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore
> >> and
> >>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337
> >>
> >> I was able to login with Facebook when trying at localhost. But at our
> >> development server we are getting this error.
> >>
> >> We are using EAP in domain mode.
> >>
> >> The truststore I placed inside of keycloak-server.json
> >> "truststore": {
> >>         "file": {
> >>             "file": "/home/soa/jboss/ssl/keycloak.jks",
> >>             "password": "keycloak123",
> >>             "hostname-verification-policy": "ANY",
> >>             "disabled": false
> >>         }
> >>     }
> >>
> >>
> >> #######
> >>
> >> ERRO:
> >>
> >>
> >> 2016-02-11 10:44:53,927 ERROR
> >> [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider]
> >> (ajp-/192.168.162.73:8008-1) Failed to make identity provider oauth
> >> callback: javax.net.ssl.SSLHandshakeException:
> >> sun.security.validator.ValidatorException: PKIX path building failed:
> >> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find
> >> valid certification path to requested target
> >> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
> >> [jsse.jar:1.8.0_45]
> >> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
> >> [jsse.jar:1.8.0_45]
> >> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
> >> at
> >>
> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >> [rt.jar:1.8.0_45]
> >> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
> >> at
> >>
> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> >>
> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
> >> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
> >> at
> >>
> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
> >> at
> >>
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> >> [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
> >> at
> >>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> >> Caused by: sun.security.validator.ValidatorException: PKIX path building
> >> failed: sun.security.provider.certpath.SunCertPathBuilderException:
> unable
> >> to find valid certification path to requested target
> >> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
> >> [rt.jar:1.8.0_45]
> >> at sun.security.validator.Validator.validate(Validator.java:260)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
> >> [jsse.jar:1.8.0_45]
> >> ... 50 more
> >> Caused by: sun.security.provider.certpath.SunCertPathBuilderException:
> >> unable to find valid certification path to requested target
> >> at
> >>
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
> >> [rt.jar:1.8.0_45]
> >> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
> >> [rt.jar:1.8.0_45]
> >> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
> >> [rt.jar:1.8.0_45]
> >> ... 56 more
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Leonardo Nunes
> >> ________________________________
> >> Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
> >> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta
> mensagem,
> >> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou
> tomar
> >> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem
> por
> >> engano, por favor avise imediatamente o remetente, respondendo o e-mail
> e em
> >> seguida apague-o. Agradecemos sua coopera??o.
> >>
> >> This message may contain confidential and/or privileged information. If
> >> you are not the addressee or authorized to receive this for the
> addressee,
> >> you must not use, copy, disclose or take any action based on this
> message or
> >> any information herein. If you have received this message in error,
> please
> >> advise the sender immediately by reply e-mail and delete this message.
> Thank
> >> you for your cooperation
> >>
> >> _______________________________________________
> >> 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/20160212/cf9f6d0b/attachment-0001.html 

From akaya at expedia.com  Fri Feb 12 05:20:46 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Fri, 12 Feb 2016 10:20:46 +0000
Subject: [keycloak-user] Extending Themes via SPI
In-Reply-To: <CAJgngAfBrCv2B_A81Yc3sbBQbWz8O6JrXEa6SUWh8xG91EDDPg@mail.gmail.com>
References: <D2E3B3EF.2772%akaya@expedia.com>
	<CAJgngAen9zYDj2XzcNQk4D6YRDb-jhxRXab9WcaFd-CEX8R6Yg@mail.gmail.com>
	<D2E3D081.2780%akaya@expedia.com> <D2E3D193.278A%akaya@expedia.com>
	<CAJgngAcBkFrWj==x5TXxePceYmv3Dy9H0WPOPSpOxrJmjytkKw@mail.gmail.com>
	<D2E3D884.2790%akaya@expedia.com>
	<CAJgngAfBrCv2B_A81Yc3sbBQbWz8O6JrXEa6SUWh8xG91EDDPg@mail.gmail.com>
Message-ID: <D2E3EEE5.27A0%akaya@expedia.com>

Hi Stian,

I understand that I can create a theme using free marker, but my question was, if I were to create a theme using JSP instead of free marker, then do I have to change the Keycloak's source code?

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: Friday, February 12, 2016 at 6:53 PM
To: Abdullah Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Extending Themes via SPI

No, you can create a theme that contains stylesheets and freemarker templates (if you need to change those) and deploy it to Keycloak. Please read http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html and take a look at the themes examples in our examples download.

On 12 February 2016 at 09:47, Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>> wrote:
Okay but what you are saying is done directly on the Keycloak source code which is then built and deployed, rather than extending classes and then deploying directly to a Keycloak instance?

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: Friday, February 12, 2016 at 6:29 PM

To: Abdullah Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Extending Themes via SPI

There's a lot more to the login on Keycloak than a simple JSP page used for JEE form-based authentication. We have user registration, password recovery, OTP support, remember me, etc, etc..

Take the look and feel (stylesheet) of your JSP login screen and apply it to Keycloak with a custom theme. That's the simplest, quickest and best option.

On 12 February 2016 at 09:15, Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>> wrote:

We have internal front end libraries that works with JSP only. From the sounds of SPI, I thought that I could use JSP and our internal libraries instead of FreeMarker templates. Also because our JSP login screen is almost ready it wouldn't take much time to just deploy it (that's what I thought).

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: Friday, February 12, 2016 at 5:54 PM
To: Abdullah Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Extending Themes via SPI

What are you actually trying to achieve? We mainly support modifying the FreeMarker templates and stylesheets. Beyond that you may in theory be able to re-implement it all to replace FreeMarker with something else, but I don't see why you would want to and it would be a significant amount of work, and also maintenance.

On 12 February 2016 at 07:08, Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>> wrote:
Hi all,

In regards to Extending Themes via SPI all I found is this documentation:
http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html and
<http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450>
http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450
I found it a little less describing.

When I implement those two classes, where do I put the new implemented classes? How do I deploy them?
Can I also use Spring mvc and JSP and few maven dependencies instead of freemarker?

I also tried to find an example to extend theme using SPI but there seems to be none. It would be really nice if you could provide a sample hello world.

Thank you very much,
Sarp Kaya

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


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/dbea4c7e/attachment.html 

From sthorger at redhat.com  Fri Feb 12 05:28:08 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 11:28:08 +0100
Subject: [keycloak-user] Extending Themes via SPI
In-Reply-To: <D2E3EEE5.27A0%akaya@expedia.com>
References: <D2E3B3EF.2772%akaya@expedia.com>
	<CAJgngAen9zYDj2XzcNQk4D6YRDb-jhxRXab9WcaFd-CEX8R6Yg@mail.gmail.com>
	<D2E3D081.2780%akaya@expedia.com> <D2E3D193.278A%akaya@expedia.com>
	<CAJgngAcBkFrWj==x5TXxePceYmv3Dy9H0WPOPSpOxrJmjytkKw@mail.gmail.com>
	<D2E3D884.2790%akaya@expedia.com>
	<CAJgngAfBrCv2B_A81Yc3sbBQbWz8O6JrXEa6SUWh8xG91EDDPg@mail.gmail.com>
	<D2E3EEE5.27A0%akaya@expedia.com>
Message-ID: <CAJgngAdFX3uLf2HrtjhH7JJ2pCkN2HitoQCsaxESwVMO-Z4c8g@mail.gmail.com>

I strongly recommend against going down the JSP route, and we do not have
time to provide you with help on doing so. You have nothing to gain, only a
lot of work and headaches.

That being said the SPI is there and you can rip out our FreeMarker
implementation if you so please. As it's a SPI you do not need to modify
Keycloak source code, instead you create your own provider implementation
of the SPI. Take a look at the providers section of the documentation for
more information.

Most likely you won't even need to touch the FreeMarker templates and you
can acommodate the changes you need purely with stylesheets.

On 12 February 2016 at 11:20, Sarp Kaya <akaya at expedia.com> wrote:

> Hi Stian,
>
> I understand that I can create a theme using free marker, but my question
> was, if I were to create a theme using JSP instead of free marker, then do
> I have to change the Keycloak?s source code?
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Reply-To: "stian at redhat.com" <stian at redhat.com>
> Date: Friday, February 12, 2016 at 6:53 PM
>
> To: Abdullah Sarp Kaya <akaya at expedia.com>
> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Extending Themes via SPI
>
> No, you can create a theme that contains stylesheets and freemarker
> templates (if you need to change those) and deploy it to Keycloak. Please
> read
> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html
> and take a look at the themes examples in our examples download.
>
> On 12 February 2016 at 09:47, Sarp Kaya <akaya at expedia.com> wrote:
>
>> Okay but what you are saying is done directly on the Keycloak source code
>> which is then built and deployed, rather than extending classes and then
>> deploying directly to a Keycloak instance?
>>
>> From: Stian Thorgersen <sthorger at redhat.com>
>> Reply-To: "stian at redhat.com" <stian at redhat.com>
>> Date: Friday, February 12, 2016 at 6:29 PM
>>
>> To: Abdullah Sarp Kaya <akaya at expedia.com>
>> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>> Subject: Re: [keycloak-user] Extending Themes via SPI
>>
>> There's a lot more to the login on Keycloak than a simple JSP page used
>> for JEE form-based authentication. We have user registration, password
>> recovery, OTP support, remember me, etc, etc..
>>
>> Take the look and feel (stylesheet) of your JSP login screen and apply it
>> to Keycloak with a custom theme. That's the simplest, quickest and best
>> option.
>>
>> On 12 February 2016 at 09:15, Sarp Kaya <akaya at expedia.com> wrote:
>>
>>>
>>> We have internal front end libraries that works with JSP only. From the
>>> sounds of SPI, I thought that I could use JSP and our internal libraries
>>> instead of FreeMarker templates. Also because our JSP login screen is
>>> almost ready it wouldn?t take much time to just deploy it (that?s what I
>>> thought).
>>>
>>> From: Stian Thorgersen <sthorger at redhat.com>
>>> Reply-To: "stian at redhat.com" <stian at redhat.com>
>>> Date: Friday, February 12, 2016 at 5:54 PM
>>> To: Abdullah Sarp Kaya <akaya at expedia.com>
>>> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>>> Subject: Re: [keycloak-user] Extending Themes via SPI
>>>
>>> What are you actually trying to achieve? We mainly support modifying the
>>> FreeMarker templates and stylesheets. Beyond that you may in theory be able
>>> to re-implement it all to replace FreeMarker with something else, but I
>>> don't see why you would want to and it would be a significant amount of
>>> work, and also maintenance.
>>>
>>> On 12 February 2016 at 07:08, Sarp Kaya <akaya at expedia.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> In regards to Extending Themes via SPI all I found is this
>>>> documentation:
>>>>
>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html
>>>>  and
>>>>
>>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450>
>>>>
>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450
>>>> I found it a little less describing.
>>>>
>>>> When I implement those two classes, where do I put the new implemented
>>>> classes? How do I deploy them?
>>>> Can I also use Spring mvc and JSP and few maven dependencies instead of
>>>> freemarker?
>>>>
>>>> I also tried to find an example to extend theme using SPI but there
>>>> seems to be none. It would be really nice if you could provide a sample
>>>> hello world.
>>>>
>>>> Thank you very much,
>>>> Sarp Kaya
>>>>
>>>> _______________________________________________
>>>> 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/20160212/0edc12aa/attachment-0001.html 

From mstrukel at redhat.com  Fri Feb 12 05:44:31 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 12 Feb 2016 11:44:31 +0100
Subject: [keycloak-user] Failed to make identity provider oauth
	callback: javax.net.ssl.SSLHandshakeException
In-Reply-To: <CAJgngAf4-aAyu_aONLOiYC9Ap0LmAur7U-yn2pP7H4o2LKHsrw@mail.gmail.com>
References: <D2E21C82.26535%leo.nunes@ojc.com.br>
	<CAJgngAfV0HFHT=_rBYe0XQHNeBwKTTrm10gUU=xd24=pAq2KvQ@mail.gmail.com>
	<56BD8499.4060007@redhat.com>
	<CA+1OW+gXfMSC+CiLo3vCSvxt0M5Gt9Qp_9TV7AiWcsfBW+DA9Q@mail.gmail.com>
	<CAJgngAf4-aAyu_aONLOiYC9Ap0LmAur7U-yn2pP7H4o2LKHsrw@mail.gmail.com>
Message-ID: <CA+1OW+gbNtE3f+n5-_s5BB1AMEyHvgHAjkbHJs4Ti8ujQWrw7Q@mail.gmail.com>

We could add such a flag, don't know how hard it would be to implement.

In principle I agree about CA cert updates. But they are many, and for
your customized truststore you may add only a few, and for big-name
services. If CAs are revoked, then your integration will stop working
as those services will start using new certs that you don't have in
your truststore.

It's quite unlikely OTOH to notice one of the 100 trusted-by-default
CA that you never connect to, that can one day be used to forge a
certificate for one of the services that you do use - that one you
won't notice until you update Java.

From leo.nunes at gjccorp.com.br  Fri Feb 12 05:47:26 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Fri, 12 Feb 2016 10:47:26 +0000
Subject: [keycloak-user] Failed to make identity provider oauth
 callback: javax.net.ssl.SSLHandshakeException
In-Reply-To: <CAJgngAfV0HFHT=_rBYe0XQHNeBwKTTrm10gUU=xd24=pAq2KvQ@mail.gmail.com>
Message-ID: <D2E34811.26567%leo.nunes@ojc.com.br>

Stian, at our EAP init opts we have the -Djavax.net.ssl.trustStore= pointing to a .jks file that have a certificate for the hosts of our domain to communicate.
If I don't specify the -Djavax.net.ssl.trustStore= then Facebook login works fine with the one provided by the JDK.

I tried to find out which are the required CA's for Facebook, so I could add it to my truststore but I couldn't find.
Could you please help me with that?

I added a valid certificate to our truststore and still get the same error.



From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: quinta-feira, 11 de fevereiro de 2016 12:23
To: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Failed to make identity provider oauth callback: javax.net.ssl.SSLHandshakeException

Does it work if you don't specify the truststore? That will use the default truststore provided by the JDK.

Also, does your truststore contain the required CA certs? For Facebook to work it'll have to contain the required CA's for their certs

On 11 February 2016 at 14:09, LEONARDO NUNES <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>> wrote:
Hi, i'm getting the error below when I try to login with Facebook.
I've followed the instructions at http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore and http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337

I was able to login with Facebook when trying at localhost. But at our development server we are getting this error.

We are using EAP in domain mode.

The truststore I placed inside of keycloak-server.json
"truststore": {
        "file": {
            "file": "/home/soa/jboss/ssl/keycloak.jks",
            "password": "keycloak123",
            "hostname-verification-policy": "ANY",
            "disabled": false
        }
    }


#######

ERRO:


2016-02-11 10:44:53,927 ERROR [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (ajp-/192.168.162.73:8008-1) Failed to make identity provider oauth callback: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937) [jsse.jar:1.8.0_45]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302) [jsse.jar:1.8.0_45]
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) [jsse.jar:1.8.0_45]
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478) [jsse.jar:1.8.0_45]
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212) [jsse.jar:1.8.0_45]
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969) [jsse.jar:1.8.0_45]
at sun.security.ssl.Handshaker.process_record(Handshaker.java:904) [jsse.jar:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050) [jsse.jar:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363) [jsse.jar:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391) [jsse.jar:1.8.0_45]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375) [jsse.jar:1.8.0_45]
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563) [rt.jar:1.8.0_45]
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) [rt.jar:1.8.0_45]
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282) [rt.jar:1.8.0_45]
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257) [rt.jar:1.8.0_45]
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250) [rt.jar:1.8.0_45]
at org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
at org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_45]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61) [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387) [rt.jar:1.8.0_45]
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292) [rt.jar:1.8.0_45]
at sun.security.validator.Validator.validate(Validator.java:260) [rt.jar:1.8.0_45]
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) [jsse.jar:1.8.0_45]
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229) [jsse.jar:1.8.0_45]
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124) [jsse.jar:1.8.0_45]
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460) [jsse.jar:1.8.0_45]
... 50 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145) [rt.jar:1.8.0_45]
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131) [rt.jar:1.8.0_45]
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280) [rt.jar:1.8.0_45]
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382) [rt.jar:1.8.0_45]
... 56 more





--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/5666c979/attachment-0001.html 

From leo.nunes at gjccorp.com.br  Fri Feb 12 05:49:26 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Fri, 12 Feb 2016 10:49:26 +0000
Subject: [keycloak-user] Failed to make identity provider oauth
 callback: javax.net.ssl.SSLHandshakeException
In-Reply-To: <CAJgngAf4-aAyu_aONLOiYC9Ap0LmAur7U-yn2pP7H4o2LKHsrw@mail.gmail.com>
Message-ID: <D2E34CB9.26592%leo.nunes@ojc.com.br>

1+ to include cacerts from Java by default.


From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: sexta-feira, 12 de fevereiro de 2016 07:43
To: Marko Strukelj <mstrukel at redhat.com<mailto:mstrukel at redhat.com>>
Cc: Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>>, Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Failed to make identity provider oauth callback: javax.net.ssl.SSLHandshakeException


On 12 February 2016 at 10:04, Marko Strukelj <mstrukel at redhat.com<mailto:mstrukel at redhat.com>> wrote:
When using 'truststore' provider it is up to you to make sure to
include all the certificates you trust. Configuration via
-Djavax.net.ssl.trustStore works the same - no automatic inclusion of
cacerts. But it sounds like a good usability feature to add a flag
that would automatically include cacerts as well. The problem is - it
happens occasionally that some CAs turn out not to be trustworthy, and
blindly importing all cacerts exposes you to that risk.

How about having a flag that is enabled by default that includes cacerts from Java? I'd actually think that update from CA certs are more likely going to happen by updating Java rather than manually maintaining a truststore.


One detail to emphasize, with third party not-self-signed certificates
it's important to include the CA certificate used to create the
specific server certificate, rather than the server certificate
itself. Facebook servers use different short-lived server certificates
- and with two consecutive requests you may be presented with two
different server certificates - but they are all issued by the same
long-lived trusted CA.


On Fri, Feb 12, 2016 at 8:07 AM, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:
> Facebook certificate should be signed by trusted authority, so it works with
> default JDK truststore. At least for me it always works.
>
> Shouldn't truststore SPI use both provided file + default JDK truststore by
> default? We may have flag to disable default JDK truststore, but not sure if
> it's ever needed. Also shouldn't we rewrite SimpleHTTP to use Apache HTTP
> client provided by HttpClientProvider SPI?
>
> Marek
>
>
> On 11/02/16 15:23, Stian Thorgersen wrote:
>
> Does it work if you don't specify the truststore? That will use the default
> truststore provided by the JDK.
>
> Also, does your truststore contain the required CA certs? For Facebook to
> work it'll have to contain the required CA's for their certs
>
> On 11 February 2016 at 14:09, LEONARDO NUNES <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>
> wrote:
>>
>> Hi, i'm getting the error below when I try to login with Facebook.
>> I've followed the instructions at
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore
>> and
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337
>>
>> I was able to login with Facebook when trying at localhost. But at our
>> development server we are getting this error.
>>
>> We are using EAP in domain mode.
>>
>> The truststore I placed inside of keycloak-server.json
>> "truststore": {
>>         "file": {
>>             "file": "/home/soa/jboss/ssl/keycloak.jks",
>>             "password": "keycloak123",
>>             "hostname-verification-policy": "ANY",
>>             "disabled": false
>>         }
>>     }
>>
>>
>> #######
>>
>> ERRO:
>>
>>
>> 2016-02-11 10:44:53,927 ERROR
>> [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider]
>> (ajp-/192.168.162.73:8008-1) Failed to make identity provider oauth
>> callback: javax.net.ssl.SSLHandshakeException:
>> sun.security.validator.ValidatorException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
>> valid certification path to requested target
>> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
>> [jsse.jar:1.8.0_45]
>> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257)
>> [rt.jar:1.8.0_45]
>> at
>> sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
>> [rt.jar:1.8.0_45]
>> at
>> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
>> at
>> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [rt.jar:1.8.0_45]
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> [rt.jar:1.8.0_45]
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.8.0_45]
>> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
>> at
>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
>> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
>> at
>> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
>> at
>> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
>> [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at
>> org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
>> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
>> Caused by: sun.security.validator.ValidatorException: PKIX path building
>> failed: sun.security.provider.certpath.SunCertPathBuilderException: unable
>> to find valid certification path to requested target
>> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
>> [rt.jar:1.8.0_45]
>> at
>> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
>> [rt.jar:1.8.0_45]
>> at sun.security.validator.Validator.validate(Validator.java:260)
>> [rt.jar:1.8.0_45]
>> at
>> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
>> [jsse.jar:1.8.0_45]
>> at
>> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
>> [jsse.jar:1.8.0_45]
>> ... 50 more
>> Caused by: sun.security.provider.certpath.SunCertPathBuilderException:
>> unable to find valid certification path to requested target
>> at
>> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
>> [rt.jar:1.8.0_45]
>> at
>> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
>> [rt.jar:1.8.0_45]
>> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>> [rt.jar:1.8.0_45]
>> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
>> [rt.jar:1.8.0_45]
>> ... 56 more
>>
>>
>>
>>
>>
>> --
>> Leonardo Nunes
>> ________________________________
>> Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
>> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem,
>> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar
>> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por
>> engano, por favor avise imediatamente o remetente, respondendo o e-mail e em
>> seguida apague-o. Agradecemos sua coopera??o.
>>
>> This message may contain confidential and/or privileged information. If
>> you are not the addressee or authorized to receive this for the addressee,
>> you must not use, copy, disclose or take any action based on this message or
>> any information herein. If you have received this message in error, please
>> advise the sender immediately by reply e-mail and delete this message. Thank
>> you for your cooperation
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/c966105e/attachment-0001.html 

From kga.official at gmail.com  Fri Feb 12 06:43:10 2016
From: kga.official at gmail.com (Akshay Kini)
Date: Fri, 12 Feb 2016 17:13:10 +0530
Subject: [keycloak-user] Keycloak as a SAML SP: Is it possible to
 configure Keycloak to use RSA-SHA256 as the algorithm to sign assertions.
In-Reply-To: <CAFtx=Tk2X-uQDuFbO5f_rEHRHkdNLPE7ArtMW3uLc-Q0_FJwgg@mail.gmail.com>
References: <CAFtx=Tk2X-uQDuFbO5f_rEHRHkdNLPE7ArtMW3uLc-Q0_FJwgg@mail.gmail.com>
Message-ID: <CAFtx=Tnutkf-X-bHjKXuOdiC1kRh-eM67ZnCmJ7ikuNrEEiXRg@mail.gmail.com>

Hi Bill,

Thanks for looking into this.

The usecase is:

Keycloak is an SP and it is sending an AuthnRequest via HTTP Post. This
AuthnRequest is always using RSA-SHA1 for signing.

I have configured the Keycloak config file as follows:
<keycloak-saml-adapter>
    <SP entityID="exampleEntityID"
        sslPolicy="NONE"
        logoutPage="/logout.jsp"

nameIDPolicyFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
        forceAuthentication="false"
        signatureAlgorithm="RSA_SHA256">


In-fact the SP element doesn't have the "signatureAlgorithm" documented
anywhere in the SAML Client Apapter Reference Guide (it only exists for the
IDP).

Now this is a bit of unfamiliar territory for me, but I looked into the
Keycloak Code base (master):
I see that the org.keycloak.adapters.saml.config.parsers.SPXmlParser
doesn't deal with ConfigXmlConstants.SIGNATURE_ALGORITHM_ATTR while the
IDPXmlParser does.


Again, thanks for looking into this.

P.S. Sorry to all the mailing list subscribers, this "chain" might get
broken despite me changing the subject. I am not sure how to fix that when
using Gmail and subscribing to a digest mailing-list. Please send a direct
e-mail to me if you know how to fix that.

Thanks,
Regards,
Akshay


On Thu, Feb 11, 2016 at 7:36 PM, <keycloak-user-request at lists.jboss.org>
wrote:

> Send keycloak-user mailing list submissions to
>         keycloak-user at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
> or, via email, send a message with subject or body 'help' to
>         keycloak-user-request at lists.jboss.org
>
> You can reach the person managing the list at
>         keycloak-user-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of keycloak-user digest..."
>
>
> Today's Topics:
>
>    1. Re: User-Federation (Renann Prado)
>    2. Re: User-Federation (Renann Prado)
>    3. Re: Keycloak as a SAML SP: Is it possible to configure
>       Keycloak to use RSA-SHA256 as the algorithm to sign assertions.
>       (Bill Burke)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Feb 2016 11:16:29 -0200
> From: Renann Prado <prado.renann at gmail.com>
> Subject: Re: [keycloak-user] User-Federation
> To: Reed Lewis <RLewis at carbonite.com>
> Cc: keycloak-user at lists.jboss.org
> Message-ID:
>         <CAEBys6KM1-n6wFqTJAAqb_aYaQdZwuiaUz2AspF5d-8Za=
> E9wQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Is there any recommended way to make sure these endpoints won't be spammed
> by an attacker? Looks like these endpoints need to be open to anyone.
>
> Thanks
> On Feb 3, 2016 11:18, "Reed Lewis" <RLewis at carbonite.com> wrote:
>
> > If you use the federation provider listed here:
> >
> > [0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
> > [1]: https://github.com/Smartling/keycloak-user-migration-provider
> >
> > You can specify a URL that will be called when a user needs to be
> > validated.
> >
> > There are three requests that need to be implemented in your sever.
> >
> > GET <baseURL>/api/users/<username>/
> > If the user exists, it should return a 200 with a json object with the
> > return type ?application/json? with the following fields:
> > username
> > email
> > emailVerified
> > firstName
> > lastName
> > roles [?user?]
> >
> > If the user does not exist, return a 404
> >
> > HEAD <baseURL>/api/users/<username>/
> > Always return 200
> >
> > POST <baseURL>/api/users/<username>/
> > The password is posted to you in a json object.
> > Return 200 if the password is OK, 401 if not.  In both cases return no
> > data.
> >
> > I wrote a small python module which implements these methods which works
> > quite well.
> >
> > Reed
> >
> > From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stuart
> Jacobs <
> > stuart.jacobs at symbiotics.co.za>
> > Date: Wednesday, February 3, 2016 at 2:40 AM
> > To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> > Subject: [keycloak-user] User-Federation
> >
> > Hi Everyone,
> >
> > I have an application that runs on a postgresql database, keycloak has
> > been configured and has created all the required tables/columns in my
> > schema using liquibase on start up of the keycloak server.
> >
> > I need to authenticate users using the projects existing user table
> > obtaining the username and password from this table.
> >
> > I have had a look at the federation provider project under the example
> > projects but this still eludes me as to how I change the keycloak mapping
> > to use my own tables in postgress?
> >
> > Can someone please point me in the right direction or if someone has
> > implemented such a solution please share how you have done it?
> >
> > Thanks everyone.
> >
> >   Regards,
> >   Stuart Jacobs
> >
> >
> >
> >
> >
> >
> >
> > www.symbiotics.co.za
> >
> >
> ********************************************************************************
> > This email and any accompanying attachments may contain confidential and
> > proprietary information. This information is private and protected by law
> > and, accordingly, if you are not the intended recipient, you are
> requested
> > to delete this entire communication immediately and are notified that any
> > disclosure, copying or distribution of or taking any action based on this
> > information is prohibited.
> >
> > Emails cannot be guaranteed to be secure or free of errors or viruses.
> The
> > sender does not accept any liability or responsibility for any
> > interception, corruption, destruction, loss, late arrival or
> incompleteness
> > of or tampering or interference with any of the information contained in
> > this email or for its incorrect delivery or non-delivery for whatsoever
> > reason or for its effect on any electronic device of the recipient.
> >
> >
> ********************************************************************************
> >
> >
> > _______________________________________________
> > 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/20160211/d777c2bf/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Thu, 11 Feb 2016 11:17:14 -0200
> From: Renann Prado <prado.renann at gmail.com>
> Subject: Re: [keycloak-user] User-Federation
> To: Reed Lewis <RLewis at carbonite.com>
> Cc: keycloak-user at lists.jboss.org
> Message-ID:
>         <CAEBys6+i6jFdycaCg-rf9vC=
> T7chbrkKeWsfAbNvC2tidKdhZw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Everyone*
> On Feb 11, 2016 11:16, "Renann Prado" <prado.renann at gmail.com> wrote:
>
> > Is there any recommended way to make sure these endpoints won't be
> spammed
> > by an attacker? Looks like these endpoints need to be open to anyone.
> >
> > Thanks
> > On Feb 3, 2016 11:18, "Reed Lewis" <RLewis at carbonite.com> wrote:
> >
> >> If you use the federation provider listed here:
> >>
> >> [0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
> >> [1]: https://github.com/Smartling/keycloak-user-migration-provider
> >>
> >> You can specify a URL that will be called when a user needs to be
> >> validated.
> >>
> >> There are three requests that need to be implemented in your sever.
> >>
> >> GET <baseURL>/api/users/<username>/
> >> If the user exists, it should return a 200 with a json object with the
> >> return type ?application/json? with the following fields:
> >> username
> >> email
> >> emailVerified
> >> firstName
> >> lastName
> >> roles [?user?]
> >>
> >> If the user does not exist, return a 404
> >>
> >> HEAD <baseURL>/api/users/<username>/
> >> Always return 200
> >>
> >> POST <baseURL>/api/users/<username>/
> >> The password is posted to you in a json object.
> >> Return 200 if the password is OK, 401 if not.  In both cases return no
> >> data.
> >>
> >> I wrote a small python module which implements these methods which works
> >> quite well.
> >>
> >> Reed
> >>
> >> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stuart
> Jacobs
> >> <stuart.jacobs at symbiotics.co.za>
> >> Date: Wednesday, February 3, 2016 at 2:40 AM
> >> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> >> Subject: [keycloak-user] User-Federation
> >>
> >> Hi Everyone,
> >>
> >> I have an application that runs on a postgresql database, keycloak has
> >> been configured and has created all the required tables/columns in my
> >> schema using liquibase on start up of the keycloak server.
> >>
> >> I need to authenticate users using the projects existing user table
> >> obtaining the username and password from this table.
> >>
> >> I have had a look at the federation provider project under the example
> >> projects but this still eludes me as to how I change the keycloak
> mapping
> >> to use my own tables in postgress?
> >>
> >> Can someone please point me in the right direction or if someone has
> >> implemented such a solution please share how you have done it?
> >>
> >> Thanks everyone.
> >>
> >>   Regards,
> >>   Stuart Jacobs
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> www.symbiotics.co.za
> >>
> >>
> ********************************************************************************
> >> This email and any accompanying attachments may contain confidential and
> >> proprietary information. This information is private and protected by
> law
> >> and, accordingly, if you are not the intended recipient, you are
> requested
> >> to delete this entire communication immediately and are notified that
> any
> >> disclosure, copying or distribution of or taking any action based on
> this
> >> information is prohibited.
> >>
> >> Emails cannot be guaranteed to be secure or free of errors or viruses.
> >> The sender does not accept any liability or responsibility for any
> >> interception, corruption, destruction, loss, late arrival or
> incompleteness
> >> of or tampering or interference with any of the information contained in
> >> this email or for its incorrect delivery or non-delivery for whatsoever
> >> reason or for its effect on any electronic device of the recipient.
> >>
> >>
> ********************************************************************************
> >>
> >>
> >> _______________________________________________
> >> 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/20160211/6164ad32/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Thu, 11 Feb 2016 09:06:49 -0500
> From: Bill Burke <bburke at redhat.com>
> Subject: Re: [keycloak-user] Keycloak as a SAML SP: Is it possible to
>         configure Keycloak to use RSA-SHA256 as the algorithm to sign
>         assertions.
> To: keycloak-user at lists.jboss.org
> Message-ID: <56BC9579.8080102 at redhat.com>
> Content-Type: text/plain; charset="windows-1252"
>
> Where?  Keycloak Saml SP?  Keycloak Server interaction with an
> app/client?  Or Keycloak Server acting as an SP in a broker scenario?
>
> They all *should* support plugging in the algorithm.  Did you configure
> this correctly?
>
> On 2/11/2016 6:29 AM, Akshay Kini wrote:
> > Hi Folks,
> >
> > We are using Keycloak as a SAML SP.
> >
> > I notice that SAML Assertions are signed using rsa-sha1, could we
> > configure it to use RSA-SHA256?
> >
> > Thanks,
> > Regards,
> > Akshay
> >
> >
> > _______________________________________________
> > 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
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/573d1ced/attachment.html
>
> ------------------------------
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> End of keycloak-user Digest, Vol 26, Issue 56
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/07f54d5a/attachment-0001.html 

From leo.nunes at gjccorp.com.br  Fri Feb 12 07:10:08 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Fri, 12 Feb 2016 12:10:08 +0000
Subject: [keycloak-user] Failed to make identity provider oauth
 callback: javax.net.ssl.SSLHandshakeException
In-Reply-To: <CA+1OW+gbNtE3f+n5-_s5BB1AMEyHvgHAjkbHJs4Ti8ujQWrw7Q@mail.gmail.com>
Message-ID: <D2E35C71.265A3%leo.nunes@ojc.com.br>

It worked for me, now I can login with Facebook.
I had to export 3 root CA's from the default java cacerts keystore, them
import them into my keystore.
This is not the best way to fix the problem, but until we don't have a
flag on keycloak to indicate we want to use both our keystore and java
keystore this will work.

Certificates to export:
digicertglobalrootca
digicertassuredidrootca
digicerthighassuranceevrootca


How to export:
keytool -exportcert -alias digicertglobalrootca -keystore cacerts -file
jboss/ssl/default-jdk/digicertglobalrootca.crt

keytool -exportcert -alias digicertassuredidrootca -keystore cacerts -file
jboss/ssl/default-jdk/digicertassuredidrootca.crt
keytool -exportcert -alias digicertglobalrootca -keystore cacerts -file
jboss/ssl/default-jdk/digicerthighassuranceevrootca.crt

How to import into another keystore:
keytool -import -trustcacerts -alias digicertglobalrootca -keystore
jboss/ssl/eap-des1.yyy.com.br.keystore.jks -file
jboss/ssl/default-jdk/digicertglobalrootca.crt
keytool -import -trustcacerts -alias digicertassuredidrootca -keystore
jboss/ssl/eap-des1.yyy.com.br.keystore.jks -file
jboss/ssl/default-jdk/digicertassuredidrootca.crt
keytool -import -trustcacerts -alias digicerthighassuranceevrootca
-keystore jboss/ssl/eap-des1.yyy.com.br.keystore.jks -file
jboss/ssl/default-jdk/digicerthighassuranceevrootca.crt







On 12/02/16 08:44, "Marko Strukelj" <mstrukel at redhat.com> wrote:

>We could add such a flag, don't know how hard it would be to implement.
>
>In principle I agree about CA cert updates. But they are many, and for
>your customized truststore you may add only a few, and for big-name
>services. If CAs are revoked, then your integration will stop working
>as those services will start using new certs that you don't have in
>your truststore.
>
>It's quite unlikely OTOH to notice one of the 100 trusted-by-default
>CA that you never connect to, that can one day be used to forge a
>certificate for one of the services that you do use - that one you
>won't notice until you update Java.
>________________________________
>Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
>voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta
>mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela
>contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc?
>recebeu esta mensagem por engano, por favor avise imediatamente o
>remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua
>coopera??o.
>
>This message may contain confidential and/or privileged information. If
>you are not the addressee or authorized to receive this for the
>addressee, you must not use, copy, disclose or take any action based on
>this message or any information herein. If you have received this message
>in error, please advise the sender immediately by reply e-mail and delete
>this message. Thank you for your cooperation



From mstrukel at redhat.com  Fri Feb 12 07:16:13 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 12 Feb 2016 13:16:13 +0100
Subject: [keycloak-user] Failed to make identity provider oauth
	callback: javax.net.ssl.SSLHandshakeException
In-Reply-To: <D2E34CB9.26592%leo.nunes@ojc.com.br>
References: <CAJgngAf4-aAyu_aONLOiYC9Ap0LmAur7U-yn2pP7H4o2LKHsrw@mail.gmail.com>
	<D2E34CB9.26592%leo.nunes@ojc.com.br>
Message-ID: <CA+1OW+jUxA+wkpqGzB0u2ZCYWD8ELB6ZK+Nz9yPJDw5ymJVyuQ@mail.gmail.com>

Security is always at odds with convenience :)

For Facebook you can prepare your truststore like this:

curl http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt
> ~/digicertsha2high.crt
keytool -importcert -keystore truststore.jks -storetype JKS -file
~/digicertsha2high.crt -alias digicertSHA2HighCA


How I came to this?

By inspecting the certificate returned by Facebook you find it's issuer:

openssl s_client -connect graph.facebook.com:443 -showcerts </dev/null
2>/dev/null|openssl x509 -outform PEM > ~/graph.facebook.com.pem
keytool -importcert -keystore tempstore.jks -storetype JKS -file
~/graph.facebook.com.pem -alias facebook.com
(type some password, and inspect the certificate - no need to confirm it)

In certificate details there is URL to issuer CA certificate I used above.

It is issuer CA that your want in your truststore, rather than
graph.facebook.com certificate. That certificate is also part of
cacerts file where all the certificate trusted by default are located.


Which is the next point - it's easy to manually start with default
truststore, rather than empty one. Just copy the default truststore
and change its password:

cp $JAVA_HOME/jre/lib/security/cacerts truststore.jks
keytool -keystore truststore.jks -storepasswd

When asked for password type: 'changeit' - that's java truststore's password.
When asked for new password type whatever you want.

That's all there is to it.



On Fri, Feb 12, 2016 at 11:49 AM, LEONARDO NUNES
<leo.nunes at gjccorp.com.br> wrote:
> 1+ to include cacerts from Java by default.
>
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Reply-To: "stian at redhat.com" <stian at redhat.com>
> Date: sexta-feira, 12 de fevereiro de 2016 07:43
> To: Marko Strukelj <mstrukel at redhat.com>
> Cc: Marek Posolda <mposolda at redhat.com>, Leonardo Nunes
> <leo.nunes at gjccorp.com.br>, "keycloak-user at lists.jboss.org"
> <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Failed to make identity provider oauth
> callback: javax.net.ssl.SSLHandshakeException
>
>
> On 12 February 2016 at 10:04, Marko Strukelj <mstrukel at redhat.com> wrote:
>>
>> When using 'truststore' provider it is up to you to make sure to
>> include all the certificates you trust. Configuration via
>> -Djavax.net.ssl.trustStore works the same - no automatic inclusion of
>> cacerts. But it sounds like a good usability feature to add a flag
>> that would automatically include cacerts as well. The problem is - it
>> happens occasionally that some CAs turn out not to be trustworthy, and
>> blindly importing all cacerts exposes you to that risk.
>
>
> How about having a flag that is enabled by default that includes cacerts
> from Java? I'd actually think that update from CA certs are more likely
> going to happen by updating Java rather than manually maintaining a
> truststore.
>
>>
>> One detail to emphasize, with third party not-self-signed certificates
>> it's important to include the CA certificate used to create the
>> specific server certificate, rather than the server certificate
>> itself. Facebook servers use different short-lived server certificates
>> - and with two consecutive requests you may be presented with two
>> different server certificates - but they are all issued by the same
>> long-lived trusted CA.
>>
>>
>>
>> On Fri, Feb 12, 2016 at 8:07 AM, Marek Posolda <mposolda at redhat.com>
>> wrote:
>> > Facebook certificate should be signed by trusted authority, so it works
>> > with
>> > default JDK truststore. At least for me it always works.
>> >
>> > Shouldn't truststore SPI use both provided file + default JDK truststore
>> > by
>> > default? We may have flag to disable default JDK truststore, but not
>> > sure if
>> > it's ever needed. Also shouldn't we rewrite SimpleHTTP to use Apache
>> > HTTP
>> > client provided by HttpClientProvider SPI?
>> >
>> > Marek
>> >
>> >
>> > On 11/02/16 15:23, Stian Thorgersen wrote:
>> >
>> > Does it work if you don't specify the truststore? That will use the
>> > default
>> > truststore provided by the JDK.
>> >
>> > Also, does your truststore contain the required CA certs? For Facebook
>> > to
>> > work it'll have to contain the required CA's for their certs
>> >
>> > On 11 February 2016 at 14:09, LEONARDO NUNES <leo.nunes at gjccorp.com.br>
>> > wrote:
>> >>
>> >> Hi, i'm getting the error below when I try to login with Facebook.
>> >> I've followed the instructions at
>> >>
>> >> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore
>> >> and
>> >>
>> >> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337
>> >>
>> >> I was able to login with Facebook when trying at localhost. But at our
>> >> development server we are getting this error.
>> >>
>> >> We are using EAP in domain mode.
>> >>
>> >> The truststore I placed inside of keycloak-server.json
>> >> "truststore": {
>> >>         "file": {
>> >>             "file": "/home/soa/jboss/ssl/keycloak.jks",
>> >>             "password": "keycloak123",
>> >>             "hostname-verification-policy": "ANY",
>> >>             "disabled": false
>> >>         }
>> >>     }
>> >>
>> >>
>> >> #######
>> >>
>> >> ERRO:
>> >>
>> >>
>> >> 2016-02-11 10:44:53,927 ERROR
>> >> [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider]
>> >> (ajp-/192.168.162.73:8008-1) Failed to make identity provider oauth
>> >> callback: javax.net.ssl.SSLHandshakeException:
>> >> sun.security.validator.ValidatorException: PKIX path building failed:
>> >> sun.security.provider.certpath.SunCertPathBuilderException: unable to
>> >> find
>> >> valid certification path to requested target
>> >> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>> >> [jsse.jar:1.8.0_45]
>> >> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
>> >> [jsse.jar:1.8.0_45]
>> >> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
>> >> [jsse.jar:1.8.0_45]
>> >> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
>> >> [jsse.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
>> >> [jsse.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
>> >> [jsse.jar:1.8.0_45]
>> >> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
>> >> [jsse.jar:1.8.0_45]
>> >> at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
>> >> [jsse.jar:1.8.0_45]
>> >> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
>> >> [jsse.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
>> >> [jsse.jar:1.8.0_45]
>> >> at
>> >> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
>> >> [jsse.jar:1.8.0_45]
>> >> at
>> >> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
>> >> [jsse.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
>> >> [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
>> >> [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282)
>> >> [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257)
>> >> [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
>> >> [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
>> >> at
>> >>
>> >> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
>> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >> [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> >> [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >> [rt.jar:1.8.0_45]
>> >> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >>
>> >> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >>
>> >> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >>
>> >> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >>
>> >> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >>
>> >> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >>
>> >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >>
>> >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >>
>> >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >>
>> >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at
>> >>
>> >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
>> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
>> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>> >>
>> >> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
>> >> at
>> >>
>> >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >>
>> >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >>
>> >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>> >> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
>> >> at
>> >>
>> >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >>
>> >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >>
>> >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >>
>> >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >>
>> >> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
>> >> at
>> >>
>> >> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
>> >> at
>> >>
>> >> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
>> >> [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
>> >> at
>> >>
>> >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >>
>> >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >>
>> >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >>
>> >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >>
>> >> org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at
>> >> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
>> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
>> >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
>> >> Caused by: sun.security.validator.ValidatorException: PKIX path
>> >> building
>> >> failed: sun.security.provider.certpath.SunCertPathBuilderException:
>> >> unable
>> >> to find valid certification path to requested target
>> >> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
>> >> [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
>> >> [rt.jar:1.8.0_45]
>> >> at sun.security.validator.Validator.validate(Validator.java:260)
>> >> [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
>> >> [jsse.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
>> >> [jsse.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
>> >> [jsse.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
>> >> [jsse.jar:1.8.0_45]
>> >> ... 50 more
>> >> Caused by: sun.security.provider.certpath.SunCertPathBuilderException:
>> >> unable to find valid certification path to requested target
>> >> at
>> >>
>> >> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
>> >> [rt.jar:1.8.0_45]
>> >> at
>> >>
>> >> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
>> >> [rt.jar:1.8.0_45]
>> >> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
>> >> [rt.jar:1.8.0_45]
>> >> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
>> >> [rt.jar:1.8.0_45]
>> >> ... 56 more
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Leonardo Nunes
>> >> ________________________________
>> >> Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
>> >> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta
>> >> mensagem,
>> >> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou
>> >> tomar
>> >> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem
>> >> por
>> >> engano, por favor avise imediatamente o remetente, respondendo o e-mail
>> >> e em
>> >> seguida apague-o. Agradecemos sua coopera??o.
>> >>
>> >> This message may contain confidential and/or privileged information. If
>> >> you are not the addressee or authorized to receive this for the
>> >> addressee,
>> >> you must not use, copy, disclose or take any action based on this
>> >> message or
>> >> any information herein. If you have received this message in error,
>> >> please
>> >> advise the sender immediately by reply e-mail and delete this message.
>> >> Thank
>> >> you for your cooperation
>> >>
>> >> _______________________________________________
>> >> 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 tdudgeon.ml at gmail.com  Fri Feb 12 09:03:25 2016
From: tdudgeon.ml at gmail.com (Tim Dudgeon)
Date: Fri, 12 Feb 2016 14:03:25 +0000
Subject: [keycloak-user] import not working in 1.8
Message-ID: <56BDE62D.5070204@gmail.com>

I've hit an issue with import. The command I used to use to import a 
realm with 1.7.0 now gives an error with 1.8.1, but from reading the 
docs all the options seem to be valid. Could someone point to what has 
changed?

The command I'm using is

/opt/jboss/keycloak/bin/standalone.sh -b 0.0.0.0 
-Dkeycloak.migration.action=import 
-Dkeycloak.migration.provider=singleFile 
-Dkeycloak.migration.file=/tmp/json/yyy.json 
-Dkeycloak.migration.strategy=OVERWRITE_EXISTING

Or to be more correct, I'm doing this in Docker, and it can be 
reproduced like this:

docker run -it --rm -v $PWD:/tmp/json jboss/keycloak:1.8.1.Final 
/opt/jboss/keycloak/bin/standalone.sh -b 0.0.0.0 
-Dkeycloak.migration.action=import 
-Dkeycloak.migration.provider=singleFile 
-Dkeycloak.migration.file=/tmp/json/yyy.json 
-Dkeycloak.migration.strategy=OVERWRITE_EXISTING

which tells me that I've specified an invalid option. It works fine if I 
use the 1.7.0.Final image.

Tim



From sthorger at redhat.com  Fri Feb 12 09:19:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 15:19:56 +0100
Subject: [keycloak-user] import not working in 1.8
In-Reply-To: <56BDE62D.5070204@gmail.com>
References: <56BDE62D.5070204@gmail.com>
Message-ID: <CAJgngAdn5OW+qa4XzJY8OQsy=E7t4744PSiKQmSQ8Z5+WQVxeg@mail.gmail.com>

The image was updated to use an entrypoint, so you can drop "$PWD:/tmp/json
jboss/keycloak:1.8.1.Final \ /opt/jboss/keycloak/bin/standalone.sh", and
just run it with:

docker run -it --rm -v -b 0.0.0.0
-Dkeycloak.migration.action=import
-Dkeycloak.migration.provider=singleFile
-Dkeycloak.migration.file=/tmp/json/yyy.json
-Dkeycloak.migration.strategy=OVERWRITE_EXISTING

On 12 February 2016 at 15:03, Tim Dudgeon <tdudgeon.ml at gmail.com> wrote:

> I've hit an issue with import. The command I used to use to import a
> realm with 1.7.0 now gives an error with 1.8.1, but from reading the
> docs all the options seem to be valid. Could someone point to what has
> changed?
>
> The command I'm using is
>
> /opt/jboss/keycloak/bin/standalone.sh -b 0.0.0.0
> -Dkeycloak.migration.action=import
> -Dkeycloak.migration.provider=singleFile
> -Dkeycloak.migration.file=/tmp/json/yyy.json
> -Dkeycloak.migration.strategy=OVERWRITE_EXISTING
>
> Or to be more correct, I'm doing this in Docker, and it can be
> reproduced like this:
>
> docker run -it --rm -v $PWD:/tmp/json jboss/keycloak:1.8.1.Final
> /opt/jboss/keycloak/bin/standalone.sh -b 0.0.0.0
> -Dkeycloak.migration.action=import
> -Dkeycloak.migration.provider=singleFile
> -Dkeycloak.migration.file=/tmp/json/yyy.json
> -Dkeycloak.migration.strategy=OVERWRITE_EXISTING
>
> which tells me that I've specified an invalid option. It works fine if I
> use the 1.7.0.Final image.
>
> Tim
>
>
> _______________________________________________
> 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/20160212/378e3eec/attachment.html 

From tdudgeon.ml at gmail.com  Fri Feb 12 09:56:52 2016
From: tdudgeon.ml at gmail.com (Tim Dudgeon)
Date: Fri, 12 Feb 2016 14:56:52 +0000
Subject: [keycloak-user] import not working in 1.8
In-Reply-To: <CAJgngAdn5OW+qa4XzJY8OQsy=E7t4744PSiKQmSQ8Z5+WQVxeg@mail.gmail.com>
References: <56BDE62D.5070204@gmail.com>
	<CAJgngAdn5OW+qa4XzJY8OQsy=E7t4744PSiKQmSQ8Z5+WQVxeg@mail.gmail.com>
Message-ID: <56BDF2B4.4040102@gmail.com>

Great, thanks. That works.

Tim

On 12/02/2016 14:19, Stian Thorgersen wrote:
> The image was updated to use an entrypoint, so you can drop 
> "$PWD:/tmp/json jboss/keycloak:1.8.1.Final \ 
> /opt/jboss/keycloak/bin/standalone.sh", and just run it with:
>
> docker run -it --rm -v -b 0.0.0.0
> -Dkeycloak.migration.action=import
> -Dkeycloak.migration.provider=singleFile
> -Dkeycloak.migration.file=/tmp/json/yyy.json
> -Dkeycloak.migration.strategy=OVERWRITE_EXISTING
>
> On 12 February 2016 at 15:03, Tim Dudgeon <tdudgeon.ml at gmail.com 
> <mailto:tdudgeon.ml at gmail.com>> wrote:
>
>     I've hit an issue with import. The command I used to use to import a
>     realm with 1.7.0 now gives an error with 1.8.1, but from reading the
>     docs all the options seem to be valid. Could someone point to what has
>     changed?
>
>     The command I'm using is
>
>     /opt/jboss/keycloak/bin/standalone.sh -b 0.0.0.0
>     -Dkeycloak.migration.action=import
>     -Dkeycloak.migration.provider=singleFile
>     -Dkeycloak.migration.file=/tmp/json/yyy.json
>     -Dkeycloak.migration.strategy=OVERWRITE_EXISTING
>
>     Or to be more correct, I'm doing this in Docker, and it can be
>     reproduced like this:
>
>     docker run -it --rm -v $PWD:/tmp/json jboss/keycloak:1.8.1.Final
>     /opt/jboss/keycloak/bin/standalone.sh -b 0.0.0.0
>     -Dkeycloak.migration.action=import
>     -Dkeycloak.migration.provider=singleFile
>     -Dkeycloak.migration.file=/tmp/json/yyy.json
>     -Dkeycloak.migration.strategy=OVERWRITE_EXISTING
>
>     which tells me that I've specified an invalid option. It works
>     fine if I
>     use the 1.7.0.Final image.
>
>     Tim
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/8c3f9bc1/attachment.html 

From tdudgeon.ml at gmail.com  Fri Feb 12 10:14:27 2016
From: tdudgeon.ml at gmail.com (Tim Dudgeon)
Date: Fri, 12 Feb 2016 15:14:27 +0000
Subject: [keycloak-user] initialising docker
Message-ID: <56BDF6D3.2020105@gmail.com>

I've been struggling with a clean way to initialize the keycloak docker 
container.
I need to import a realm definition, and the only way I can find is it 
start the image with the import options, wait for this to complete so 
that the database is populated and then to Ctrl-C out and to restart the 
container proper, which is hardly automatable.
With 1.8 this also needs to include defining the admin user.

Is there a cleaner way of achieving this?
For instance, with the postgres docker images you just put any 
initialisation *.sql or *.sh scripts in a specific directory and they 
get executed first time the server starts.

Tim

From robin1233 at gmail.com  Fri Feb 12 12:10:15 2016
From: robin1233 at gmail.com (robinfernandes .)
Date: Fri, 12 Feb 2016 12:10:15 -0500
Subject: [keycloak-user] Quick clarification about Offline tokens
Message-ID: <CAFOTW4ZPEnuM-=hOP7rHA5e3VGajdJEF975cwgBq_LYRzyfo2g@mail.gmail.com>

Hi Everyone,

So the scenario that I am trying to understand is as follows:

1. I get an offline token and I try to refresh my token pair
(access,refresh) using this offline token.
2. Will I get a new offline token? Or will Keycloak see that you passed in
an offline token so it will return the same offline token back?

The tests that I performed I saw it returning a new offline token each
time. Is that a correct understanding?
Is there any parameter I can pass to the token refresh call so that it
gives me the same offline token back?

Thanks,
Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/c25691bd/attachment.html 

From darkness.renann at gmail.com  Fri Feb 12 16:21:56 2016
From: darkness.renann at gmail.com (Renann Prado)
Date: Fri, 12 Feb 2016 19:21:56 -0200
Subject: [keycloak-user] Cordova + Keycloak + Native Facebook login
Message-ID: <CAEBys6K2fDC643abUfVUTO2T8pnEg9_+7XATUJ7hvJLRysJe-Q@mail.gmail.com>

Is Keycloak supporting native facebook already?
I found at least 2 two-year old threads talking about native facebook
login, but none of them seem to have a solution.

Renann Prado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/f9967feb/attachment.html 

From bburke at redhat.com  Fri Feb 12 18:13:49 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 12 Feb 2016 18:13:49 -0500
Subject: [keycloak-user] Keycloak as a SAML SP: Is it possible to
 configure Keycloak to use RSA-SHA256 as the algorithm to sign assertions.
In-Reply-To: <CAFtx=Tnutkf-X-bHjKXuOdiC1kRh-eM67ZnCmJ7ikuNrEEiXRg@mail.gmail.com>
References: <CAFtx=Tk2X-uQDuFbO5f_rEHRHkdNLPE7ArtMW3uLc-Q0_FJwgg@mail.gmail.com>
	<CAFtx=Tnutkf-X-bHjKXuOdiC1kRh-eM67ZnCmJ7ikuNrEEiXRg@mail.gmail.com>
Message-ID: <56BE672D.8090805@redhat.com>

So, you're not using keycloak-server, just our SAML client SP adapter?

http://keycloak.github.io/docs/userguide/saml-client-adapter/html/adapter-config.html#d4e124

You can set the signature algorithm there.  The IDP section is basically 
describing what the IDP expects when you communicate to it.

On 2/12/2016 6:43 AM, Akshay Kini wrote:
> Hi Bill,
>
> Thanks for looking into this.
>
> The usecase is:
>
> Keycloak is an SP and it is sending an AuthnRequest via HTTP Post. 
> This AuthnRequest is always using RSA-SHA1 for signing.
>
> I have configured the Keycloak config file as follows:
> <keycloak-saml-adapter>
>     <SP entityID="exampleEntityID"
>         sslPolicy="NONE"
>         logoutPage="/logout.jsp"
> nameIDPolicyFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>         forceAuthentication="false"
>         signatureAlgorithm="RSA_SHA256">
>
>
> In-fact the SP element doesn't have the "signatureAlgorithm" 
> documented anywhere in the SAML Client Apapter Reference Guide (it 
> only exists for the IDP).
>
> Now this is a bit of unfamiliar territory for me, but I looked into 
> the Keycloak Code base (master):
> I see that the org.keycloak.adapters.saml.config.parsers.SPXmlParser 
> doesn't deal with ConfigXmlConstants.SIGNATURE_ALGORITHM_ATTR while 
> the IDPXmlParser does.
>
>
> Again, thanks for looking into this.
>
> P.S. Sorry to all the mailing list subscribers, this "chain" might get 
> broken despite me changing the subject. I am not sure how to fix that 
> when using Gmail and subscribing to a digest mailing-list. Please send 
> a direct e-mail to me if you know how to fix that.
>
> Thanks,
> Regards,
> Akshay
>
>
> On Thu, Feb 11, 2016 at 7:36 PM, 
> <keycloak-user-request at lists.jboss.org 
> <mailto:keycloak-user-request at lists.jboss.org>> wrote:
>
>     Send keycloak-user mailing list submissions to
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>
>     To subscribe or unsubscribe via the World Wide Web, visit
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>     or, via email, send a message with subject or body 'help' to
>     keycloak-user-request at lists.jboss.org
>     <mailto:keycloak-user-request at lists.jboss.org>
>
>     You can reach the person managing the list at
>     keycloak-user-owner at lists.jboss.org
>     <mailto:keycloak-user-owner at lists.jboss.org>
>
>     When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of keycloak-user digest..."
>
>
>     Today's Topics:
>
>        1. Re: User-Federation (Renann Prado)
>        2. Re: User-Federation (Renann Prado)
>        3. Re: Keycloak as a SAML SP: Is it possible to configure
>           Keycloak to use RSA-SHA256 as the algorithm to sign assertions.
>           (Bill Burke)
>
>
>     ----------------------------------------------------------------------
>
>     Message: 1
>     Date: Thu, 11 Feb 2016 11:16:29 -0200
>     From: Renann Prado <prado.renann at gmail.com
>     <mailto:prado.renann at gmail.com>>
>     Subject: Re: [keycloak-user] User-Federation
>     To: Reed Lewis <RLewis at carbonite.com <mailto:RLewis at carbonite.com>>
>     Cc: keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>
>     Message-ID:
>     <CAEBys6KM1-n6wFqTJAAqb_aYaQdZwuiaUz2AspF5d-8Za=E9wQ at mail.gmail.com <mailto:E9wQ at mail.gmail.com>>
>     Content-Type: text/plain; charset="utf-8"
>
>     Is there any recommended way to make sure these endpoints won't be
>     spammed
>     by an attacker? Looks like these endpoints need to be open to anyone.
>
>     Thanks
>     On Feb 3, 2016 11:18, "Reed Lewis" <RLewis at carbonite.com
>     <mailto:RLewis at carbonite.com>> wrote:
>
>     > If you use the federation provider listed here:
>     >
>     > [0]:
>     http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
>     > [1]: https://github.com/Smartling/keycloak-user-migration-provider
>     >
>     > You can specify a URL that will be called when a user needs to be
>     > validated.
>     >
>     > There are three requests that need to be implemented in your sever.
>     >
>     > GET <baseURL>/api/users/<username>/
>     > If the user exists, it should return a 200 with a json object
>     with the
>     > return type ?application/json? with the following fields:
>     > username
>     > email
>     > emailVerified
>     > firstName
>     > lastName
>     > roles [?user?]
>     >
>     > If the user does not exist, return a 404
>     >
>     > HEAD <baseURL>/api/users/<username>/
>     > Always return 200
>     >
>     > POST <baseURL>/api/users/<username>/
>     > The password is posted to you in a json object.
>     > Return 200 if the password is OK, 401 if not.  In both cases
>     return no
>     > data.
>     >
>     > I wrote a small python module which implements these methods
>     which works
>     > quite well.
>     >
>     > Reed
>     >
>     > From: <keycloak-user-bounces at lists.jboss.org
>     <mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of
>     Stuart Jacobs <
>     > stuart.jacobs at symbiotics.co.za
>     <mailto:stuart.jacobs at symbiotics.co.za>>
>     > Date: Wednesday, February 3, 2016 at 2:40 AM
>     > To: "keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>"
>     <keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>>
>     > Subject: [keycloak-user] User-Federation
>     >
>     > Hi Everyone,
>     >
>     > I have an application that runs on a postgresql database,
>     keycloak has
>     > been configured and has created all the required tables/columns
>     in my
>     > schema using liquibase on start up of the keycloak server.
>     >
>     > I need to authenticate users using the projects existing user table
>     > obtaining the username and password from this table.
>     >
>     > I have had a look at the federation provider project under the
>     example
>     > projects but this still eludes me as to how I change the
>     keycloak mapping
>     > to use my own tables in postgress?
>     >
>     > Can someone please point me in the right direction or if someone has
>     > implemented such a solution please share how you have done it?
>     >
>     > Thanks everyone.
>     >
>     >   Regards,
>     >   Stuart Jacobs
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     > www.symbiotics.co.za <http://www.symbiotics.co.za>
>     >
>     >
>     ********************************************************************************
>     > This email and any accompanying attachments may contain
>     confidential and
>     > proprietary information. This information is private and
>     protected by law
>     > and, accordingly, if you are not the intended recipient, you are
>     requested
>     > to delete this entire communication immediately and are notified
>     that any
>     > disclosure, copying or distribution of or taking any action
>     based on this
>     > information is prohibited.
>     >
>     > Emails cannot be guaranteed to be secure or free of errors or
>     viruses. The
>     > sender does not accept any liability or responsibility for any
>     > interception, corruption, destruction, loss, late arrival or
>     incompleteness
>     > of or tampering or interference with any of the information
>     contained in
>     > this email or for its incorrect delivery or non-delivery for
>     whatsoever
>     > reason or for its effect on any electronic device of the recipient.
>     >
>     >
>     ********************************************************************************
>     >
>     >
>     > _______________________________________________
>     > keycloak-user mailing list
>     > keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-user
>     >
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>     URL:
>     http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/d777c2bf/attachment-0001.html
>
>     ------------------------------
>
>     Message: 2
>     Date: Thu, 11 Feb 2016 11:17:14 -0200
>     From: Renann Prado <prado.renann at gmail.com
>     <mailto:prado.renann at gmail.com>>
>     Subject: Re: [keycloak-user] User-Federation
>     To: Reed Lewis <RLewis at carbonite.com <mailto:RLewis at carbonite.com>>
>     Cc: keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>
>     Message-ID:
>            
>     <CAEBys6+i6jFdycaCg-rf9vC=T7chbrkKeWsfAbNvC2tidKdhZw at mail.gmail.com <mailto:T7chbrkKeWsfAbNvC2tidKdhZw at mail.gmail.com>>
>     Content-Type: text/plain; charset="utf-8"
>
>     Everyone*
>     On Feb 11, 2016 11:16, "Renann Prado" <prado.renann at gmail.com
>     <mailto:prado.renann at gmail.com>> wrote:
>
>     > Is there any recommended way to make sure these endpoints won't
>     be spammed
>     > by an attacker? Looks like these endpoints need to be open to
>     anyone.
>     >
>     > Thanks
>     > On Feb 3, 2016 11:18, "Reed Lewis" <RLewis at carbonite.com
>     <mailto:RLewis at carbonite.com>> wrote:
>     >
>     >> If you use the federation provider listed here:
>     >>
>     >> [0]:
>     http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
>     >> [1]: https://github.com/Smartling/keycloak-user-migration-provider
>     >>
>     >> You can specify a URL that will be called when a user needs to be
>     >> validated.
>     >>
>     >> There are three requests that need to be implemented in your sever.
>     >>
>     >> GET <baseURL>/api/users/<username>/
>     >> If the user exists, it should return a 200 with a json object
>     with the
>     >> return type ?application/json? with the following fields:
>     >> username
>     >> email
>     >> emailVerified
>     >> firstName
>     >> lastName
>     >> roles [?user?]
>     >>
>     >> If the user does not exist, return a 404
>     >>
>     >> HEAD <baseURL>/api/users/<username>/
>     >> Always return 200
>     >>
>     >> POST <baseURL>/api/users/<username>/
>     >> The password is posted to you in a json object.
>     >> Return 200 if the password is OK, 401 if not.  In both cases
>     return no
>     >> data.
>     >>
>     >> I wrote a small python module which implements these methods
>     which works
>     >> quite well.
>     >>
>     >> Reed
>     >>
>     >> From: <keycloak-user-bounces at lists.jboss.org
>     <mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of
>     Stuart Jacobs
>     >> <stuart.jacobs at symbiotics.co.za
>     <mailto:stuart.jacobs at symbiotics.co.za>>
>     >> Date: Wednesday, February 3, 2016 at 2:40 AM
>     >> To: "keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>"
>     <keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>>
>     >> Subject: [keycloak-user] User-Federation
>     >>
>     >> Hi Everyone,
>     >>
>     >> I have an application that runs on a postgresql database,
>     keycloak has
>     >> been configured and has created all the required tables/columns
>     in my
>     >> schema using liquibase on start up of the keycloak server.
>     >>
>     >> I need to authenticate users using the projects existing user table
>     >> obtaining the username and password from this table.
>     >>
>     >> I have had a look at the federation provider project under the
>     example
>     >> projects but this still eludes me as to how I change the
>     keycloak mapping
>     >> to use my own tables in postgress?
>     >>
>     >> Can someone please point me in the right direction or if
>     someone has
>     >> implemented such a solution please share how you have done it?
>     >>
>     >> Thanks everyone.
>     >>
>     >>   Regards,
>     >>   Stuart Jacobs
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >> www.symbiotics.co.za <http://www.symbiotics.co.za>
>     >>
>     >>
>     ********************************************************************************
>     >> This email and any accompanying attachments may contain
>     confidential and
>     >> proprietary information. This information is private and
>     protected by law
>     >> and, accordingly, if you are not the intended recipient, you
>     are requested
>     >> to delete this entire communication immediately and are
>     notified that any
>     >> disclosure, copying or distribution of or taking any action
>     based on this
>     >> information is prohibited.
>     >>
>     >> Emails cannot be guaranteed to be secure or free of errors or
>     viruses.
>     >> The sender does not accept any liability or responsibility for any
>     >> interception, corruption, destruction, loss, late arrival or
>     incompleteness
>     >> of or tampering or interference with any of the information
>     contained in
>     >> this email or for its incorrect delivery or non-delivery for
>     whatsoever
>     >> reason or for its effect on any electronic device of the recipient.
>     >>
>     >>
>     ********************************************************************************
>     >>
>     >>
>     >> _______________________________________________
>     >> keycloak-user mailing list
>     >> keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>     >>
>     >
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>     URL:
>     http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/6164ad32/attachment-0001.html
>
>     ------------------------------
>
>     Message: 3
>     Date: Thu, 11 Feb 2016 09:06:49 -0500
>     From: Bill Burke <bburke at redhat.com <mailto:bburke at redhat.com>>
>     Subject: Re: [keycloak-user] Keycloak as a SAML SP: Is it possible to
>             configure Keycloak to use RSA-SHA256 as the algorithm to sign
>             assertions.
>     To: keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>
>     Message-ID: <56BC9579.8080102 at redhat.com
>     <mailto:56BC9579.8080102 at redhat.com>>
>     Content-Type: text/plain; charset="windows-1252"
>
>     Where?  Keycloak Saml SP?  Keycloak Server interaction with an
>     app/client?  Or Keycloak Server acting as an SP in a broker scenario?
>
>     They all *should* support plugging in the algorithm.  Did you
>     configure
>     this correctly?
>
>     On 2/11/2016 6:29 AM, Akshay Kini wrote:
>     > Hi Folks,
>     >
>     > We are using Keycloak as a SAML SP.
>     >
>     > I notice that SAML Assertions are signed using rsa-sha1, could we
>     > configure it to use RSA-SHA256?
>     >
>     > Thanks,
>     > Regards,
>     > Akshay
>     >
>     >
>     > _______________________________________________
>     > keycloak-user mailing list
>     > keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>     URL:
>     http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/573d1ced/attachment.html
>
>     ------------------------------
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>     End of keycloak-user Digest, Vol 26, Issue 56
>     *********************************************
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/0e8870a7/attachment-0001.html 

From jessec at dnbcloud.com  Fri Feb 12 20:48:38 2016
From: jessec at dnbcloud.com (Jesse Chahal)
Date: Fri, 12 Feb 2016 17:48:38 -0800
Subject: [keycloak-user] Extending Themes via SPI
Message-ID: <CAP26fkcNzdOGsatSW31MTnhz=x4uqQ_vg6Pxj2-z_7QpFbhYCQ@mail.gmail.com>

So I'm also in a similar situation here where our front-end team will not
even consider looking into FTL theme engine that was used in keycloak. They
will reject keycloak as a good solution unless we can reimplement the login
screen in an entirely different technology. I'm still trying to convince
people that using the current theming engine is a better choice but I don't
think we'll even be able to get there unless I can help them do a
comparison of the two implementations. We don't currently care about
registration, social auth, password reset, etc... through the login screen.
Most of this will be done through the keycloak admin client by an
administrator in our cases. This means I need a way to actually use the
Login SPI to able to redirect to a login page hosted on a different server.
Are there any suggestions of places where I could start looking at in order
to implement a custom Login page hosted on a different server. The reason I
specify different server (same tld domain) is I'm also a bit worried about
CORS issues (hopefully we'll be fine).


Thanks,
Jesse

On Fri, Feb 12, 2016 at 1:43 AM, <keycloak-user-request at lists.jboss.org>
wrote:

> Send keycloak-user mailing list submissions to
>         keycloak-user at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
> or, via email, send a message with subject or body 'help' to
>         keycloak-user-request at lists.jboss.org
>
> You can reach the person managing the list at
>         keycloak-user-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of keycloak-user digest..."
>
>
> Today's Topics:
>
>    1. Re: Extending Themes via SPI (Stian Thorgersen)
>    2. Re: Failed to make identity provider oauth        callback:
>       javax.net.ssl.SSLHandshakeException (Marko Strukelj)
>    3. Re: Failed to make identity provider oauth        callback:
>       javax.net.ssl.SSLHandshakeException (Stian Thorgersen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 12 Feb 2016 09:53:56 +0100
> From: Stian Thorgersen <sthorger at redhat.com>
> Subject: Re: [keycloak-user] Extending Themes via SPI
> To: Sarp Kaya <akaya at expedia.com>
> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Message-ID:
>         <
> CAJgngAfBrCv2B_A81Yc3sbBQbWz8O6JrXEa6SUWh8xG91EDDPg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> No, you can create a theme that contains stylesheets and freemarker
> templates (if you need to change those) and deploy it to Keycloak. Please
> read
> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html
> and take a look at the themes examples in our examples download.
>
> On 12 February 2016 at 09:47, Sarp Kaya <akaya at expedia.com> wrote:
>
> > Okay but what you are saying is done directly on the Keycloak source code
> > which is then built and deployed, rather than extending classes and then
> > deploying directly to a Keycloak instance?
> >
> > From: Stian Thorgersen <sthorger at redhat.com>
> > Reply-To: "stian at redhat.com" <stian at redhat.com>
> > Date: Friday, February 12, 2016 at 6:29 PM
> >
> > To: Abdullah Sarp Kaya <akaya at expedia.com>
> > Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> > Subject: Re: [keycloak-user] Extending Themes via SPI
> >
> > There's a lot more to the login on Keycloak than a simple JSP page used
> > for JEE form-based authentication. We have user registration, password
> > recovery, OTP support, remember me, etc, etc..
> >
> > Take the look and feel (stylesheet) of your JSP login screen and apply it
> > to Keycloak with a custom theme. That's the simplest, quickest and best
> > option.
> >
> > On 12 February 2016 at 09:15, Sarp Kaya <akaya at expedia.com> wrote:
> >
> >>
> >> We have internal front end libraries that works with JSP only. From the
> >> sounds of SPI, I thought that I could use JSP and our internal libraries
> >> instead of FreeMarker templates. Also because our JSP login screen is
> >> almost ready it wouldn?t take much time to just deploy it (that?s what I
> >> thought).
> >>
> >> From: Stian Thorgersen <sthorger at redhat.com>
> >> Reply-To: "stian at redhat.com" <stian at redhat.com>
> >> Date: Friday, February 12, 2016 at 5:54 PM
> >> To: Abdullah Sarp Kaya <akaya at expedia.com>
> >> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> >> Subject: Re: [keycloak-user] Extending Themes via SPI
> >>
> >> What are you actually trying to achieve? We mainly support modifying the
> >> FreeMarker templates and stylesheets. Beyond that you may in theory be
> able
> >> to re-implement it all to replace FreeMarker with something else, but I
> >> don't see why you would want to and it would be a significant amount of
> >> work, and also maintenance.
> >>
> >> On 12 February 2016 at 07:08, Sarp Kaya <akaya at expedia.com> wrote:
> >>
> >>> Hi all,
> >>>
> >>> In regards to Extending Themes via SPI all I found is this
> documentation:
> >>>
> >>>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html
> >>>  and
> >>>
> >>> <
> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450
> >
> >>>
> >>>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2450
> >>> I found it a little less describing.
> >>>
> >>> When I implement those two classes, where do I put the new implemented
> >>> classes? How do I deploy them?
> >>> Can I also use Spring mvc and JSP and few maven dependencies instead of
> >>> freemarker?
> >>>
> >>> I also tried to find an example to extend theme using SPI but there
> >>> seems to be none. It would be really nice if you could provide a sample
> >>> hello world.
> >>>
> >>> Thank you very much,
> >>> Sarp Kaya
> >>>
> >>> _______________________________________________
> >>> 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/20160212/dd16d2fc/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Fri, 12 Feb 2016 10:04:04 +0100
> From: Marko Strukelj <mstrukel at redhat.com>
> Subject: Re: [keycloak-user] Failed to make identity provider oauth
>         callback: javax.net.ssl.SSLHandshakeException
> To: Marek Posolda <mposolda at redhat.com>
> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>,
>         LEONARDO NUNES <leo.nunes at gjccorp.com.br>
> Message-ID:
>         <
> CA+1OW+gXfMSC+CiLo3vCSvxt0M5Gt9Qp_9TV7AiWcsfBW+DA9Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> When using 'truststore' provider it is up to you to make sure to
> include all the certificates you trust. Configuration via
> -Djavax.net.ssl.trustStore works the same - no automatic inclusion of
> cacerts. But it sounds like a good usability feature to add a flag
> that would automatically include cacerts as well. The problem is - it
> happens occasionally that some CAs turn out not to be trustworthy, and
> blindly importing all cacerts exposes you to that risk.
>
> One detail to emphasize, with third party not-self-signed certificates
> it's important to include the CA certificate used to create the
> specific server certificate, rather than the server certificate
> itself. Facebook servers use different short-lived server certificates
> - and with two consecutive requests you may be presented with two
> different server certificates - but they are all issued by the same
> long-lived trusted CA.
>
>
> On Fri, Feb 12, 2016 at 8:07 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
> > Facebook certificate should be signed by trusted authority, so it works
> with
> > default JDK truststore. At least for me it always works.
> >
> > Shouldn't truststore SPI use both provided file + default JDK truststore
> by
> > default? We may have flag to disable default JDK truststore, but not
> sure if
> > it's ever needed. Also shouldn't we rewrite SimpleHTTP to use Apache HTTP
> > client provided by HttpClientProvider SPI?
> >
> > Marek
> >
> >
> > On 11/02/16 15:23, Stian Thorgersen wrote:
> >
> > Does it work if you don't specify the truststore? That will use the
> default
> > truststore provided by the JDK.
> >
> > Also, does your truststore contain the required CA certs? For Facebook to
> > work it'll have to contain the required CA's for their certs
> >
> > On 11 February 2016 at 14:09, LEONARDO NUNES <leo.nunes at gjccorp.com.br>
> > wrote:
> >>
> >> Hi, i'm getting the error below when I try to login with Facebook.
> >> I've followed the instructions at
> >>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore
> >> and
> >>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337
> >>
> >> I was able to login with Facebook when trying at localhost. But at our
> >> development server we are getting this error.
> >>
> >> We are using EAP in domain mode.
> >>
> >> The truststore I placed inside of keycloak-server.json
> >> "truststore": {
> >>         "file": {
> >>             "file": "/home/soa/jboss/ssl/keycloak.jks",
> >>             "password": "keycloak123",
> >>             "hostname-verification-policy": "ANY",
> >>             "disabled": false
> >>         }
> >>     }
> >>
> >>
> >> #######
> >>
> >> ERRO:
> >>
> >>
> >> 2016-02-11 10:44:53,927 ERROR
> >> [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider]
> >> (ajp-/192.168.162.73:8008-1) Failed to make identity provider oauth
> >> callback: javax.net.ssl.SSLHandshakeException:
> >> sun.security.validator.ValidatorException: PKIX path building failed:
> >> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find
> >> valid certification path to requested target
> >> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
> >> [jsse.jar:1.8.0_45]
> >> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
> >> [jsse.jar:1.8.0_45]
> >> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
> >> [jsse.jar:1.8.0_45]
> >> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
> >> at
> >>
> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >> [rt.jar:1.8.0_45]
> >> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
> >> at
> >>
> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at
> >>
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> >>
> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
> >> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
> >> at
> >>
> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
> >> at
> >>
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> >> [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
> >> at
> >>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> >>
> org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> >> Caused by: sun.security.validator.ValidatorException: PKIX path building
> >> failed: sun.security.provider.certpath.SunCertPathBuilderException:
> unable
> >> to find valid certification path to requested target
> >> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
> >> [rt.jar:1.8.0_45]
> >> at sun.security.validator.Validator.validate(Validator.java:260)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> >> [jsse.jar:1.8.0_45]
> >> at
> >>
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
> >> [jsse.jar:1.8.0_45]
> >> ... 50 more
> >> Caused by: sun.security.provider.certpath.SunCertPathBuilderException:
> >> unable to find valid certification path to requested target
> >> at
> >>
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
> >> [rt.jar:1.8.0_45]
> >> at
> >>
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
> >> [rt.jar:1.8.0_45]
> >> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
> >> [rt.jar:1.8.0_45]
> >> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
> >> [rt.jar:1.8.0_45]
> >> ... 56 more
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Leonardo Nunes
> >> ________________________________
> >> Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
> >> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta
> mensagem,
> >> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou
> tomar
> >> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem
> por
> >> engano, por favor avise imediatamente o remetente, respondendo o e-mail
> e em
> >> seguida apague-o. Agradecemos sua coopera??o.
> >>
> >> This message may contain confidential and/or privileged information. If
> >> you are not the addressee or authorized to receive this for the
> addressee,
> >> you must not use, copy, disclose or take any action based on this
> message or
> >> any information herein. If you have received this message in error,
> please
> >> advise the sender immediately by reply e-mail and delete this message.
> Thank
> >> you for your cooperation
> >>
> >> _______________________________________________
> >> 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
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 12 Feb 2016 10:43:18 +0100
> From: Stian Thorgersen <sthorger at redhat.com>
> Subject: Re: [keycloak-user] Failed to make identity provider oauth
>         callback: javax.net.ssl.SSLHandshakeException
> To: Marko Strukelj <mstrukel at redhat.com>
> Cc: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>,
>         LEONARDO NUNES <leo.nunes at gjccorp.com.br>
> Message-ID:
>         <
> CAJgngAf4-aAyu_aONLOiYC9Ap0LmAur7U-yn2pP7H4o2LKHsrw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On 12 February 2016 at 10:04, Marko Strukelj <mstrukel at redhat.com> wrote:
>
> > When using 'truststore' provider it is up to you to make sure to
> > include all the certificates you trust. Configuration via
> > -Djavax.net.ssl.trustStore works the same - no automatic inclusion of
> > cacerts. But it sounds like a good usability feature to add a flag
> > that would automatically include cacerts as well. The problem is - it
> > happens occasionally that some CAs turn out not to be trustworthy, and
> > blindly importing all cacerts exposes you to that risk.
> >
>
> How about having a flag that is enabled by default that includes cacerts
> from Java? I'd actually think that update from CA certs are more likely
> going to happen by updating Java rather than manually maintaining a
> truststore.
>
>
> > One detail to emphasize, with third party not-self-signed certificates
> > it's important to include the CA certificate used to create the
> > specific server certificate, rather than the server certificate
> > itself. Facebook servers use different short-lived server certificates
> > - and with two consecutive requests you may be presented with two
> > different server certificates - but they are all issued by the same
> > long-lived trusted CA.
>
>
> >
> > On Fri, Feb 12, 2016 at 8:07 AM, Marek Posolda <mposolda at redhat.com>
> > wrote:
> > > Facebook certificate should be signed by trusted authority, so it works
> > with
> > > default JDK truststore. At least for me it always works.
> > >
> > > Shouldn't truststore SPI use both provided file + default JDK
> truststore
> > by
> > > default? We may have flag to disable default JDK truststore, but not
> > sure if
> > > it's ever needed. Also shouldn't we rewrite SimpleHTTP to use Apache
> HTTP
> > > client provided by HttpClientProvider SPI?
> > >
> > > Marek
> > >
> > >
> > > On 11/02/16 15:23, Stian Thorgersen wrote:
> > >
> > > Does it work if you don't specify the truststore? That will use the
> > default
> > > truststore provided by the JDK.
> > >
> > > Also, does your truststore contain the required CA certs? For Facebook
> to
> > > work it'll have to contain the required CA's for their certs
> > >
> > > On 11 February 2016 at 14:09, LEONARDO NUNES <leo.nunes at gjccorp.com.br
> >
> > > wrote:
> > >>
> > >> Hi, i'm getting the error below when I try to login with Facebook.
> > >> I've followed the instructions at
> > >>
> >
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#truststore
> > >> and
> > >>
> >
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e337
> > >>
> > >> I was able to login with Facebook when trying at localhost. But at our
> > >> development server we are getting this error.
> > >>
> > >> We are using EAP in domain mode.
> > >>
> > >> The truststore I placed inside of keycloak-server.json
> > >> "truststore": {
> > >>         "file": {
> > >>             "file": "/home/soa/jboss/ssl/keycloak.jks",
> > >>             "password": "keycloak123",
> > >>             "hostname-verification-policy": "ANY",
> > >>             "disabled": false
> > >>         }
> > >>     }
> > >>
> > >>
> > >> #######
> > >>
> > >> ERRO:
> > >>
> > >>
> > >> 2016-02-11 10:44:53,927 ERROR
> > >> [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider]
> > >> (ajp-/192.168.162.73:8008-1) Failed to make identity provider oauth
> > >> callback: javax.net.ssl.SSLHandshakeException:
> > >> sun.security.validator.ValidatorException: PKIX path building failed:
> > >> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> > find
> > >> valid certification path to requested target
> > >> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> > >> [jsse.jar:1.8.0_45]
> > >> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
> > >> [jsse.jar:1.8.0_45]
> > >> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
> > >> [jsse.jar:1.8.0_45]
> > >> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
> > >> [jsse.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
> > >> [jsse.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
> > >> [jsse.jar:1.8.0_45]
> > >> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
> > >> [jsse.jar:1.8.0_45]
> > >> at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
> > >> [jsse.jar:1.8.0_45]
> > >> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
> > >> [jsse.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
> > >> [jsse.jar:1.8.0_45]
> > >> at
> > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
> > >> [jsse.jar:1.8.0_45]
> > >> at
> > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
> > >> [jsse.jar:1.8.0_45]
> > >> at
> > >>
> > sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
> > >> [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
> > >> [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(HttpURLConnection.java:1282)
> > >> [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1257)
> > >> [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
> > >> [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:124)
> > >> at
> > >>
> >
> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:228)
> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >> [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > >> [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >> [rt.jar:1.8.0_45]
> > >> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > >>
> >
> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > >>
> >
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > >>
> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:107)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > >>
> >
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:154)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > >>
> >
> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > >>
> >
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > >>
> >
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > >>
> >
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > >>
> >
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at
> > >>
> >
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> > >> [resteasy-jaxrs-2.3.8.SP4-redhat-2.jar:]
> > >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> > >>
> >
> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> > >> at
> > >>
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > >>
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > >>
> >
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
> > >> [keycloak-services-1.8.1.Final.jar:1.8.1.Final]
> > >> at
> > >>
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > >>
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > >>
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > >>
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > >>
> >
> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:91)
> > >> at
> > >>
> >
> org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:72)
> > >> at
> > >>
> >
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> > >> [jboss-as-web-7.4.3.Final-redhat-2.jar:7.4.3.Final-redhat-2]
> > >> at
> > >>
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > >>
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > >>
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > >>
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:490)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > >>
> >
> org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at
> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> > >> [jbossweb-7.4.10.Final-redhat-1.jar:7.4.10.Final-redhat-1]
> > >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
> > >> Caused by: sun.security.validator.ValidatorException: PKIX path
> building
> > >> failed: sun.security.provider.certpath.SunCertPathBuilderException:
> > unable
> > >> to find valid certification path to requested target
> > >> at
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
> > >> [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
> > >> [rt.jar:1.8.0_45]
> > >> at sun.security.validator.Validator.validate(Validator.java:260)
> > >> [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> > >> [jsse.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> > >> [jsse.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> > >> [jsse.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
> > >> [jsse.jar:1.8.0_45]
> > >> ... 50 more
> > >> Caused by: sun.security.provider.certpath.SunCertPathBuilderException:
> > >> unable to find valid certification path to requested target
> > >> at
> > >>
> >
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
> > >> [rt.jar:1.8.0_45]
> > >> at
> > >>
> >
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
> > >> [rt.jar:1.8.0_45]
> > >> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
> > >> [rt.jar:1.8.0_45]
> > >> at
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
> > >> [rt.jar:1.8.0_45]
> > >> ... 56 more
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Leonardo Nunes
> > >> ________________________________
> > >> Esta mensagem pode conter informa??o confidencial e/ou privilegiada.
> Se
> > >> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta
> > mensagem,
> > >> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou
> > tomar
> > >> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta
> mensagem
> > por
> > >> engano, por favor avise imediatamente o remetente, respondendo o
> e-mail
> > e em
> > >> seguida apague-o. Agradecemos sua coopera??o.
> > >>
> > >> This message may contain confidential and/or privileged information.
> If
> > >> you are not the addressee or authorized to receive this for the
> > addressee,
> > >> you must not use, copy, disclose or take any action based on this
> > message or
> > >> any information herein. If you have received this message in error,
> > please
> > >> advise the sender immediately by reply e-mail and delete this message.
> > Thank
> > >> you for your cooperation
> > >>
> > >> _______________________________________________
> > >> 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/20160212/cf9f6d0b/attachment.html
>
> ------------------------------
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> End of keycloak-user Digest, Vol 26, Issue 66
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160212/ca49d0ad/attachment-0001.html 

From prabhalar at yahoo.com  Fri Feb 12 22:17:38 2016
From: prabhalar at yahoo.com (Raghuram Prabhala)
Date: Sat, 13 Feb 2016 03:17:38 +0000 (UTC)
Subject: [keycloak-user] Course and Fine Grained Entitlements
In-Reply-To: <56B24EFA.7050100@redhat.com>
References: <56B24EFA.7050100@redhat.com>
Message-ID: <1185803635.2852362.1455333458464.JavaMail.yahoo@mail.yahoo.com>

Even our organization is looking for UMA modules (there are already a few vendors who offer some version of UMA) and a couple of months back I tried out something that Pedro put together which works with an old version of Keycloak. While I didn't explore the features in detail, I found that to be very nicely integrated with keycloak and definitely in the right direction. If anyone wants to look at it, here is the link. Please make sure you follow all the build instructions (see?https://github.com/pedroigor/keycloak-authz/issues/31?also)

https://github.com/pedroigor/keycloak-authz
Raghu
      From: Bill Burke <bburke at redhat.com>
 To: keycloak-user at lists.jboss.org 
 Sent: Wednesday, February 3, 2016 2:03 PM
 Subject: Re: [keycloak-user] Course and Fine Grained Entitlements
   
 Pedro is working on that...He has some stuff.? Hope he responds.? Not going to be part of Keycloak until 2.0 though.? And yes, its around UMA.
 
 On 2/3/2016 1:47 PM, Guy Davis wrote:
  
 Hi Lars, 
  Good question.? My organization is also asking similar questions about adopting Keycloak.? Let me give my understanding as a user, then Keycloak team can correct my misunderstandings. 
  Basically, Keycloak offers coarse-grained authorizations (realm-roles?and?client-app?roles) assigned to users (or?groups). ??So I understand Keycloak will let you grant user Bob the 'myapp-admin' role.? However, it falls to the backend service or application to then map that role to application-specific permissions.? For example, role 'myapp-admins' can access /myapp/project1/admin page.? This resource security can be done (for Java apps) in declarative fashion using web.xml security constraints.? Alternatively, your application code could dynamically obtain the Keycloak user principal, check their roles, and map into your app's permission scheme. ? 
  This understanding implies that your application is responsible for an admin UI to map fine-grained permissions on your app's resources to Keycloak roles. ? If your app only has 'coarse-grained" resources, then you can probably just use Keycloak roles, with no need for a permission layer or the UI it entails. 
  Also, see this pre-amble about?Permission Scopes.?In future, it sounds like Keycloak team is considering support for the?UMA portion of the OAuth standard.? This may help with fine-grained permission management within Keycloak itself? 
  Hope this helps, Guy 
  <sorry, original response was only to Lars, now to list as well>  
 On Tue, Feb 2, 2016 at 8:29 PM, Lars Noldan <lars.noldan at drillinginfo.com> wrote:
 
 We're in the investigation stage on moving from a $BigExpensiveVendor solution toward keycloak, and we're looking for a solution to help manage both Course and Fine grained entitlements.? Keycloak appears to be a fantastic authentication solution, but I'm wondering what are you, the keycloak community using to handle Authorization? 
  Thanks!  
 _______________________________________________
 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/20160213/7605b057/attachment.html 

From zaquas at gmail.com  Sat Feb 13 04:51:20 2016
From: zaquas at gmail.com (Stefano Zaccaria)
Date: Sat, 13 Feb 2016 10:51:20 +0100
Subject: [keycloak-user] Use keycloak as I used picketlink
Message-ID: <CACUY9A=F6pmT1-qyC2UVcbdt=HoYoRT3wmpgW7cpxvrBBHrV7A@mail.gmail.com>

I want to change from picketlink to keycloak
In my ee app I use keycloack CDI to check the user roles and grant with
BasicModel.hasRole(relationshipManager, identity.getAccount(),
BasicModel.getRole(identityManager, "admin"))
or
Authorization Util.hasRole(identity, partitionManager, "admin");
in my bean methods
How can I made the same thing with Keycloak?
Thanks in advantage
-- 
*Stefano*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160213/c077571b/attachment.html 

From mposolda at redhat.com  Mon Feb 15 03:18:57 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 15 Feb 2016 09:18:57 +0100
Subject: [keycloak-user] Quick clarification about Offline tokens
In-Reply-To: <CAFOTW4ZPEnuM-=hOP7rHA5e3VGajdJEF975cwgBq_LYRzyfo2g@mail.gmail.com>
References: <CAFOTW4ZPEnuM-=hOP7rHA5e3VGajdJEF975cwgBq_LYRzyfo2g@mail.gmail.com>
Message-ID: <56C189F1.80800@redhat.com>

On 12/02/16 18:10, robinfernandes . wrote:
> Hi Everyone,
>
> So the scenario that I am trying to understand is as follows:
>
> 1. I get an offline token and I try to refresh my token pair 
> (access,refresh) using this offline token.
> 2. Will I get a new offline token? Or will Keycloak see that you 
> passed in an offline token so it will return the same offline token back?
>
> The tests that I performed I saw it returning a new offline token each 
> time. Is that a correct understanding?
Yes, it works this way. However if you have some DAO on your application 
side, you don't need to save new offline token every time. You can still 
use the old offline token for refreshing and it will work. There is no 
any expiration on offline token itself, there is just expiration on 
keycloak-server side, which is updated during each token refresh (In 
other words, as long as you refresh at least once every 30 days, you can 
use same offline token for a years).

The only exception of this is, if you have "Revoke refresh token" switch 
enabled for your realm. Then each offline token can be used just once, 
so you need to always use newest offline token.

Marek

> Is there any parameter I can pass to the token refresh call so that it 
> gives me the same offline token back?
>
> Thanks,
> Robin
>
>
> _______________________________________________
> 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/20160215/dfc4e013/attachment.html 

From Edgar at info.nl  Mon Feb 15 03:40:36 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Mon, 15 Feb 2016 08:40:36 +0000
Subject: [keycloak-user] initialising docker
In-Reply-To: <56BDF6D3.2020105@gmail.com>
References: <56BDF6D3.2020105@gmail.com>
Message-ID: <B76D8AC6-0053-4A91-A9C2-03E503B0F1F6@info.nl>

Hi Tim,

We also struggle with this. What we do at the moment is we _always_ import the realm on startup of our Keycloak Docker container. Our current idea is that we will not have any runtime configuration changes in our realm at all, apart from filling the Keycloak caches. The idea being that runtime configuration changes are not automatable. We store our users and groups in LDAP/Active Directory and all realm configuration is stored in the realm JSON file in Git and imported every time. 

I was wondering: if you do change your realm configuration runtime how do you deal with deployment automation? Is your idea to only import your realm definition once? If so, how would you deal with automating realm configuration changes?

cheers

Edgar 

> On 12 Feb 2016, at 16:14, Tim Dudgeon <tdudgeon.ml at gmail.com> wrote:
> 
> I've been struggling with a clean way to initialize the keycloak docker 
> container.
> I need to import a realm definition, and the only way I can find is it 
> start the image with the import options, wait for this to complete so 
> that the database is populated and then to Ctrl-C out and to restart the 
> container proper, which is hardly automatable.
> With 1.8 this also needs to include defining the admin user.
> 
> Is there a cleaner way of achieving this?
> For instance, with the postgres docker images you just put any 
> initialisation *.sql or *.sh scripts in a specific directory and they 
> get executed first time the server starts.
> 
> 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  Mon Feb 15 04:05:18 2016
From: tdudgeon.ml at gmail.com (Tim Dudgeon)
Date: Mon, 15 Feb 2016 09:05:18 +0000
Subject: [keycloak-user] initialising docker
In-Reply-To: <B76D8AC6-0053-4A91-A9C2-03E503B0F1F6@info.nl>
References: <56BDF6D3.2020105@gmail.com>
	<B76D8AC6-0053-4A91-A9C2-03E503B0F1F6@info.nl>
Message-ID: <56C194CE.5080401@gmail.com>

Hi Edgar,

Well, the way I'm doing it now (which I don't like at all, hence the 
original post), is to run the startup script in a separate container so 
that the database (Postgres in my case) is populated, and to do that 
once before the actual container is launched (so that the real container 
picks up the required configuration from the database).
Importing the realm every time might be an alternative, as long is it 
doesn't over-write any user info. I'll look into that.
But hoping that there are better suggestions for this out there!

Tim

On 15/02/2016 08:40, Edgar Vonk - Info.nl wrote:
> Hi Tim,
>
> We also struggle with this. What we do at the moment is we _always_ import the realm on startup of our Keycloak Docker container. Our current idea is that we will not have any runtime configuration changes in our realm at all, apart from filling the Keycloak caches. The idea being that runtime configuration changes are not automatable. We store our users and groups in LDAP/Active Directory and all realm configuration is stored in the realm JSON file in Git and imported every time.
>
> I was wondering: if you do change your realm configuration runtime how do you deal with deployment automation? Is your idea to only import your realm definition once? If so, how would you deal with automating realm configuration changes?
>
> cheers
>
> Edgar
>
>> On 12 Feb 2016, at 16:14, Tim Dudgeon <tdudgeon.ml at gmail.com> wrote:
>>
>> I've been struggling with a clean way to initialize the keycloak docker
>> container.
>> I need to import a realm definition, and the only way I can find is it
>> start the image with the import options, wait for this to complete so
>> that the database is populated and then to Ctrl-C out and to restart the
>> container proper, which is hardly automatable.
>> With 1.8 this also needs to include defining the admin user.
>>
>> Is there a cleaner way of achieving this?
>> For instance, with the postgres docker images you just put any
>> initialisation *.sql or *.sh scripts in a specific directory and they
>> get executed first time the server starts.
>>
>> Tim
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user


From sthorger at redhat.com  Mon Feb 15 04:45:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 15 Feb 2016 10:45:50 +0100
Subject: [keycloak-user] initialising docker
In-Reply-To: <56C194CE.5080401@gmail.com>
References: <56BDF6D3.2020105@gmail.com>
	<B76D8AC6-0053-4A91-A9C2-03E503B0F1F6@info.nl>
	<56C194CE.5080401@gmail.com>
Message-ID: <CAJgngAevqV5TJq6wTeTYp3jGjeBOVr0roTs9dpU++XG98XxxDQ@mail.gmail.com>

We are planning on at some point to add an import directory. You can dump a
realm json file in there and Keycloak will only import it once. It would
use the hash of the file and add a marker to the db to make sure it's only
done once, even if you delete the realm in the db.

Not sure when or even if this will be added though.

Another option is that it would be relatively easy to extend the Docker
image to import a file only first time it's started.
On 15 Feb 2016 10:06, "Tim Dudgeon" <tdudgeon.ml at gmail.com> wrote:

> Hi Edgar,
>
> Well, the way I'm doing it now (which I don't like at all, hence the
> original post), is to run the startup script in a separate container so
> that the database (Postgres in my case) is populated, and to do that
> once before the actual container is launched (so that the real container
> picks up the required configuration from the database).
> Importing the realm every time might be an alternative, as long is it
> doesn't over-write any user info. I'll look into that.
> But hoping that there are better suggestions for this out there!
>
> Tim
>
> On 15/02/2016 08:40, Edgar Vonk - Info.nl wrote:
> > Hi Tim,
> >
> > We also struggle with this. What we do at the moment is we _always_
> import the realm on startup of our Keycloak Docker container. Our current
> idea is that we will not have any runtime configuration changes in our
> realm at all, apart from filling the Keycloak caches. The idea being that
> runtime configuration changes are not automatable. We store our users and
> groups in LDAP/Active Directory and all realm configuration is stored in
> the realm JSON file in Git and imported every time.
> >
> > I was wondering: if you do change your realm configuration runtime how
> do you deal with deployment automation? Is your idea to only import your
> realm definition once? If so, how would you deal with automating realm
> configuration changes?
> >
> > cheers
> >
> > Edgar
> >
> >> On 12 Feb 2016, at 16:14, Tim Dudgeon <tdudgeon.ml at gmail.com> wrote:
> >>
> >> I've been struggling with a clean way to initialize the keycloak docker
> >> container.
> >> I need to import a realm definition, and the only way I can find is it
> >> start the image with the import options, wait for this to complete so
> >> that the database is populated and then to Ctrl-C out and to restart the
> >> container proper, which is hardly automatable.
> >> With 1.8 this also needs to include defining the admin user.
> >>
> >> Is there a cleaner way of achieving this?
> >> For instance, with the postgres docker images you just put any
> >> initialisation *.sql or *.sh scripts in a specific directory and they
> >> get executed first time the server starts.
> >>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160215/81297f38/attachment.html 

From Edgar at info.nl  Mon Feb 15 05:37:33 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Mon, 15 Feb 2016 10:37:33 +0000
Subject: [keycloak-user] initialising docker
In-Reply-To: <CAJgngAevqV5TJq6wTeTYp3jGjeBOVr0roTs9dpU++XG98XxxDQ@mail.gmail.com>
References: <56BDF6D3.2020105@gmail.com>
	<B76D8AC6-0053-4A91-A9C2-03E503B0F1F6@info.nl>
	<56C194CE.5080401@gmail.com>
	<CAJgngAevqV5TJq6wTeTYp3jGjeBOVr0roTs9dpU++XG98XxxDQ@mail.gmail.com>
Message-ID: <08FB342B-FE2F-45E6-A983-9A1084CE35F3@info.nl>

Hi Stian,

Ok, thanks.

Say that you would only import a realm once. How then would you typically deal with changes in the realm configuration in an automated deployment situation? We do not want any manual steps in our deployment and so we want all Keycloak realm changes managed from our Git repository. Does Keycloak support some kind of update/delta mechanism that we can use to automated realm configuration changes?

cheers

Edgar

On 15 Feb 2016, at 10:45, Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>> wrote:


We are planning on at some point to add an import directory. You can dump a realm json file in there and Keycloak will only import it once. It would use the hash of the file and add a marker to the db to make sure it's only done once, even if you delete the realm in the db.

Not sure when or even if this will be added though.

Another option is that it would be relatively easy to extend the Docker image to import a file only first time it's started.

On 15 Feb 2016 10:06, "Tim Dudgeon" <tdudgeon.ml at gmail.com<mailto:tdudgeon.ml at gmail.com>> wrote:
Hi Edgar,

Well, the way I'm doing it now (which I don't like at all, hence the
original post), is to run the startup script in a separate container so
that the database (Postgres in my case) is populated, and to do that
once before the actual container is launched (so that the real container
picks up the required configuration from the database).
Importing the realm every time might be an alternative, as long is it
doesn't over-write any user info. I'll look into that.
But hoping that there are better suggestions for this out there!

Tim

On 15/02/2016 08:40, Edgar Vonk - Info.nl<http://info.nl> wrote:
> Hi Tim,
>
> We also struggle with this. What we do at the moment is we _always_ import the realm on startup of our Keycloak Docker container. Our current idea is that we will not have any runtime configuration changes in our realm at all, apart from filling the Keycloak caches. The idea being that runtime configuration changes are not automatable. We store our users and groups in LDAP/Active Directory and all realm configuration is stored in the realm JSON file in Git and imported every time.
>
> I was wondering: if you do change your realm configuration runtime how do you deal with deployment automation? Is your idea to only import your realm definition once? If so, how would you deal with automating realm configuration changes?
>
> cheers
>
> Edgar
>
>> On 12 Feb 2016, at 16:14, Tim Dudgeon <tdudgeon.ml at gmail.com<mailto:tdudgeon.ml at gmail.com>> wrote:
>>
>> I've been struggling with a clean way to initialize the keycloak docker
>> container.
>> I need to import a realm definition, and the only way I can find is it
>> start the image with the import options, wait for this to complete so
>> that the database is populated and then to Ctrl-C out and to restart the
>> container proper, which is hardly automatable.
>> With 1.8 this also needs to include defining the admin user.
>>
>> Is there a cleaner way of achieving this?
>> For instance, with the postgres docker images you just put any
>> initialisation *.sql or *.sh scripts in a specific directory and they
>> get executed first time the server starts.
>>
>> Tim
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160215/529ece45/attachment.html 

From sthorger at redhat.com  Mon Feb 15 06:10:26 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 15 Feb 2016 12:10:26 +0100
Subject: [keycloak-user] initialising docker
In-Reply-To: <08FB342B-FE2F-45E6-A983-9A1084CE35F3@info.nl>
References: <56BDF6D3.2020105@gmail.com>
	<B76D8AC6-0053-4A91-A9C2-03E503B0F1F6@info.nl>
	<56C194CE.5080401@gmail.com>
	<CAJgngAevqV5TJq6wTeTYp3jGjeBOVr0roTs9dpU++XG98XxxDQ@mail.gmail.com>
	<08FB342B-FE2F-45E6-A983-9A1084CE35F3@info.nl>
Message-ID: <CAJgngAfFYGb0Lzx9npsaMMY0L7Ymw5bg0GzLjFJCa4frGZZh7Q@mail.gmail.com>

We don't support anything like that and it would have to be written to use
the rest endpoints so it can check the live db. Maybe it's something we
should consider for the future. It wouldn't be trivial to implement I think.
On 15 Feb 2016 11:37, "Edgar Vonk - Info.nl" <Edgar at info.nl> wrote:

> Hi Stian,
>
> Ok, thanks.
>
> Say that you would only import a realm once. How then would you typically
> deal with changes in the realm configuration in an automated deployment
> situation? We do not want any manual steps in our deployment and so we want
> all Keycloak realm changes managed from our Git repository. Does Keycloak
> support some kind of update/delta mechanism that we can use to automated
> realm configuration changes?
>
> cheers
>
> Edgar
>
> On 15 Feb 2016, at 10:45, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> We are planning on at some point to add an import directory. You can dump
> a realm json file in there and Keycloak will only import it once. It would
> use the hash of the file and add a marker to the db to make sure it's only
> done once, even if you delete the realm in the db.
>
> Not sure when or even if this will be added though.
>
> Another option is that it would be relatively easy to extend the Docker
> image to import a file only first time it's started.
> On 15 Feb 2016 10:06, "Tim Dudgeon" <tdudgeon.ml at gmail.com> wrote:
>
>> Hi Edgar,
>>
>> Well, the way I'm doing it now (which I don't like at all, hence the
>> original post), is to run the startup script in a separate container so
>> that the database (Postgres in my case) is populated, and to do that
>> once before the actual container is launched (so that the real container
>> picks up the required configuration from the database).
>> Importing the realm every time might be an alternative, as long is it
>> doesn't over-write any user info. I'll look into that.
>> But hoping that there are better suggestions for this out there!
>>
>> Tim
>>
>> On 15/02/2016 08:40, Edgar Vonk - Info.nl <http://info.nl> wrote:
>> > Hi Tim,
>> >
>> > We also struggle with this. What we do at the moment is we _always_
>> import the realm on startup of our Keycloak Docker container. Our current
>> idea is that we will not have any runtime configuration changes in our
>> realm at all, apart from filling the Keycloak caches. The idea being that
>> runtime configuration changes are not automatable. We store our users and
>> groups in LDAP/Active Directory and all realm configuration is stored in
>> the realm JSON file in Git and imported every time.
>> >
>> > I was wondering: if you do change your realm configuration runtime how
>> do you deal with deployment automation? Is your idea to only import your
>> realm definition once? If so, how would you deal with automating realm
>> configuration changes?
>> >
>> > cheers
>> >
>> > Edgar
>> >
>> >> On 12 Feb 2016, at 16:14, Tim Dudgeon <tdudgeon.ml at gmail.com> wrote:
>> >>
>> >> I've been struggling with a clean way to initialize the keycloak docker
>> >> container.
>> >> I need to import a realm definition, and the only way I can find is it
>> >> start the image with the import options, wait for this to complete so
>> >> that the database is populated and then to Ctrl-C out and to restart
>> the
>> >> container proper, which is hardly automatable.
>> >> With 1.8 this also needs to include defining the admin user.
>> >>
>> >> Is there a cleaner way of achieving this?
>> >> For instance, with the postgres docker images you just put any
>> >> initialisation *.sql or *.sh scripts in a specific directory and they
>> >> get executed first time the server starts.
>> >>
>> >> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160215/18d57b23/attachment-0001.html 

From psilva at redhat.com  Mon Feb 15 07:37:39 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 15 Feb 2016 07:37:39 -0500 (EST)
Subject: [keycloak-user] Course and Fine Grained Entitlements
In-Reply-To: <1185803635.2852362.1455333458464.JavaMail.yahoo@mail.yahoo.com>
References: <56B24EFA.7050100@redhat.com>
	<1185803635.2852362.1455333458464.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <438676051.22848757.1455539859144.JavaMail.zimbra@redhat.com>

Hi All,

    @Raghu, I think we already discussing this on GitHub :)

    The understanding from both Guy Davis and Raghu are correct. Currently, KC provides coarse-grained authz based on vanilla OAuth2 and roles/scopes within an access token. There no fine-grained permissions where you can define permissions such as which actions an identity is allowed to perform on a protected resource. Today, you need something on the app side to handle that.

    The whole idea behind Keycloak AuthZ is to leverage KC capabilities in order to provide a Policy Administration Point (based on KC admin console), a Policy Decision Point (based on a RESTFul API) and Policy Enforcement Points (something like KC adapters but for authz). Given that, KC will be able to support different access control models (ABAC, RBAC, GBAC, Risk or Context-based, etc) with a policy model that can be built around a specific resource (or a set of resources) in order to decide whether an access is granted or not. 

    Currently, that projects provide a minimal UMA implementation and UIs to manage authorization policies, from where you can even simulate them to check for the outcome before actually enforcing them into your application. There is also some initial implementation of a JAX-RS based adapter that makes easier to integrate with the Keycloak AuthZ server in order to enforce authorization for the protected resources. From an UMA perspective, we are also planning to support more advanced use cases where an user can authorize another to access his resource, but currently we are focusing on API security use cases.

    So, the list of things we are planning is pretty big and I hope to have some decisions around this project after our meeting which will happen next month. More details can be found here [1].

[1] https://github.com/pedroigor/keycloak-authz

Regards.
Pedro Igor

    

----- Original Message -----
From: "Raghuram Prabhala" <prabhalar at yahoo.com>
To: "Bill Burke" <bburke at redhat.com>, keycloak-user at lists.jboss.org
Sent: Saturday, February 13, 2016 1:17:38 AM
Subject: Re: [keycloak-user] Course and Fine Grained Entitlements

Even our organization is looking for UMA modules (there are already a few vendors who offer some version of UMA) and a couple of months back I tried out something that Pedro put together which works with an old version of Keycloak. While I didn't explore the features in detail, I found that to be very nicely integrated with keycloak and definitely in the right direction. If anyone wants to look at it, here is the link. Please make sure you follow all the build instructions (see https://github.com/pedroigor/keycloak-authz/issues/31 also) 


https://github.com/pedroigor/keycloak-authz 

Raghu 

From: Bill Burke <bburke at redhat.com> 
To: keycloak-user at lists.jboss.org 
Sent: Wednesday, February 3, 2016 2:03 PM 
Subject: Re: [keycloak-user] Course and Fine Grained Entitlements 

Pedro is working on that...He has some stuff. Hope he responds. Not going to be part of Keycloak until 2.0 though. And yes, its around UMA. 

On 2/3/2016 1:47 PM, Guy Davis wrote: 



Hi Lars, 

Good question. My organization is also asking similar questions about adopting Keycloak. Let me give my understanding as a user, then Keycloak team can correct my misunderstandings. 

Basically, Keycloak offers coarse-grained authorizations ( realm-roles and client-app roles ) assigned to users (or groups ). So I understand Keycloak will let you grant user Bob the 'myapp-admin' role. However, it falls to the backend service or application to then map that role to application-specific permissions. For example, role 'myapp-admins' can access /myapp/project1/admin page. This resource security can be done (for Java apps) in declarative fashion using web.xml security constraints. Alternatively, your application code could dynamically obtain the Keycloak user principal, check their roles, and map into your app's permission scheme. 

This understanding implies that your application is responsible for an admin UI to map fine-grained permissions on your app's resources to Keycloak roles. If your app only has 'coarse-grained" resources, then you can probably just use Keycloak roles, with no need for a permission layer or the UI it entails. 

Also, see this pre-amble about Permission Scopes . In future, it sounds like Keycloak team is considering support for the UMA portion of the OAuth standard . This may help with fine-grained permission management within Keycloak itself? 

Hope this helps, 
Guy 

<sorry, original response was only to Lars, now to list as well> 

On Tue, Feb 2, 2016 at 8:29 PM, Lars Noldan < lars.noldan at drillinginfo.com > wrote: 



We're in the investigation stage on moving from a $BigExpensiveVendor solution toward keycloak, and we're looking for a solution to help manage both Course and Fine grained entitlements. Keycloak appears to be a fantastic authentication solution, but I'm wondering what are you, the keycloak community using to handle Authorization? 

Thanks! 

_______________________________________________ 
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

From Edgar at info.nl  Mon Feb 15 08:10:35 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Mon, 15 Feb 2016 13:10:35 +0000
Subject: [keycloak-user] Add custom protocol mapper
Message-ID: <6C7ABE03-7388-47E7-8A0E-E501B8EF816F@info.nl>

Hi,

We want to write our own custom protocol mapper where we add custom dynamic user attributes to the JWT tokens by querying our custom database.

However if I not mistaken there is no SPI for adding custom mappers? How would we go about adding our own protocol mapper most easily?

cheers

Edgar

From bburke at redhat.com  Mon Feb 15 10:39:07 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 Feb 2016 10:39:07 -0500
Subject: [keycloak-user] Add custom protocol mapper
In-Reply-To: <6C7ABE03-7388-47E7-8A0E-E501B8EF816F@info.nl>
References: <6C7ABE03-7388-47E7-8A0E-E501B8EF816F@info.nl>
Message-ID: <56C1F11B.5090201@redhat.com>

There is an SPI, but it is unpublished.  I haven't had time to polish it 
or document it.  You can use it, but we can't guarantee it won't change.

https://github.com/keycloak/keycloak/tree/master/services/src/main/java/org/keycloak/protocol/oidc/mappers



On 2/15/2016 8:10 AM, Edgar Vonk - Info.nl wrote:
> Hi,
>
> We want to write our own custom protocol mapper where we add custom dynamic user attributes to the JWT tokens by querying our custom database.
>
> However if I not mistaken there is no SPI for adding custom mappers? How would we go about adding our own protocol mapper most easily?
>
> cheers
>
> Edgar
> _______________________________________________
> 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 Edgar at info.nl  Mon Feb 15 11:03:10 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Mon, 15 Feb 2016 16:03:10 +0000
Subject: [keycloak-user] Add custom protocol mapper
In-Reply-To: <56C1F11B.5090201@redhat.com>
References: <6C7ABE03-7388-47E7-8A0E-E501B8EF816F@info.nl>
	<56C1F11B.5090201@redhat.com>
Message-ID: <C2E10509-B4D5-4BD3-B33A-051DA0B1C460@info.nl>

Thanks Bill! We found this out indeed and managed to create our own mapper as a spike. Creating the Java class is easy enough and fine as it is. You also need to add the mapper to the list of available mappers in:
https://github.com/keycloak/keycloak/blob/master/services/src/main/resources/META-INF/services/org.keycloak.protocol.ProtocolMapper

Our challenge now lies in how to integrate these code changes into our (Docker based) build proces. Ideally we do not want to have to build Keycloak itself from source code. We really only want to build our custom mapper and somehow add it to the Keycloak distribution if at all possible. The Java class is the easy part I guess, but adding the mapper definition to the META-INF file seems a little harder.

cheers


> On 15 Feb 2016, at 16:39, Bill Burke <bburke at redhat.com> wrote:
> 
> There is an SPI, but it is unpublished.  I haven't had time to polish it 
> or document it.  You can use it, but we can't guarantee it won't change.
> 
> https://github.com/keycloak/keycloak/tree/master/services/src/main/java/org/keycloak/protocol/oidc/mappers
> 
> 
> 
> On 2/15/2016 8:10 AM, Edgar Vonk - Info.nl wrote:
>> Hi,
>> 
>> We want to write our own custom protocol mapper where we add custom dynamic user attributes to the JWT tokens by querying our custom database.
>> 
>> However if I not mistaken there is no SPI for adding custom mappers? How would we go about adding our own protocol mapper most easily?
>> 
>> cheers
>> 
>> Edgar
>> _______________________________________________
>> 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 bburke at redhat.com  Mon Feb 15 11:31:38 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 Feb 2016 11:31:38 -0500
Subject: [keycloak-user] Add custom protocol mapper
In-Reply-To: <C2E10509-B4D5-4BD3-B33A-051DA0B1C460@info.nl>
References: <6C7ABE03-7388-47E7-8A0E-E501B8EF816F@info.nl>
	<56C1F11B.5090201@redhat.com>
	<C2E10509-B4D5-4BD3-B33A-051DA0B1C460@info.nl>
Message-ID: <56C1FD6A.50607@redhat.com>

Search documentation for how to add a provider.  It works the same for 
protocol mapper.  You just need to have that /META-INF/services file in 
the jar that contains your mapper classes.  You deploy that jar, and it 
should work.  Again, there is documentation for other SPIs, packaging 
would work the same for protocol mapper.

On 2/15/2016 11:03 AM, Edgar Vonk - Info.nl wrote:
> Thanks Bill! We found this out indeed and managed to create our own mapper as a spike. Creating the Java class is easy enough and fine as it is. You also need to add the mapper to the list of available mappers in:
> https://github.com/keycloak/keycloak/blob/master/services/src/main/resources/META-INF/services/org.keycloak.protocol.ProtocolMapper
>
> Our challenge now lies in how to integrate these code changes into our (Docker based) build proces. Ideally we do not want to have to build Keycloak itself from source code. We really only want to build our custom mapper and somehow add it to the Keycloak distribution if at all possible. The Java class is the easy part I guess, but adding the mapper definition to the META-INF file seems a little harder.
>
> cheers
>
>
>> On 15 Feb 2016, at 16:39, Bill Burke <bburke at redhat.com> wrote:
>>
>> There is an SPI, but it is unpublished.  I haven't had time to polish it
>> or document it.  You can use it, but we can't guarantee it won't change.
>>
>> https://github.com/keycloak/keycloak/tree/master/services/src/main/java/org/keycloak/protocol/oidc/mappers
>>
>>
>>
>> On 2/15/2016 8:10 AM, Edgar Vonk - Info.nl wrote:
>>> Hi,
>>>
>>> We want to write our own custom protocol mapper where we add custom dynamic user attributes to the JWT tokens by querying our custom database.
>>>
>>> However if I not mistaken there is no SPI for adding custom mappers? How would we go about adding our own protocol mapper most easily?
>>>
>>> cheers
>>>
>>> Edgar
>>> _______________________________________________
>>> 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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From bruno at abstractj.org  Mon Feb 15 12:43:39 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 15 Feb 2016 15:43:39 -0200
Subject: [keycloak-user] Cordova + Keycloak + Native Facebook login
In-Reply-To: <CAEBys6K2fDC643abUfVUTO2T8pnEg9_+7XATUJ7hvJLRysJe-Q@mail.gmail.com>
References: <CAEBys6K2fDC643abUfVUTO2T8pnEg9_+7XATUJ7hvJLRysJe-Q@mail.gmail.com>
Message-ID: <CAM5SUC7y-M9kh00s_ynwvr_dz9xMDRc937+mmTTvW9KQejnORQ@mail.gmail.com>

Hi Rennan, which threads are you talking about? I fear I'm missing the
context here.



On Fri, Feb 12, 2016 at 7:21 PM, Renann Prado <darkness.renann at gmail.com> wrote:
> Is Keycloak supporting native facebook already?
> I found at least 2 two-year old threads talking about native facebook login,
> but none of them seem to have a solution.
>
> Renann Prado
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 
- abstractj

From akaya at expedia.com  Tue Feb 16 01:59:21 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Tue, 16 Feb 2016 06:59:21 +0000
Subject: [keycloak-user] Disabling status cookie
Message-ID: <D2E905E8.28CE%akaya@expedia.com>

Hello,

I want my users to be able to login via API calls with our without requiring a browser. I looked at examples and found customer-app-cli, however I realised that even with manual login, the current workflow requires a browser to login. I found that every time when
http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob

this page loads we get a form with a different code. In theory we should be able to just stick username and password in the body and be able to get 302 response. However when I get the curl equivalent of what browser is doing I've gotten the below:

curl 'http://localhost:8080/auth/realms/demo/login-actions/authenticate?code=oY8nS7rFOlwYHNJwWS6kcw88jbxluo8EuDmZ_o5TWsw.431db3e8-6234-4ba5-8818-ed0335b8ee72&execution=08d88824-1286-4455-b5d1-07240bda8efd' -H 'Cookie: KEYCLOAK_STATE_CHECKER=a2teB_8_wfAfD9VtmV0DJhqDEuM9187r58mVW24Gfrg; KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjQzMWRiM2U4LTYyMzQtNGJhNS04ODE4LWVkMDMzNWI4ZWU3MiIsImNpZCI6ImN1c3RvbWVyLXBvcnRhbC1jbGkiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZGVtby9wcm90b2NvbC9vcGVuaWQtY29ubmVjdC9vYXV0aC9vb2IiLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYTA1MzFlNTYtZjk0Zi00NmM4LWFlNGUtNjQ4MDUyNDc2ZjEwIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9hdXRoL3JlYWxtcy9kZW1vIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJyZWRpcmVjdF91cmkiOiJ1cm46aWV0Zjp3ZzpvYXV0aDoyLjA6b29iIn19.B5vuMj-fafRAS0gJ6m-OrU5cX0atABuWy252y5k7jr0' -H 'Origin: http://localhost:8080' -H 'Accept-Encoding: gzip, deflate' -H 'Accept-Language: en-US,en;q=0.8' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36' -H 'Content-Type: application/x-www-form-urlencoded' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Cache-Control: max-age=0' -H 'Referer: http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob' -H 'Connection: keep-alive' --data 'username=sarp&password=pass1234&login=Log+in' -compressed

I was hoping not to use the cookies and just change the code bit with a new request to the page mentioned above and expect 302 response, however I am getting 500 responses saying error occurred instead.

I looked on admin management console, but could not really find a way to disable cookies for the given client or the realm. I am guessing that one of those cookies are encrypting something that is required and not using it simply prevents logging in successfully. So how can I disable this requirement?

Kind Regards,
Sarp Kaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/a3eb5167/attachment-0001.html 

From Mohan.Radhakrishnan at cognizant.com  Tue Feb 16 02:18:39 2016
From: Mohan.Radhakrishnan at cognizant.com (Mohan.Radhakrishnan at cognizant.com)
Date: Tue, 16 Feb 2016 07:18:39 +0000
Subject: [keycloak-user] Reset password flow
Message-ID: <E1B160F4999FD6449524E16C2CB94E0307809873@CTSINCHNSXMBE.cts.com>

Hi,
            I have some details about a password change flow would work in OAuth. But my knowledge of it is scanty. Can I ask how the general procedure works ?


1.       There is a identity service endpoint. Is this token endpoint unique for a client ? So here client is the AngularJS SPA that requests the bearer token.

2.       This endpoint needs a current valid bearer token/clien ID/Client secret



How is the password sent and updated using this flow ?


Thanks,
Mohan
This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/14cacdfe/attachment.html 

From Edgar at info.nl  Tue Feb 16 03:37:11 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Tue, 16 Feb 2016 08:37:11 +0000
Subject: [keycloak-user] Add custom protocol mapper
In-Reply-To: <56C1FD6A.50607@redhat.com>
References: <6C7ABE03-7388-47E7-8A0E-E501B8EF816F@info.nl>
	<56C1F11B.5090201@redhat.com>
	<C2E10509-B4D5-4BD3-B33A-051DA0B1C460@info.nl>
	<56C1FD6A.50607@redhat.com>
Message-ID: <8BDEA2D4-AB4E-4015-BE24-61E9160ACDF3@info.nl>

Ah, clear. Thanks a lot! That is exactly what we were looking for.


> On 15 Feb 2016, at 17:31, Bill Burke <bburke at redhat.com> wrote:
> 
> Search documentation for how to add a provider.  It works the same for protocol mapper.  You just need to have that /META-INF/services file in the jar that contains your mapper classes.  You deploy that jar, and it should work.  Again, there is documentation for other SPIs, packaging would work the same for protocol mapper.
> 
> On 2/15/2016 11:03 AM, Edgar Vonk - Info.nl wrote:
>> Thanks Bill! We found this out indeed and managed to create our own mapper as a spike. Creating the Java class is easy enough and fine as it is. You also need to add the mapper to the list of available mappers in:
>> https://github.com/keycloak/keycloak/blob/master/services/src/main/resources/META-INF/services/org.keycloak.protocol.ProtocolMapper
>> 
>> Our challenge now lies in how to integrate these code changes into our (Docker based) build proces. Ideally we do not want to have to build Keycloak itself from source code. We really only want to build our custom mapper and somehow add it to the Keycloak distribution if at all possible. The Java class is the easy part I guess, but adding the mapper definition to the META-INF file seems a little harder.
>> 
>> cheers
>> 
>> 
>>> On 15 Feb 2016, at 16:39, Bill Burke <bburke at redhat.com> wrote:
>>> 
>>> There is an SPI, but it is unpublished.  I haven't had time to polish it
>>> or document it.  You can use it, but we can't guarantee it won't change.
>>> 
>>> https://github.com/keycloak/keycloak/tree/master/services/src/main/java/org/keycloak/protocol/oidc/mappers
>>> 
>>> 
>>> 
>>> On 2/15/2016 8:10 AM, Edgar Vonk - Info.nl wrote:
>>>> Hi,
>>>> 
>>>> We want to write our own custom protocol mapper where we add custom dynamic user attributes to the JWT tokens by querying our custom database.
>>>> 
>>>> However if I not mistaken there is no SPI for adding custom mappers? How would we go about adding our own protocol mapper most easily?
>>>> 
>>>> cheers
>>>> 
>>>> Edgar
>>>> _______________________________________________
>>>> 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
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 



From lkrzyzan at redhat.com  Tue Feb 16 04:58:03 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Tue, 16 Feb 2016 10:58:03 +0100
Subject: [keycloak-user] How to find reference user guide for older verrsion
Message-ID: <9AF0CB93-4B21-4549-B20C-60690ECBE1EE@redhat.com>

hi,
I cannot find a link to reference guide for 1.8.0.Final

http://keycloak.jboss.org/docs.html <http://keycloak.jboss.org/docs.html> shows only 1.9.0.CR1 which doesn?t have the version in the URL.

Thanks,

Libor Krzy?anek
jboss.org Development Team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/786c4e74/attachment.html 

From bruno at abstractj.org  Tue Feb 16 05:15:18 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 16 Feb 2016 10:15:18 +0000
Subject: [keycloak-user] How to find reference user guide for older
	verrsion
In-Reply-To: <9AF0CB93-4B21-4549-B20C-60690ECBE1EE@redhat.com>
References: <9AF0CB93-4B21-4549-B20C-60690ECBE1EE@redhat.com>
Message-ID: <CAM5SUC51+Qvd7zhqbOCuSUTuRVgayA3s4LrtK7KCt+dTuwWb0w@mail.gmail.com>

I think you can just download the docs. Not sure if it helps
http://www.redhat.com/j/elqNow/elqRedir.htm?ref=http://downloads.jboss.org/keycloak/1.8.0.Final/keycloak-docs-1.8.0.Final.zip


On Tue, Feb 16, 2016 at 7:58 AM Libor Krzyzanek <lkrzyzan at redhat.com> wrote:

> hi,
> I cannot find a link to reference guide for 1.8.0.Final
>
> http://keycloak.jboss.org/docs.html shows only 1.9.0.CR1 which doesn?t
> have the version in the URL.
>
> Thanks,
>
> Libor Krzy?anek
> jboss.org Development Team
>
> _______________________________________________
> 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/20160216/63e007e0/attachment.html 

From lkrzyzan at redhat.com  Tue Feb 16 05:16:55 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Tue, 16 Feb 2016 11:16:55 +0100
Subject: [keycloak-user] How to find reference user guide for older
	verrsion
In-Reply-To: <CAM5SUC51+Qvd7zhqbOCuSUTuRVgayA3s4LrtK7KCt+dTuwWb0w@mail.gmail.com>
References: <9AF0CB93-4B21-4549-B20C-60690ECBE1EE@redhat.com>
	<CAM5SUC51+Qvd7zhqbOCuSUTuRVgayA3s4LrtK7KCt+dTuwWb0w@mail.gmail.com>
Message-ID: <E4E37AB8-C1BD-4907-A48E-2803915978DE@redhat.com>

Ah in downloads. 
Ok. It helped.

I thought that historical versions are online as well.
Nevermind.

Thanks,

Libor Krzy?anek
jboss.org Development Team

> On Feb 16, 2016, at 11:15 AM, Bruno Oliveira <bruno at abstractj.org> wrote:
> 
> I think you can just download the docs. Not sure if it helps http://www.redhat.com/j/elqNow/elqRedir.htm?ref=http://downloads.jboss.org/keycloak/1.8.0.Final/keycloak-docs-1.8.0.Final.zip <http://www.redhat.com/j/elqNow/elqRedir.htm?ref=http://downloads.jboss.org/keycloak/1.8.0.Final/keycloak-docs-1.8.0.Final.zip>
> 
> 
> On Tue, Feb 16, 2016 at 7:58 AM Libor Krzyzanek <lkrzyzan at redhat.com <mailto:lkrzyzan at redhat.com>> wrote:
> hi,
> I cannot find a link to reference guide for 1.8.0.Final
> 
> http://keycloak.jboss.org/docs.html <http://keycloak.jboss.org/docs.html> shows only 1.9.0.CR1 which doesn?t have the version in the URL.
> 
> Thanks,
> 
> Libor Krzy?anek
> jboss.org <http://jboss.org/> Development Team
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/4e60d1ec/attachment-0001.html 

From leo.nunes at gjccorp.com.br  Tue Feb 16 06:44:25 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Tue, 16 Feb 2016 11:44:25 +0000
Subject: [keycloak-user] Problems when using Javascript Adapter
Message-ID: <D2E89FF7.266C2%leo.nunes@ojc.com.br>

Hi, I'm having a problem when using the Javascript Adapter with an application deployed on Tomcat 7 at localhost:8088 and using Keycloak 1.8.0.CR3 on localhost:8080.

I get the following error at the browser console when trying to call the keycloak.loadUserProfile() method.
XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/account. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8088' is therefore not allowed access. The response had HTTP status code 403.

And this when I try to call keycloak.loadUserProfile() method.
XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/protocol/openid-connect/userinfo. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8088' is therefore not allowed access. The response had HTTP status code 403.

Details:

- If I don't login using keycloak.login() and just navigate to a restricted page configured at the web.xml and login, after i'm redirected to the restricted page if I try to call keycloak.loadUserProfile() I get the same error.
- If I login using keycloak.login() and then call keycloak.loadUserProfile() or keycloak.loadUserProfile() it works.
- If I navigate to another page and try to call keycloak.loadUserProfile() or keycloak.loadUserProfile() I get the same error.
- It only works right after I login, if I navigate to another page it won't work anymore.

This is my keycloak.json file
{
  "realm": "demo",
  "realm-public-key": "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrVrCuTtArbgaZzL1hvh0xtL5mc7o0NqPVnYXkLvgcwiC3BjLGw1tGEGoJaXDuSaRllobm53JBhjx33UNv+5z/UMG4kytBWxheNVKnL6GgqlNabMaFfPLPCF8kAgKnsi79NMo+n6KnSY8YeUmec/p2vjO2NjsSAVcWEQMVhJ31LwIDAQAB",
  "auth-server-url": "http://localhost:8080/auth",
  "ssl-required": "external",
  "resource": "accounts-teste",
  "public-client": true,
  "enable-cors": true
}


--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/cb1d946d/attachment.html 

From bruno at abstractj.org  Tue Feb 16 06:49:50 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 16 Feb 2016 11:49:50 +0000
Subject: [keycloak-user] Problems when using Javascript Adapter
In-Reply-To: <D2E89FF7.266C2%leo.nunes@ojc.com.br>
References: <D2E89FF7.266C2%leo.nunes@ojc.com.br>
Message-ID: <CAM5SUC5_PTzY7abwrKr4fG4k06Mic14XWGE_c6L91H0bDNMQzQ@mail.gmail.com>

I believe that your issue is related to CORS, take a look at the examples
https://github.com/keycloak/keycloak/tree/master/examples/cors and the
documentation as well
http://keycloak.github.io/docs/userguide/keycloak-server/html/cors.html.


On Tue, Feb 16, 2016 at 9:44 AM LEONARDO NUNES <leo.nunes at gjccorp.com.br>
wrote:

> Hi, I'm having a problem when using the Javascript Adapter with an
> application deployed on Tomcat 7 at localhost:8088 and using Keycloak
> 1.8.0.CR3 on localhost:8080.
>
> I get the following error at the browser console when trying to call
> the keycloak.loadUserProfile() method.
> XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/account.
> No 'Access-Control-Allow-Origin' header is present on the requested
> resource. Origin 'http://localhost:8088' is therefore not allowed access.
> The response had HTTP status code 403.
>
> And this when I try to call keycloak.loadUserProfile() method.
> XMLHttpRequest cannot load
> http://localhost:8080/auth/realms/demo/protocol/openid-connect/userinfo.
> No 'Access-Control-Allow-Origin' header is present on the requested
> resource. Origin 'http://localhost:8088' is therefore not allowed access.
> The response had HTTP status code 403.
>
> Details:
>
> - If I don't login using keycloak.login() and just navigate to a
> restricted page configured at the web.xml and login, after i'm redirected
> to the restricted page if I try to call keycloak.loadUserProfile() I get
> the same error.
> - If I login using keycloak.login() and then call
> keycloak.loadUserProfile() or keycloak.loadUserProfile() it works.
> - If I navigate to another page and try to call keycloak.loadUserProfile()
> or keycloak.loadUserProfile() I get the same error.
> - It only works right after I login, if I navigate to another page it
> won't work anymore.
>
> This is my keycloak.json file
> {
>   "realm": "demo",
>   "realm-public-key":
> "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrVrCuTtArbgaZzL1hvh0xtL5mc7o0NqPVnYXkLvgcwiC3BjLGw1tGEGoJaXDuSaRllobm53JBhjx33UNv+5z/UMG4kytBWxheNVKnL6GgqlNabMaFfPLPCF8kAgKnsi79NMo+n6KnSY8YeUmec/p2vjO2NjsSAVcWEQMVhJ31LwIDAQAB",
>   "auth-server-url": "http://localhost:8080/auth",
>   "ssl-required": "external",
>   "resource": "accounts-teste",
>   "public-client": true,
>   "enable-cors": true
> }
>
>
> --
> Leonardo Nunes
> ------------------------------
>
>
> *Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem,
> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar
> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por
> engano, por favor avise imediatamente o remetente, respondendo o e-mail e
> em seguida apague-o. Agradecemos sua coopera??o. This message may contain
> confidential and/or privileged information. If you are not the addressee or
> authorized to receive this for the addressee, you must not use, copy,
> disclose or take any action based on this message or any information
> herein. If you have received this message in error, please advise the
> sender immediately by reply e-mail and delete this message. Thank you for
> your cooperation*
> _______________________________________________
> 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/20160216/b0425863/attachment.html 

From leo.nunes at gjccorp.com.br  Tue Feb 16 07:23:01 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Tue, 16 Feb 2016 12:23:01 +0000
Subject: [keycloak-user] Problems when using Javascript Adapter
In-Reply-To: <CAM5SUC5_PTzY7abwrKr4fG4k06Mic14XWGE_c6L91H0bDNMQzQ@mail.gmail.com>
Message-ID: <D2E8A5A6.266CC%leo.nunes@ojc.com.br>

Bruno thanks for the replay.
I have tried the cors example application and it works fine.
When I configure my application to login the way cors example application does, it works also.

The problem I see is that it calls the init method with the login-required, and this causes every page load to login again.
I have an event listener adapter that sends a request to our statistics server after every login, when I use the onLoad: 'login-required' then on every page load the listener for login is called.
keycloakAuth.init({ onLoad: 'login-required' })

One thing got confused is, when I use the Javascript Adapter, then I don't have to configure keycloak at the web.xml?
Or can I still configure at the web.xml, define the restricted urls and also use the Javascript Adapter?

I might be using the Javascript Adapter not the way it was designed to be used.


--
Leonardo Nunes


From: Bruno Oliveira <bruno at abstractj.org<mailto:bruno at abstractj.org>>
Date: ter?a-feira, 16 de fevereiro de 2016 09:49
To: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Problems when using Javascript Adapter

I believe that your issue is related to CORS, take a look at the examples https://github.com/keycloak/keycloak/tree/master/examples/cors and the documentation as well http://keycloak.github.io/docs/userguide/keycloak-server/html/cors.html.


On Tue, Feb 16, 2016 at 9:44 AM LEONARDO NUNES <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>> wrote:
Hi, I'm having a problem when using the Javascript Adapter with an application deployed on Tomcat 7 at localhost:8088 and using Keycloak 1.8.0.CR3 on localhost:8080.

I get the following error at the browser console when trying to call the keycloak.loadUserProfile() method.
XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/account. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8088' is therefore not allowed access. The response had HTTP status code 403.

And this when I try to call keycloak.loadUserProfile() method.
XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/protocol/openid-connect/userinfo. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8088' is therefore not allowed access. The response had HTTP status code 403.

Details:

- If I don't login using keycloak.login() and just navigate to a restricted page configured at the web.xml and login, after i'm redirected to the restricted page if I try to call keycloak.loadUserProfile() I get the same error.
- If I login using keycloak.login() and then call keycloak.loadUserProfile() or keycloak.loadUserProfile() it works.
- If I navigate to another page and try to call keycloak.loadUserProfile() or keycloak.loadUserProfile() I get the same error.
- It only works right after I login, if I navigate to another page it won't work anymore.

This is my keycloak.json file
{
  "realm": "demo",
  "realm-public-key": "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrVrCuTtArbgaZzL1hvh0xtL5mc7o0NqPVnYXkLvgcwiC3BjLGw1tGEGoJaXDuSaRllobm53JBhjx33UNv+5z/UMG4kytBWxheNVKnL6GgqlNabMaFfPLPCF8kAgKnsi79NMo+n6KnSY8YeUmec/p2vjO2NjsSAVcWEQMVhJ31LwIDAQAB",
  "auth-server-url": "http://localhost:8080/auth",
  "ssl-required": "external",
  "resource": "accounts-teste",
  "public-client": true,
  "enable-cors": true
}


--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/0a5ae910/attachment-0001.html 

From bburke at redhat.com  Tue Feb 16 07:38:43 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Feb 2016 07:38:43 -0500
Subject: [keycloak-user] Disabling status cookie
In-Reply-To: <D2E905E8.28CE%akaya@expedia.com>
References: <D2E905E8.28CE%akaya@expedia.com>
Message-ID: <56C31853.1080904@redhat.com>

See our direct grant API.    Here's an example:

https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java

I *STRONGLY* suggest you do not use the direct grant API for 
browser-based applications.  Otherwise you lose 90% of the features of 
Keycloak.  Use the direct grant API for REST clients, that's what it was 
designed for.

On 2/16/2016 1:59 AM, Sarp Kaya wrote:
> Hello,
>
> I want my users to be able to login via API calls with our without 
> requiring a browser. I looked at examples and found customer-app-cli, 
> however I realised that even with manual login, the current workflow 
> requires a browser to login. I found that every time when
> http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
>
> this page loads we get a form with a different code. In theory we 
> should be able to just stick username and password in the body and be 
> able to get 302 response. However when I get the curl equivalent of 
> what browser is doing I?ve gotten the below:
>
> curl 
> 'http://localhost:8080/auth/realms/demo/login-actions/authenticate?code=oY8nS7rFOlwYHNJwWS6kcw88jbxluo8EuDmZ_o5TWsw.431db3e8-6234-4ba5-8818-ed0335b8ee72&execution=08d88824-1286-4455-b5d1-07240bda8efd' 
> -H 'Cookie: 
> KEYCLOAK_STATE_CHECKER=a2teB_8_wfAfD9VtmV0DJhqDEuM9187r58mVW24Gfrg; 
> KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjQzMWRiM2U4LTYyMzQtNGJhNS04ODE4LWVkMDMzNWI4ZWU3MiIsImNpZCI6ImN1c3RvbWVyLXBvcnRhbC1jbGkiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZGVtby9wcm90b2NvbC9vcGVuaWQtY29ubmVjdC9vYXV0aC9vb2IiLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYTA1MzFlNTYtZjk0Zi00NmM4LWFlNGUtNjQ4MDUyNDc2ZjEwIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9hdXRoL3JlYWxtcy9kZW1vIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJyZWRpcmVjdF91cmkiOiJ1cm46aWV0Zjp3ZzpvYXV0aDoyLjA6b29iIn19.B5vuMj-fafRAS0gJ6m-OrU5cX0atABuWy252y5k7jr0' 
> -H 'Origin: http://localhost:8080' -H 'Accept-Encoding: gzip, deflate' 
> -H 'Accept-Language: en-US,en;q=0.8' -H 'Upgrade-Insecure-Requests: 1' 
> -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 
> Safari/537.36' -H 'Content-Type: application/x-www-form-urlencoded' -H 
> 'Accept: 
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' 
> -H 'Cache-Control: max-age=0' -H 'Referer: 
> http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob' 
> -H 'Connection: keep-alive' --data 
> 'username=sarp&password=pass1234&login=Log+in' ?compressed
>
> I was hoping not to use the cookies and just change the code bit with 
> a new request to the page mentioned above and expect 302 response, 
> however I am getting 500 responses saying error occurred instead.
>
> I looked on admin management console, but could not really find a way 
> to disable cookies for the given client or the realm. I am guessing 
> that one of those cookies are encrypting something that is required 
> and not using it simply prevents logging in successfully. So how can I 
> disable this requirement?
>
> Kind Regards,
> Sarp Kaya
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/af8e3043/attachment.html 

From marso at gmx.at  Tue Feb 16 10:18:05 2016
From: marso at gmx.at (marso at gmx.at)
Date: Tue, 16 Feb 2016 16:18:05 +0100
Subject: [keycloak-user] NullPointerException - Authenticator - Cookie
Message-ID: <trinity-977bd2a2-ffb7-4616-bf2e-592dcdfeaca2-1455635885162@3capp-gmx-bs64>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/286598e2/attachment.html 

From sthorger at redhat.com  Tue Feb 16 11:27:26 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 16 Feb 2016 17:27:26 +0100
Subject: [keycloak-user] Problems when using Javascript Adapter
In-Reply-To: <D2E8A5A6.266CC%leo.nunes@ojc.com.br>
References: <CAM5SUC5_PTzY7abwrKr4fG4k06Mic14XWGE_c6L91H0bDNMQzQ@mail.gmail.com>
	<D2E8A5A6.266CC%leo.nunes@ojc.com.br>
Message-ID: <CAJgngAdxU9sx-1k7ZTLy=r5KuosSdcR2_3vYbuyKwFnGU4z5XQ@mail.gmail.com>

Your HTML5 application should use the JavaScript adapter, not both as you
are doing now. That is why you are getting a endless redirect loop as both
adapters just keep trying to login.

On 16 February 2016 at 13:23, LEONARDO NUNES <leo.nunes at gjccorp.com.br>
wrote:

> Bruno thanks for the replay.
> I have tried the cors example application and it works fine.
> When I configure my application to login the way cors example application
> does, it works also.
>
> The problem I see is that it calls the init method with the
> login-required, and this causes every page load to login again.
> I have an event listener adapter that sends a request to our statistics
> server after every login, when I use the onLoad: 'login-required' then on
> every page load the listener for login is called.
> keycloakAuth.init({ onLoad: 'login-required' })
>
> One thing got confused is, when I use the Javascript Adapter, then I don't
> have to configure keycloak at the web.xml?
> Or can I still configure at the web.xml, define the restricted urls and
> also use the Javascript Adapter?
>
> I might be using the Javascript Adapter not the way it was designed to be
> used.
>
>
> --
> Leonardo Nunes
>
>
> From: Bruno Oliveira <bruno at abstractj.org>
> Date: ter?a-feira, 16 de fevereiro de 2016 09:49
> To: Leonardo Nunes <leo.nunes at gjccorp.com.br>, "
> keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Problems when using Javascript Adapter
>
> I believe that your issue is related to CORS, take a look at the examples
> https://github.com/keycloak/keycloak/tree/master/examples/cors and the
> documentation as well
> http://keycloak.github.io/docs/userguide/keycloak-server/html/cors.html.
>
>
> On Tue, Feb 16, 2016 at 9:44 AM LEONARDO NUNES <leo.nunes at gjccorp.com.br>
> wrote:
>
>> Hi, I'm having a problem when using the Javascript Adapter with an
>> application deployed on Tomcat 7 at localhost:8088 and using Keycloak
>> 1.8.0.CR3 on localhost:8080.
>>
>> I get the following error at the browser console when trying to call
>> the keycloak.loadUserProfile() method.
>> XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/account.
>> No 'Access-Control-Allow-Origin' header is present on the requested
>> resource. Origin 'http://localhost:8088' is therefore not allowed
>> access. The response had HTTP status code 403.
>>
>> And this when I try to call keycloak.loadUserProfile() method.
>> XMLHttpRequest cannot load
>> http://localhost:8080/auth/realms/demo/protocol/openid-connect/userinfo.
>> No 'Access-Control-Allow-Origin' header is present on the requested
>> resource. Origin 'http://localhost:8088' is therefore not allowed
>> access. The response had HTTP status code 403.
>>
>> Details:
>>
>> - If I don't login using keycloak.login() and just navigate to a
>> restricted page configured at the web.xml and login, after i'm redirected
>> to the restricted page if I try to call keycloak.loadUserProfile() I get
>> the same error.
>> - If I login using keycloak.login() and then call
>> keycloak.loadUserProfile() or keycloak.loadUserProfile() it works.
>> - If I navigate to another page and try to
>> call keycloak.loadUserProfile() or keycloak.loadUserProfile() I get the
>> same error.
>> - It only works right after I login, if I navigate to another page it
>> won't work anymore.
>>
>> This is my keycloak.json file
>> {
>>   "realm": "demo",
>>   "realm-public-key":
>> "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrVrCuTtArbgaZzL1hvh0xtL5mc7o0NqPVnYXkLvgcwiC3BjLGw1tGEGoJaXDuSaRllobm53JBhjx33UNv+5z/UMG4kytBWxheNVKnL6GgqlNabMaFfPLPCF8kAgKnsi79NMo+n6KnSY8YeUmec/p2vjO2NjsSAVcWEQMVhJ31LwIDAQAB",
>>   "auth-server-url": "http://localhost:8080/auth",
>>   "ssl-required": "external",
>>   "resource": "accounts-teste",
>>   "public-client": true,
>>   "enable-cors": true
>> }
>>
>>
>> --
>> Leonardo Nunes
>> ------------------------------
>>
>>
>> *Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
>> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem,
>> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar
>> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por
>> engano, por favor avise imediatamente o remetente, respondendo o e-mail e
>> em seguida apague-o. Agradecemos sua coopera??o. This message may contain
>> confidential and/or privileged information. If you are not the addressee or
>> authorized to receive this for the addressee, you must not use, copy,
>> disclose or take any action based on this message or any information
>> herein. If you have received this message in error, please advise the
>> sender immediately by reply e-mail and delete this message. Thank you for
>> your cooperation*
>> _______________________________________________
>> 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/20160216/68ff6fb5/attachment-0001.html 

From dev at sgordon.totalise.co.uk  Tue Feb 16 11:32:55 2016
From: dev at sgordon.totalise.co.uk (Simon Gordon)
Date: 16 Feb 2016 16:32:55 +0000
Subject: [keycloak-user] OpenShift cartridge - steps to follow?
Message-ID: <BV.WM.2.0.pv.1.0.18.1602161632550.24649@webmail01.plus.net>

Hi all

Sorry if this is a simple one, I'm struggling with OpenShift and the 
cartridge instructions

-- Option 1 -- I've followed the steps at: 
http://docs.jboss.org/keycloak/docs/1.2.0.CR1/userguide/html/openshift.html 
Which points to 
http://cartreflect-claytondev.rhcloud.com/github/keycloak/openshift-keycloak-cartridge

I guessed the URL was <host>/auth (although no output told me that), but 
admin/admin login isn't working. This cartridge I used a few months ago and 
I did manage to get this working - but now, no luck logging in

-- Option 2 -- There is also, the older docs at: 
http://docs.jboss.org/keycloak/docs/1.0-alpha-1/userguide/html/openshift.html 
Which says to use: 
https://raw.githubusercontent.com/keycloak/openshift-keycloak-cartridge/master/metadata/manifest.yml

This seems to lead to an 'empty' WildFly app server - at least, I can't 
find a URL to launch which actually provides a KeyCloak instance and no 
output from creating the instance which gives a hint

I feel I'm missing something, although I'm following the guidance on the 
pages. Any hints please anyone?

Cheers,

   Simon


From smacksnr at hotmail.com  Tue Feb 16 11:44:34 2016
From: smacksnr at hotmail.com (Bill Simakis)
Date: Tue, 16 Feb 2016 11:44:34 -0500
Subject: [keycloak-user] User Account access from client
Message-ID: <BLU179-W12809647996963CE554BC9D7AD0@phx.gbl>

I have a web app using the spring security adapter which I have successfully integrated for the authentication/Authorization with KeyCloak.?
We wanted to make the user's life a little easier by providing a link within our app to allow an authenticated user to go to their Account page in KeyCloak. As this link is realm specific, is there a way we could get the url dynamically??

Thanks

Bill? 		 	   		  

From leo.nunes at gjccorp.com.br  Tue Feb 16 11:55:01 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Tue, 16 Feb 2016 16:55:01 +0000
Subject: [keycloak-user] Problems when using Javascript Adapter
In-Reply-To: <CAJgngAdxU9sx-1k7ZTLy=r5KuosSdcR2_3vYbuyKwFnGU4z5XQ@mail.gmail.com>
Message-ID: <D2E8E4DB.26713%leo.nunes@ojc.com.br>

Stian, so how do I restrict URLs?
Do I need to place the keycloakAuth.init({ onLoad: 'login-required' }) at all pages I what to restrict and keycloakAuth.init({ onLoad: 'check-sso' }) at pages not restricted?

Does keycloakAuth.init({ onLoad: 'login-required' }) really login the user every time it's called?
Because my listener that implements EventListenerProvider enters the onEvent with EventType LOGIN every time init method is called.


--
Leonardo Nunes

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: ter?a-feira, 16 de fevereiro de 2016 14:27
To: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>
Cc: Bruno Oliveira <bruno at abstractj.org<mailto:bruno at abstractj.org>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Problems when using Javascript Adapter

Your HTML5 application should use the JavaScript adapter, not both as you are doing now. That is why you are getting a endless redirect loop as both adapters just keep trying to login.

On 16 February 2016 at 13:23, LEONARDO NUNES <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>> wrote:
Bruno thanks for the replay.
I have tried the cors example application and it works fine.
When I configure my application to login the way cors example application does, it works also.

The problem I see is that it calls the init method with the login-required, and this causes every page load to login again.
I have an event listener adapter that sends a request to our statistics server after every login, when I use the onLoad: 'login-required' then on every page load the listener for login is called.
keycloakAuth.init({ onLoad: 'login-required' })

One thing got confused is, when I use the Javascript Adapter, then I don't have to configure keycloak at the web.xml?
Or can I still configure at the web.xml, define the restricted urls and also use the Javascript Adapter?

I might be using the Javascript Adapter not the way it was designed to be used.


--
Leonardo Nunes


From: Bruno Oliveira <bruno at abstractj.org<mailto:bruno at abstractj.org>>
Date: ter?a-feira, 16 de fevereiro de 2016 09:49
To: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Problems when using Javascript Adapter

I believe that your issue is related to CORS, take a look at the examples https://github.com/keycloak/keycloak/tree/master/examples/cors and the documentation as well http://keycloak.github.io/docs/userguide/keycloak-server/html/cors.html.


On Tue, Feb 16, 2016 at 9:44 AM LEONARDO NUNES <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>> wrote:
Hi, I'm having a problem when using the Javascript Adapter with an application deployed on Tomcat 7 at localhost:8088 and using Keycloak 1.8.0.CR3 on localhost:8080.

I get the following error at the browser console when trying to call the keycloak.loadUserProfile() method.
XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/account. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8088' is therefore not allowed access. The response had HTTP status code 403.

And this when I try to call keycloak.loadUserProfile() method.
XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/protocol/openid-connect/userinfo. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8088' is therefore not allowed access. The response had HTTP status code 403.

Details:

- If I don't login using keycloak.login() and just navigate to a restricted page configured at the web.xml and login, after i'm redirected to the restricted page if I try to call keycloak.loadUserProfile() I get the same error.
- If I login using keycloak.login() and then call keycloak.loadUserProfile() or keycloak.loadUserProfile() it works.
- If I navigate to another page and try to call keycloak.loadUserProfile() or keycloak.loadUserProfile() I get the same error.
- It only works right after I login, if I navigate to another page it won't work anymore.

This is my keycloak.json file
{
  "realm": "demo",
  "realm-public-key": "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrVrCuTtArbgaZzL1hvh0xtL5mc7o0NqPVnYXkLvgcwiC3BjLGw1tGEGoJaXDuSaRllobm53JBhjx33UNv+5z/UMG4kytBWxheNVKnL6GgqlNabMaFfPLPCF8kAgKnsi79NMo+n6KnSY8YeUmec/p2vjO2NjsSAVcWEQMVhJ31LwIDAQAB",
  "auth-server-url": "http://localhost:8080/auth",
  "ssl-required": "external",
  "resource": "accounts-teste",
  "public-client": true,
  "enable-cors": true
}


--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/2c9fc444/attachment.html 

From prado.renann at gmail.com  Tue Feb 16 12:00:56 2016
From: prado.renann at gmail.com (Renann Prado)
Date: Tue, 16 Feb 2016 15:00:56 -0200
Subject: [keycloak-user] Problems when using Javascript Adapter
In-Reply-To: <D2E8E4DB.26713%leo.nunes@ojc.com.br>
References: <CAJgngAdxU9sx-1k7ZTLy=r5KuosSdcR2_3vYbuyKwFnGU4z5XQ@mail.gmail.com>
	<D2E8E4DB.26713%leo.nunes@ojc.com.br>
Message-ID: <CAEBys6KaVg=hOHiWGgiZotSbKARrc+fzf-7uiM7k_s4PQi8s8w@mail.gmail.com>

If you are not running on the CORS issue, have you tried to set your web
origins properly?
Remember that http://localhost:8080 != localhost:8080
On Feb 16, 2016 14:55, "LEONARDO NUNES" <leo.nunes at gjccorp.com.br> wrote:

> Stian, so how do I restrict URLs?
> Do I need to place the keycloakAuth.init({ onLoad: 'login-required' }) at
> all pages I what to restrict and keycloakAuth.init({ onLoad: 'check-sso' })
> at pages not restricted?
>
> Does keycloakAuth.init({ onLoad: 'login-required' }) really login the user
> every time it's called?
> Because my listener that implements EventListenerProvider enters the
> onEvent with EventType LOGIN every time init method is called.
>
>
> --
> Leonardo Nunes
>
> From: Stian Thorgersen <sthorger at redhat.com>
> Reply-To: "stian at redhat.com" <stian at redhat.com>
> Date: ter?a-feira, 16 de fevereiro de 2016 14:27
> To: Leonardo Nunes <leo.nunes at gjccorp.com.br>
> Cc: Bruno Oliveira <bruno at abstractj.org>, "keycloak-user at lists.jboss.org"
> <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Problems when using Javascript Adapter
>
> Your HTML5 application should use the JavaScript adapter, not both as you
> are doing now. That is why you are getting a endless redirect loop as both
> adapters just keep trying to login.
>
> On 16 February 2016 at 13:23, LEONARDO NUNES <leo.nunes at gjccorp.com.br>
> wrote:
>
>> Bruno thanks for the replay.
>> I have tried the cors example application and it works fine.
>> When I configure my application to login the way cors example application
>> does, it works also.
>>
>> The problem I see is that it calls the init method with the
>> login-required, and this causes every page load to login again.
>> I have an event listener adapter that sends a request to our statistics
>> server after every login, when I use the onLoad: 'login-required' then on
>> every page load the listener for login is called.
>> keycloakAuth.init({ onLoad: 'login-required' })
>>
>> One thing got confused is, when I use the Javascript Adapter, then I
>> don't have to configure keycloak at the web.xml?
>> Or can I still configure at the web.xml, define the restricted urls and
>> also use the Javascript Adapter?
>>
>> I might be using the Javascript Adapter not the way it was designed to be
>> used.
>>
>>
>> --
>> Leonardo Nunes
>>
>>
>> From: Bruno Oliveira <bruno at abstractj.org>
>> Date: ter?a-feira, 16 de fevereiro de 2016 09:49
>> To: Leonardo Nunes <leo.nunes at gjccorp.com.br>, "
>> keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>> Subject: Re: [keycloak-user] Problems when using Javascript Adapter
>>
>> I believe that your issue is related to CORS, take a look at the examples
>> https://github.com/keycloak/keycloak/tree/master/examples/cors and the
>> documentation as well
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/cors.html.
>>
>>
>> On Tue, Feb 16, 2016 at 9:44 AM LEONARDO NUNES <leo.nunes at gjccorp.com.br>
>> wrote:
>>
>>> Hi, I'm having a problem when using the Javascript Adapter with an
>>> application deployed on Tomcat 7 at localhost:8088 and using Keycloak
>>> 1.8.0.CR3 on localhost:8080.
>>>
>>> I get the following error at the browser console when trying to call
>>> the keycloak.loadUserProfile() method.
>>> XMLHttpRequest cannot load
>>> http://localhost:8080/auth/realms/demo/account. No
>>> 'Access-Control-Allow-Origin' header is present on the requested resource.
>>> Origin 'http://localhost:8088' is therefore not allowed access. The
>>> response had HTTP status code 403.
>>>
>>> And this when I try to call keycloak.loadUserProfile() method.
>>> XMLHttpRequest cannot load
>>> http://localhost:8080/auth/realms/demo/protocol/openid-connect/userinfo.
>>> No 'Access-Control-Allow-Origin' header is present on the requested
>>> resource. Origin 'http://localhost:8088' is therefore not allowed
>>> access. The response had HTTP status code 403.
>>>
>>> Details:
>>>
>>> - If I don't login using keycloak.login() and just navigate to a
>>> restricted page configured at the web.xml and login, after i'm redirected
>>> to the restricted page if I try to call keycloak.loadUserProfile() I get
>>> the same error.
>>> - If I login using keycloak.login() and then call
>>> keycloak.loadUserProfile() or keycloak.loadUserProfile() it works.
>>> - If I navigate to another page and try to
>>> call keycloak.loadUserProfile() or keycloak.loadUserProfile() I get the
>>> same error.
>>> - It only works right after I login, if I navigate to another page it
>>> won't work anymore.
>>>
>>> This is my keycloak.json file
>>> {
>>>   "realm": "demo",
>>>   "realm-public-key":
>>> "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrVrCuTtArbgaZzL1hvh0xtL5mc7o0NqPVnYXkLvgcwiC3BjLGw1tGEGoJaXDuSaRllobm53JBhjx33UNv+5z/UMG4kytBWxheNVKnL6GgqlNabMaFfPLPCF8kAgKnsi79NMo+n6KnSY8YeUmec/p2vjO2NjsSAVcWEQMVhJ31LwIDAQAB",
>>>   "auth-server-url": "http://localhost:8080/auth",
>>>   "ssl-required": "external",
>>>   "resource": "accounts-teste",
>>>   "public-client": true,
>>>   "enable-cors": true
>>> }
>>>
>>>
>>> --
>>> Leonardo Nunes
>>> ------------------------------
>>>
>>>
>>> *Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
>>> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem,
>>> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar
>>> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por
>>> engano, por favor avise imediatamente o remetente, respondendo o e-mail e
>>> em seguida apague-o. Agradecemos sua coopera??o. This message may contain
>>> confidential and/or privileged information. If you are not the addressee or
>>> authorized to receive this for the addressee, you must not use, copy,
>>> disclose or take any action based on this message or any information
>>> herein. If you have received this message in error, please advise the
>>> sender immediately by reply e-mail and delete this message. Thank you for
>>> your cooperation*
>>> _______________________________________________
>>> 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/20160216/01e84373/attachment-0001.html 

From leo.nunes at gjccorp.com.br  Tue Feb 16 12:19:15 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Tue, 16 Feb 2016 17:19:15 +0000
Subject: [keycloak-user] Problems when using Javascript Adapter
In-Reply-To: <CAEBys6KaVg=hOHiWGgiZotSbKARrc+fzf-7uiM7k_s4PQi8s8w@mail.gmail.com>
Message-ID: <D2E8ECD9.2673C%leo.nunes@ojc.com.br>

Renann, thanks you for your replay.
Now that i'm using just Javascript Adapter i'm not having the CORS issue anymore.
My doubt now is the last email I sent.


--
Leonardo Nunes


From: Renann Prado <prado.renann at gmail.com<mailto:prado.renann at gmail.com>>
Date: ter?a-feira, 16 de fevereiro de 2016 15:00
To: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>
Cc: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Problems when using Javascript Adapter


If you are not running on the CORS issue, have you tried to set your web origins properly?
Remember that http://localhost:8080 != localhost:8080

On Feb 16, 2016 14:55, "LEONARDO NUNES" <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>> wrote:
Stian, so how do I restrict URLs?
Do I need to place the keycloakAuth.init({ onLoad: 'login-required' }) at all pages I what to restrict and keycloakAuth.init({ onLoad: 'check-sso' }) at pages not restricted?

Does keycloakAuth.init({ onLoad: 'login-required' }) really login the user every time it's called?
Because my listener that implements EventListenerProvider enters the onEvent with EventType LOGIN every time init method is called.


--
Leonardo Nunes

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: ter?a-feira, 16 de fevereiro de 2016 14:27
To: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>
Cc: Bruno Oliveira <bruno at abstractj.org<mailto:bruno at abstractj.org>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Problems when using Javascript Adapter

Your HTML5 application should use the JavaScript adapter, not both as you are doing now. That is why you are getting a endless redirect loop as both adapters just keep trying to login.

On 16 February 2016 at 13:23, LEONARDO NUNES <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>> wrote:
Bruno thanks for the replay.
I have tried the cors example application and it works fine.
When I configure my application to login the way cors example application does, it works also.

The problem I see is that it calls the init method with the login-required, and this causes every page load to login again.
I have an event listener adapter that sends a request to our statistics server after every login, when I use the onLoad: 'login-required' then on every page load the listener for login is called.
keycloakAuth.init({ onLoad: 'login-required' })

One thing got confused is, when I use the Javascript Adapter, then I don't have to configure keycloak at the web.xml?
Or can I still configure at the web.xml, define the restricted urls and also use the Javascript Adapter?

I might be using the Javascript Adapter not the way it was designed to be used.


--
Leonardo Nunes


From: Bruno Oliveira <bruno at abstractj.org<mailto:bruno at abstractj.org>>
Date: ter?a-feira, 16 de fevereiro de 2016 09:49
To: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Problems when using Javascript Adapter

I believe that your issue is related to CORS, take a look at the examples https://github.com/keycloak/keycloak/tree/master/examples/cors and the documentation as well http://keycloak.github.io/docs/userguide/keycloak-server/html/cors.html.


On Tue, Feb 16, 2016 at 9:44 AM LEONARDO NUNES <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>> wrote:
Hi, I'm having a problem when using the Javascript Adapter with an application deployed on Tomcat 7 at localhost:8088 and using Keycloak 1.8.0.CR3 on localhost:8080.

I get the following error at the browser console when trying to call the keycloak.loadUserProfile() method.
XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/account. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8088' is therefore not allowed access. The response had HTTP status code 403.

And this when I try to call keycloak.loadUserProfile() method.
XMLHttpRequest cannot load http://localhost:8080/auth/realms/demo/protocol/openid-connect/userinfo. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8088' is therefore not allowed access. The response had HTTP status code 403.

Details:

- If I don't login using keycloak.login() and just navigate to a restricted page configured at the web.xml and login, after i'm redirected to the restricted page if I try to call keycloak.loadUserProfile() I get the same error.
- If I login using keycloak.login() and then call keycloak.loadUserProfile() or keycloak.loadUserProfile() it works.
- If I navigate to another page and try to call keycloak.loadUserProfile() or keycloak.loadUserProfile() I get the same error.
- It only works right after I login, if I navigate to another page it won't work anymore.

This is my keycloak.json file
{
  "realm": "demo",
  "realm-public-key": "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrVrCuTtArbgaZzL1hvh0xtL5mc7o0NqPVnYXkLvgcwiC3BjLGw1tGEGoJaXDuSaRllobm53JBhjx33UNv+5z/UMG4kytBWxheNVKnL6GgqlNabMaFfPLPCF8kAgKnsi79NMo+n6KnSY8YeUmec/p2vjO2NjsSAVcWEQMVhJ31LwIDAQAB",
  "auth-server-url": "http://localhost:8080/auth",
  "ssl-required": "external",
  "resource": "accounts-teste",
  "public-client": true,
  "enable-cors": true
}


--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user

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


_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/cb36d084/attachment.html 

From bruno at abstractj.org  Tue Feb 16 13:09:02 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 16 Feb 2016 18:09:02 +0000
Subject: [keycloak-user] OpenShift cartridge - steps to follow?
In-Reply-To: <BV.WM.2.0.pv.1.0.18.1602161632550.24649@webmail01.plus.net>
References: <BV.WM.2.0.pv.1.0.18.1602161632550.24649@webmail01.plus.net>
Message-ID: <CAM5SUC53hZ1Y3K_x32ZU3zA=5GskGarEqe8OfCRW--xWQSxizA@mail.gmail.com>

Hi Simon, it didn't work for me also. Although, version 1.7.0.Final or
superior will works just fine. Try this for example:

rhc app create your-app-name
http://cartreflect-claytondev.rhcloud.com/github/keycloak/openshift-keycloak-cartridge?commit=1.7.0.Final

username: admin / password: admin

I hope it helps.


On Tue, Feb 16, 2016 at 2:33 PM Simon Gordon <dev at sgordon.totalise.co.uk>
wrote:

> Hi all
>
> Sorry if this is a simple one, I'm struggling with OpenShift and the
> cartridge instructions
>
> -- Option 1 -- I've followed the steps at:
> http://docs.jboss.org/keycloak/docs/1.2.0.CR1/userguide/html/openshift.html
> Which points to
>
> http://cartreflect-claytondev.rhcloud.com/github/keycloak/openshift-keycloak-cartridge
>
> I guessed the URL was <host>/auth (although no output told me that), but
> admin/admin login isn't working. This cartridge I used a few months ago and
> I did manage to get this working - but now, no luck logging in
>
> -- Option 2 -- There is also, the older docs at:
>
> http://docs.jboss.org/keycloak/docs/1.0-alpha-1/userguide/html/openshift.html
> Which says to use:
>
> https://raw.githubusercontent.com/keycloak/openshift-keycloak-cartridge/master/metadata/manifest.yml
>
> This seems to lead to an 'empty' WildFly app server - at least, I can't
> find a URL to launch which actually provides a KeyCloak instance and no
> output from creating the instance which gives a hint
>
> I feel I'm missing something, although I'm following the guidance on the
> pages. Any hints please anyone?
>
> Cheers,
>
>    Simon
>
> _______________________________________________
> 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/20160216/e2bd09b8/attachment-0001.html 

From bruno at abstractj.org  Tue Feb 16 13:22:08 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 16 Feb 2016 18:22:08 +0000
Subject: [keycloak-user] OpenShift cartridge - steps to follow?
In-Reply-To: <BV.WM.2.0.pv.1.0.18.1602161632550.24649@webmail01.plus.net>
References: <BV.WM.2.0.pv.1.0.18.1602161632550.24649@webmail01.plus.net>
Message-ID: <CAM5SUC4RUqSg2RYZjS0stKWQvMT4_S1OCepCg=UGPDc_ofdAGQ@mail.gmail.com>

Here is the thing, the display name at the cartridge is wrong. If we look
at the repository https://github.com/keycloak/openshift-keycloak-cartridge.

The cartridge itself make use of 1.9.0.CR1 which now it's mandatory to
define your admin credentials.

What you have to do?

1. Create the cartridge following the documentation instructions.
2. ssh 9384983948 at yourcartridge-blah.rhcloud.com

3. $WILDFLY_HOME/bin/add-user-keycloak.sh -u admin -p admin

(of course it's not mandatory to be admin/admin :))

4. rhc app-restart yourapp

It must work, I will PR the repository to provide the correct display name.



On Tue, Feb 16, 2016 at 2:33 PM Simon Gordon <dev at sgordon.totalise.co.uk>
wrote:

> Hi all
>
> Sorry if this is a simple one, I'm struggling with OpenShift and the
> cartridge instructions
>
> -- Option 1 -- I've followed the steps at:
> http://docs.jboss.org/keycloak/docs/1.2.0.CR1/userguide/html/openshift.html
> Which points to
>
> http://cartreflect-claytondev.rhcloud.com/github/keycloak/openshift-keycloak-cartridge
>
> I guessed the URL was <host>/auth (although no output told me that), but
> admin/admin login isn't working. This cartridge I used a few months ago and
> I did manage to get this working - but now, no luck logging in
>
> -- Option 2 -- There is also, the older docs at:
>
> http://docs.jboss.org/keycloak/docs/1.0-alpha-1/userguide/html/openshift.html
> Which says to use:
>
> https://raw.githubusercontent.com/keycloak/openshift-keycloak-cartridge/master/metadata/manifest.yml
>
> This seems to lead to an 'empty' WildFly app server - at least, I can't
> find a URL to launch which actually provides a KeyCloak instance and no
> output from creating the instance which gives a hint
>
> I feel I'm missing something, although I'm following the guidance on the
> pages. Any hints please anyone?
>
> Cheers,
>
>    Simon
>
> _______________________________________________
> 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/20160216/e537ffd1/attachment.html 

From pblair at clearme.com  Tue Feb 16 14:40:00 2016
From: pblair at clearme.com (Paul Blair)
Date: Tue, 16 Feb 2016 19:40:00 +0000
Subject: [keycloak-user] 1.8.1.Final SQL error
Message-ID: <D2E8E53F.1183D%pblair@clearme.com>

I've just installed Keycloak 1.8.1.Final in a clean environment with a new Postgres database instance.  I'm getting an error on startup that the column direct_grants_only does not exist on the CLIENT table. When I log in to the database I can confirm it's not there; otherwise the tables all seem to be set up, and the CLIENT table does have a direct_access_grants_enabled column. I've verified that the server is running WildFly 10.0.0.Final and that all the Keycloak jars under ./modules/system/layers/base/org/keycloak/keycloak-core/main are 1.8.1.Final. I've diffed all the config files where we made changes against older versions of Keycloak and applied them to 1.8.1.Final, and nothing seems relevant.

Also odd is that I have two Keycloak instances running in two separate Docker containers and that I only see this error in one of them. They were both created at the same time by Terraform in exactly the same way.

Any idea what this might be coming from?

17:04:30,706 INFO  [org.keycloak.services.resources.KeycloakApplication] (ServerService Thread Pool -- 50) Load config from /opt/jboss/wildfly/standalone/configuration/keycloak-server.json
17:04:33,048 INFO  [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 50) Updating database
17:04:43,154 ERROR [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 50) Change Set META-INF/jpa-changelog-1.2.0.Final.xml::1.2.0.Final::keycloak failed.  Error: ERROR: column "direct_grants_only" does not exist
  Position: 59 [Failed SQL: UPDATE public.CLIENT SET DIRECT_GRANTS_ONLY = FALSE WHERE DIRECT_GRANTS_ONLY is null]: liquibase.exception.DatabaseException: ERROR: column "direct_grants_only" does not exist
  Position: 59 [Failed SQL: UPDATE public.CLIENT SET DIRECT_GRANTS_ONLY = FALSE WHERE DIRECT_GRANTS_ONLY is null]
at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:316)
at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:55)
at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:122)
at liquibase.database.AbstractJdbcDatabase.execute(AbstractJdbcDatabase.java:1247)
at liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1230)
at liquibase.changelog.ChangeSet.execute(ChangeSet.java:548)
at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:51)
at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73)
at liquibase.Liquibase.update(Liquibase.java:210)
at liquibase.Liquibase.update(Liquibase.java:190)
at liquibase.Liquibase.update(Liquibase.java:186)
at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:153)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)
at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
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:103)
at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)
at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)
at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)
at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:139)
at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:82)
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:408)
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: org.postgresql.util.PSQLException: ERROR: column "direct_grants_only" does not exist
  Position: 59
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2198)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1927)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:561)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:405)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:397)
at org.jboss.jca.adapters.jdbc.WrappedStatement.execute(WrappedStatement.java:198)
at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:314)
... 47 more
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/9f696025/attachment-0001.html 

From mstrukel at redhat.com  Tue Feb 16 16:08:21 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 16 Feb 2016 22:08:21 +0100
Subject: [keycloak-user] User Account access from client
In-Reply-To: <BLU179-W12809647996963CE554BC9D7AD0@phx.gbl>
References: <BLU179-W12809647996963CE554BC9D7AD0@phx.gbl>
Message-ID: <CA+1OW+goC2P45TgggzW1oE2Bovo6PRqCfD9d8P7cS3A+=-nwLg@mail.gmail.com>

You can take a look at how example demo app does this:

https://github.com/keycloak/keycloak/blob/1.9.0.CR1/examples/demo-template/customer-app/src/main/webapp/customers/view.jsp#L16

On Tue, Feb 16, 2016 at 5:44 PM, Bill Simakis <smacksnr at hotmail.com> wrote:
> I have a web app using the spring security adapter which I have successfully integrated for the authentication/Authorization with KeyCloak.
> We wanted to make the user's life a little easier by providing a link within our app to allow an authenticated user to go to their Account page in KeyCloak. As this link is realm specific, is there a way we could get the url dynamically?
>
> Thanks
>
> Bill
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From pblair at clearme.com  Tue Feb 16 16:33:50 2016
From: pblair at clearme.com (Paul Blair)
Date: Tue, 16 Feb 2016 21:33:50 +0000
Subject: [keycloak-user] 1.8.1.Final SQL error
Message-ID: <D2E8FFE0.11841%pblair@clearme.com>

This doesn't seem to have recurred. Not sure what happened there.

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of "pblair at clearme.com<mailto:pblair at clearme.com>" <pblair at clearme.com<mailto:pblair at clearme.com>>
Date: Tuesday, February 16, 2016 at 2:40 PM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: [keycloak-user] 1.8.1.Final SQL error

I've just installed Keycloak 1.8.1.Final in a clean environment with a new Postgres database instance.  I'm getting an error on startup that the column direct_grants_only does not exist on the CLIENT table. When I log in to the database I can confirm it's not there; otherwise the tables all seem to be set up, and the CLIENT table does have a direct_access_grants_enabled column. I've verified that the server is running WildFly 10.0.0.Final and that all the Keycloak jars under ./modules/system/layers/base/org/keycloak/keycloak-core/main are 1.8.1.Final. I've diffed all the config files where we made changes against older versions of Keycloak and applied them to 1.8.1.Final, and nothing seems relevant.

Also odd is that I have two Keycloak instances running in two separate Docker containers and that I only see this error in one of them. They were both created at the same time by Terraform in exactly the same way.

Any idea what this might be coming from?

17:04:30,706 INFO  [org.keycloak.services.resources.KeycloakApplication] (ServerService Thread Pool -- 50) Load config from /opt/jboss/wildfly/standalone/configuration/keycloak-server.json
17:04:33,048 INFO  [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 50) Updating database
17:04:43,154 ERROR [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 50) Change Set META-INF/jpa-changelog-1.2.0.Final.xml::1.2.0.Final::keycloak failed.  Error: ERROR: column "direct_grants_only" does not exist
  Position: 59 [Failed SQL: UPDATE public.CLIENT SET DIRECT_GRANTS_ONLY = FALSE WHERE DIRECT_GRANTS_ONLY is null]: liquibase.exception.DatabaseException: ERROR: column "direct_grants_only" does not exist
  Position: 59 [Failed SQL: UPDATE public.CLIENT SET DIRECT_GRANTS_ONLY = FALSE WHERE DIRECT_GRANTS_ONLY is null]
at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:316)
at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:55)
at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:122)
at liquibase.database.AbstractJdbcDatabase.execute(AbstractJdbcDatabase.java:1247)
at liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1230)
at liquibase.changelog.ChangeSet.execute(ChangeSet.java:548)
at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:51)
at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73)
at liquibase.Liquibase.update(Liquibase.java:210)
at liquibase.Liquibase.update(Liquibase.java:190)
at liquibase.Liquibase.update(Liquibase.java:186)
at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:153)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)
at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
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:103)
at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)
at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)
at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)
at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:139)
at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:82)
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:408)
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: org.postgresql.util.PSQLException: ERROR: column "direct_grants_only" does not exist
  Position: 59
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2198)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1927)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:561)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:405)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:397)
at org.jboss.jca.adapters.jdbc.WrappedStatement.execute(WrappedStatement.java:198)
at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:314)
... 47 more
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160216/1f1aae90/attachment.html 

From zaquas at gmail.com  Tue Feb 16 18:59:13 2016
From: zaquas at gmail.com (Stefano Zaccaria)
Date: Wed, 17 Feb 2016 00:59:13 +0100
Subject: [keycloak-user] Use keycloak as I used picketlink
In-Reply-To: <CACUY9A=F6pmT1-qyC2UVcbdt=HoYoRT3wmpgW7cpxvrBBHrV7A@mail.gmail.com>
References: <CACUY9A=F6pmT1-qyC2UVcbdt=HoYoRT3wmpgW7cpxvrBBHrV7A@mail.gmail.com>
Message-ID: <CACUY9Amnq_WEcr=RP0i_HEVSeyP+bX63mTRua121-CFeMXMsvw@mail.gmail.com>

Hello to all,
I want to change from picketlink to keycloak
In my ee app I use keycloack CDI to check the user roles and grant with
BasicModel.hasRole(relationshipManager, identity.getAccount(),
BasicModel.getRole(identityManager, "admin"))
or
Authorization Util.hasRole(identity, partitionManager, "admin");
in my bean methods
How can I made the same thing with Keycloak?
Thanks in advantage

Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/bc3e1ec6/attachment-0001.html 

From psilva at redhat.com  Tue Feb 16 20:37:17 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 16 Feb 2016 20:37:17 -0500 (EST)
Subject: [keycloak-user] Use keycloak as I used picketlink
In-Reply-To: <CACUY9Amnq_WEcr=RP0i_HEVSeyP+bX63mTRua121-CFeMXMsvw@mail.gmail.com>
References: <CACUY9A=F6pmT1-qyC2UVcbdt=HoYoRT3wmpgW7cpxvrBBHrV7A@mail.gmail.com>
	<CACUY9Amnq_WEcr=RP0i_HEVSeyP+bX63mTRua121-CFeMXMsvw@mail.gmail.com>
Message-ID: <880645123.23989036.1455673037969.JavaMail.zimbra@redhat.com>

Hi Stefano,

    In KC you can use standard JEE security mechanisms to perform RBAC. 

    Another thing you can do is obtain a KeycloakSecurityContext and get roles or any other claim from there. Something like:

        KeycloakSecurityContext securityContext = (KeycloakSecurityContext) request.getAttribute(KeycloakSecurityContext.class.getName());
        AccessToken token = securityContext.getToken();
        AccessToken.Access realmAccess = token.getRealmAccess();
                
        if (realmAccess.isUserInRole("admin")) {
            // do admin stuff
        }

    You can use a lot of information from the AccessToken to perform local authorization checks. Above is RBAC, but you can also use claims to perform ABAC, for instance.

Regards.
Pedro Igor

----- Original Message -----
From: "Stefano Zaccaria" <zaquas at gmail.com>
To: keycloak-user at lists.jboss.org
Sent: Tuesday, February 16, 2016 9:59:13 PM
Subject: [keycloak-user] Use keycloak as I used picketlink




Hello to all, 
I want to change from picketlink to keycloak 
In my ee app I use keycloack CDI to check the user roles and grant with BasicModel.hasRole(relationshipManager, identity.getAccount(), BasicModel.getRole(identityManager, "admin")) 
or 
Authorization Util.hasRole(identity, partitionManager, "admin"); 
in my bean methods 
How can I made the same thing with Keycloak? 
Thanks in advantage 

Stefano 

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

From akaya at expedia.com  Wed Feb 17 00:55:30 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Wed, 17 Feb 2016 05:55:30 +0000
Subject: [keycloak-user] Disabling status cookie
In-Reply-To: <56C31853.1080904@redhat.com>
References: <D2E905E8.28CE%akaya@expedia.com> <56C31853.1080904@redhat.com>
Message-ID: <D2EA47AB.291D%akaya@expedia.com>

Thanks for the suggestion. It works just as expected. I was also wondering how would direct grant API use TOTP? I tried using it, before configuring I received {"error_description":"Account is not fully set up","error":"invalid_grant"} however after setting the account I kept getting {"error_description":"Invalid user credentials","error":"invalid_grant"} this is how I requested:

curl -X POST 'http://localhost:8080/auth/realms/demo/protocol/openid-connect/token' --data 'username=sarp&password=pass1234&grant_type=password&client_id=admin-cli' -v

Have I done something incorrect when requesting for a token?

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>>
Date: Tuesday, February 16, 2016 at 10:38 PM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Disabling status cookie

See our direct grant API.    Here's an example:

https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java

I *STRONGLY* suggest you do not use the direct grant API for browser-based applications.  Otherwise you lose 90% of the features of Keycloak.  Use the direct grant API for REST clients, that's what it was designed for.

On 2/16/2016 1:59 AM, Sarp Kaya wrote:
Hello,

I want my users to be able to login via API calls with our without requiring a browser. I looked at examples and found customer-app-cli, however I realised that even with manual login, the current workflow requires a browser to login. I found that every time when
http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob

this page loads we get a form with a different code. In theory we should be able to just stick username and password in the body and be able to get 302 response. However when I get the curl equivalent of what browser is doing I've gotten the below:

curl 'http://localhost:8080/auth/realms/demo/login-actions/authenticate?code=oY8nS7rFOlwYHNJwWS6kcw88jbxluo8EuDmZ_o5TWsw.431db3e8-6234-4ba5-8818-ed0335b8ee72&execution=08d88824-1286-4455-b5d1-07240bda8efd' -H 'Cookie: KEYCLOAK_STATE_CHECKER=a2teB_8_wfAfD9VtmV0DJhqDEuM9187r58mVW24Gfrg; KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjQzMWRiM2U4LTYyMzQtNGJhNS04ODE4LWVkMDMzNWI4ZWU3MiIsImNpZCI6ImN1c3RvbWVyLXBvcnRhbC1jbGkiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZGVtby9wcm90b2NvbC9vcGVuaWQtY29ubmVjdC9vYXV0aC9vb2IiLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYTA1MzFlNTYtZjk0Zi00NmM4LWFlNGUtNjQ4MDUyNDc2ZjEwIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9hdXRoL3JlYWxtcy9kZW1vIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJyZWRpcmVjdF91cmkiOiJ1cm46aWV0Zjp3ZzpvYXV0aDoyLjA6b29iIn19.B5vuMj-fafRAS0gJ6m-OrU5cX0atABuWy252y5k7jr0' -H 'Origin: http://localhost:8080' -H 'Accept-Encoding: gzip, deflate' -H 'Accept-Language: en-US,en;q=0.8' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36' -H 'Content-Type: application/x-www-form-urlencoded' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Cache-Control: max-age=0' -H 'Referer: http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob' -H 'Connection: keep-alive' --data 'username=sarp&password=pass1234&login=Log+in' -compressed

I was hoping not to use the cookies and just change the code bit with a new request to the page mentioned above and expect 302 response, however I am getting 500 responses saying error occurred instead.

I looked on admin management console, but could not really find a way to disable cookies for the given client or the realm. I am guessing that one of those cookies are encrypting something that is required and not using it simply prevents logging in successfully. So how can I disable this requirement?

Kind Regards,
Sarp Kaya



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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/df2c5d6d/attachment.html 

From mposolda at redhat.com  Wed Feb 17 02:42:02 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 08:42:02 +0100
Subject: [keycloak-user] 1.8.1.Final SQL error
In-Reply-To: <D2E8FFE0.11841%pblair@clearme.com>
References: <D2E8FFE0.11841%pblair@clearme.com>
Message-ID: <56C4244A.2090606@redhat.com>

Ah, good to know as here PostgreSQL works fine.

I guess your DB wasn't properly cleaned, but just partially, which is 
worst situation as DB is in inconsistent state and Keycloak can't solve 
this type of DB mess. Keycloak is supposed to handle start against empty 
DB or upgrade against DB from previous version.

Marek

On 16/02/16 22:33, Paul Blair wrote:
> This doesn't seem to have recurred. Not sure what happened there.
>
> From: <keycloak-user-bounces at lists.jboss.org 
> <mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of 
> "pblair at clearme.com <mailto:pblair at clearme.com>" <pblair at clearme.com 
> <mailto:pblair at clearme.com>>
> Date: Tuesday, February 16, 2016 at 2:40 PM
> To: "keycloak-user at lists.jboss.org 
> <mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org 
> <mailto:keycloak-user at lists.jboss.org>>
> Subject: [keycloak-user] 1.8.1.Final SQL error
>
> I've just installed Keycloak 1.8.1.Final in a clean environment with a 
> new Postgres database instance.  I'm getting an error on startup that 
> the column direct_grants_only does not exist on the CLIENT table. When 
> I log in to the database I can confirm it's not there; otherwise the 
> tables all seem to be set up, and the CLIENT table does have 
> a direct_access_grants_enabled column. I've verified that the server 
> is running WildFly 10.0.0.Final and that all the Keycloak jars 
> under ./modules/system/layers/base/org/keycloak/keycloak-core/main are 
> 1.8.1.Final. I've diffed all the config files where we made changes 
> against older versions of Keycloak and applied them to 1.8.1.Final, 
> and nothing seems relevant.
>
> Also odd is that I have two Keycloak instances running in two separate 
> Docker containers and that I only see this error in one of them. They 
> were both created at the same time by Terraform in exactly the same way.
>
> Any idea what this might be coming from?
>
> 17:04:30,706 INFO 
>  [org.keycloak.services.resources.KeycloakApplication] (ServerService 
> Thread Pool -- 50) Load config from 
> /opt/jboss/wildfly/standalone/configuration/keycloak-server.json
> 17:04:33,048 INFO 
>  [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] 
> (ServerService Thread Pool -- 50) Updating database
> 17:04:43,154 ERROR 
> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] 
> (ServerService Thread Pool -- 50) Change Set 
> META-INF/jpa-changelog-1.2.0.Final.xml::1.2.0.Final::keycloak failed. 
>  Error: ERROR: column "direct_grants_only" does not exist
>   Position: 59 [Failed SQL: UPDATE public.CLIENT SET 
> DIRECT_GRANTS_ONLY = FALSE WHERE DIRECT_GRANTS_ONLY is null]: 
> liquibase.exception.DatabaseException: ERROR: column 
> "direct_grants_only" does not exist
>   Position: 59 [Failed SQL: UPDATE public.CLIENT SET 
> DIRECT_GRANTS_ONLY = FALSE WHERE DIRECT_GRANTS_ONLY is null]
> at 
> liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:316)
> at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:55)
> at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:122)
> at 
> liquibase.database.AbstractJdbcDatabase.execute(AbstractJdbcDatabase.java:1247)
> at 
> liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1230)
> at liquibase.changelog.ChangeSet.execute(ChangeSet.java:548)
> at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:51)
> at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73)
> at liquibase.Liquibase.update(Liquibase.java:210)
> at liquibase.Liquibase.update(Liquibase.java:190)
> at liquibase.Liquibase.update(Liquibase.java:186)
> at 
> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84)
> at 
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:153)
> at 
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)
> at 
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)
> at 
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
> 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:103)
> at 
> org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)
> at 
> org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)
> at 
> org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)
> at 
> org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:139)
> at 
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:82)
> 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:408)
> at 
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
> at 
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
> at 
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
> at 
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
> at 
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
> at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at 
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at 
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at 
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at 
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
> at 
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
> at 
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
> at 
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
> at 
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: org.postgresql.util.PSQLException: ERROR: column 
> "direct_grants_only" does not exist
>   Position: 59
> at 
> org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2198)
> at 
> org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1927)
> at 
> org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
> at 
> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:561)
> at 
> org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:405)
> at 
> org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:397)
> at 
> org.jboss.jca.adapters.jdbc.WrappedStatement.execute(WrappedStatement.java:198)
> at 
> liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:314)
> ... 47 more
>
>
> _______________________________________________
> 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/20160217/db22b870/attachment-0001.html 

From zaquas at gmail.com  Wed Feb 17 02:41:59 2016
From: zaquas at gmail.com (Stefano Zaccaria)
Date: Wed, 17 Feb 2016 08:41:59 +0100
Subject: [keycloak-user] Use keycloak as I used picketlink
In-Reply-To: <880645123.23989036.1455673037969.JavaMail.zimbra@redhat.com>
References: <CACUY9A=F6pmT1-qyC2UVcbdt=HoYoRT3wmpgW7cpxvrBBHrV7A@mail.gmail.com>
	<CACUY9Amnq_WEcr=RP0i_HEVSeyP+bX63mTRua121-CFeMXMsvw@mail.gmail.com>
	<880645123.23989036.1455673037969.JavaMail.zimbra@redhat.com>
Message-ID: <CACUY9Am1=y4V80F8oP0YrsbH79bCSVCPch0XEnn-_uzga3hw+w@mail.gmail.com>

Thanks Pedro!
You are been so clear!!!
So, excuse for my pedantry, the old stuff that I had used with picketlink
and deltaspike I must forget:

es: @LoggedIn, CDI that call picketlink lib etc etc.

In clear I must use only the code that you suggest me... what I read in our
site, in particular in http://picketlink.org/keycloak-merge-faq/

"Q) What happens with PicketLink Java EE related capabilities
A) Based on experience gained with PicketLink project we?ll be introducing
Keycloak SDK component including libraries for easier integration with Java
EE applications"

It must interpret as the code you suggest me?

Thanks very much!



2016-02-17 2:37 GMT+01:00 Pedro Igor Silva <psilva at redhat.com>:

> Hi Stefano,
>
>     In KC you can use standard JEE security mechanisms to perform RBAC.
>
>     Another thing you can do is obtain a KeycloakSecurityContext and get
> roles or any other claim from there. Something like:
>
>         KeycloakSecurityContext securityContext =
> (KeycloakSecurityContext)
> request.getAttribute(KeycloakSecurityContext.class.getName());
>         AccessToken token = securityContext.getToken();
>         AccessToken.Access realmAccess = token.getRealmAccess();
>
>         if (realmAccess.isUserInRole("admin")) {
>             // do admin stuff
>         }
>
>     You can use a lot of information from the AccessToken to perform local
> authorization checks. Above is RBAC, but you can also use claims to perform
> ABAC, for instance.
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Stefano Zaccaria" <zaquas at gmail.com>
> To: keycloak-user at lists.jboss.org
> Sent: Tuesday, February 16, 2016 9:59:13 PM
> Subject: [keycloak-user] Use keycloak as I used picketlink
>
>
>
>
> Hello to all,
> I want to change from picketlink to keycloak
> In my ee app I use keycloack CDI to check the user roles and grant with
> BasicModel.hasRole(relationshipManager, identity.getAccount(),
> BasicModel.getRole(identityManager, "admin"))
> or
> Authorization Util.hasRole(identity, partitionManager, "admin");
> in my bean methods
> How can I made the same thing with Keycloak?
> Thanks in advantage
>
> Stefano
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>



-- 
*Stefano*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/c17ad289/attachment.html 

From jrevillard at gnubila.fr  Wed Feb 17 03:07:32 2016
From: jrevillard at gnubila.fr (=?UTF-8?B?SsOpcsO0bWUgUmV2aWxsYXJk?=)
Date: Wed, 17 Feb 2016 09:07:32 +0100
Subject: [keycloak-user] Adapter trustore: use default java trustore
	possible ?
Message-ID: <56C42A44.7070507@gnubila.fr>

Dear all,

I'm testing now a Keycloak server properly configured with https 
configuration.
The server certificate is one which is already known by the default java 
trustore.
Would it be possible to setup the keycloak.json adapter config to use 
this default java trustore ?

Best,
Jerome

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3908 bytes
Desc: Signature cryptographique S/MIME
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/71d20ac1/attachment.bin 

From tech at psynd.net  Wed Feb 17 03:53:20 2016
From: tech at psynd.net (Tech @ PSYND)
Date: Wed, 17 Feb 2016 09:53:20 +0100
Subject: [keycloak-user] OpenAM migration to Keycloak
Message-ID: <e8c615efb4ab49de08e8e82e2c5ead4f@psynd.net>

Hi all,

my customer and we are evaluating a migration from OpenAM to Keycloak, 
did anybody here already experienced this?
Are there any bottlenecks that we should take into account before 
starting the project?

Thanks!

Mauro

From Edgar at info.nl  Wed Feb 17 03:57:54 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Wed, 17 Feb 2016 08:57:54 +0000
Subject: [keycloak-user] Frequent LDAP bind failed socket connection reset
 exceptions in Keycloak LDAP user federation
Message-ID: <5F0501E4-FEB6-4840-BC64-2FF0823A0B73@info.nl>

hi,

We are getting frequent LDAP simple bind failed, socket exceptions, when communicating with our Active Directory server using the Keycloak user federation provider. The might very well be a problem on the AD side of things or perhaps in our network, but I was wondering if it might be something in Keycloak? We have not been able to narrow it down so far.

It happens quite often for example when manually synching users from AD to Keycloak but also for example when creating a new user from Keycloak to AD. When you try any such action again it always succeeds. It seems some sort of hiccup.

09:08:23,080 ERROR [org.keycloak.services] LDAP Query failed
org.keycloak.models.ModelException: LDAP Query failed
	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:168)
	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getFirstResult(LDAPQuery.java:175)
	at org.keycloak.federation.ldap.LDAPFederationProvider.loadLDAPUserByUsername(LDAPFederationProvider.java:504)

[..]

Caused by: org.keycloak.models.ModelException: Querying of LDAP failed org.keycloak.federation.ldap.idm.query.internal.LDAPQuery at 12228106
	at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:169)
	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:164)
	... 54 more
Caused by: javax.naming.CommunicationException: simple bind failed: ldap.hf.info.nl:636 [Root exception is java.net.SocketException: Connection reset]
	at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788)
	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
	at javax.naming.InitialContext.init(InitialContext.java:244)
	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.createLdapContext(LDAPOperationManager.java:473)
	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:541)
	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.search(LDAPOperationManager.java:166)
	at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:160)
	... 55 more
Caused by: java.net.SocketException: Connection reset
	at java.net.SocketInputStream.read(SocketInputStream.java:209)
	at java.net.SocketInputStream.read(SocketInputStream.java:141)
	at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
	at sun.security.ssl.InputRecord.read(InputRecord.java:503)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
	at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:426)
	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:399)
	at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
	at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
	... 69 more

From bruno at abstractj.org  Wed Feb 17 05:01:25 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 17 Feb 2016 10:01:25 +0000
Subject: [keycloak-user] Disabling status cookie
In-Reply-To: <D2EA47AB.291D%akaya@expedia.com>
References: <D2E905E8.28CE%akaya@expedia.com> <56C31853.1080904@redhat.com>
	<D2EA47AB.291D%akaya@expedia.com>
Message-ID: <CAM5SUC56TMCTA=A7-JGZViWNVbg2LcpZiTyjbct6KR=3LNErhQ@mail.gmail.com>

I believe that Stian recently replied here
http://lists.jboss.org/pipermail/keycloak-user/2016-January/004484.html


On Wed, Feb 17, 2016 at 3:55 AM Sarp Kaya <akaya at expedia.com> wrote:

> Thanks for the suggestion. It works just as expected. I was also wondering
> how would direct grant API use TOTP? I tried using it, before configuring I
> received {"error_description":"Account is not fully set
> up","error":"invalid_grant"} however after setting the account I kept
> getting {"error_description":"Invalid user
> credentials","error":"invalid_grant"} this is how I requested:
>
> curl -X POST '
> http://localhost:8080/auth/realms/demo/protocol/openid-connect/token'
> --data
> 'username=sarp&password=pass1234&grant_type=password&client_id=admin-cli' -v
> Have I done something incorrect when requesting for a token?
>
> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Bill Burke <
> bburke at redhat.com>
> Date: Tuesday, February 16, 2016 at 10:38 PM
> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Disabling status cookie
>
> See our direct grant API.    Here's an example:
>
>
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java
>
> I *STRONGLY* suggest you do not use the direct grant API for browser-based
> applications.  Otherwise you lose 90% of the features of Keycloak.  Use the
> direct grant API for REST clients, that's what it was designed for.
>
> On 2/16/2016 1:59 AM, Sarp Kaya wrote:
>
> Hello,
>
> I want my users to be able to login via API calls with our without
> requiring a browser. I looked at examples and found customer-app-cli,
> however I realised that even with manual login, the current workflow
> requires a browser to login. I found that every time when
>
> http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
>
> this page loads we get a form with a different code. In theory we should
> be able to just stick username and password in the body and be able to get
> 302 response. However when I get the curl equivalent of what browser is
> doing I?ve gotten the below:
>
> curl '
> http://localhost:8080/auth/realms/demo/login-actions/authenticate?code=oY8nS7rFOlwYHNJwWS6kcw88jbxluo8EuDmZ_o5TWsw.431db3e8-6234-4ba5-8818-ed0335b8ee72&execution=08d88824-1286-4455-b5d1-07240bda8efd'
> -H 'Cookie:
> KEYCLOAK_STATE_CHECKER=a2teB_8_wfAfD9VtmV0DJhqDEuM9187r58mVW24Gfrg;
> KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjQzMWRiM2U4LTYyMzQtNGJhNS04ODE4LWVkMDMzNWI4ZWU3MiIsImNpZCI6ImN1c3RvbWVyLXBvcnRhbC1jbGkiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZGVtby9wcm90b2NvbC9vcGVuaWQtY29ubmVjdC9vYXV0aC9vb2IiLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYTA1MzFlNTYtZjk0Zi00NmM4LWFlNGUtNjQ4MDUyNDc2ZjEwIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9hdXRoL3JlYWxtcy9kZW1vIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJyZWRpcmVjdF91cmkiOiJ1cm46aWV0Zjp3ZzpvYXV0aDoyLjA6b29iIn19.B5vuMj-fafRAS0gJ6m-OrU5cX0atABuWy252y5k7jr0'
> -H 'Origin: http://localhost:8080' -H 'Accept-Encoding: gzip, deflate' -H
> 'Accept-Language: en-US,en;q=0.8' -H 'Upgrade-Insecure-Requests: 1' -H
> 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36'
> -H 'Content-Type: application/x-www-form-urlencoded' -H 'Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
> -H 'Cache-Control: max-age=0' -H 'Referer:
> http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob'
> -H 'Connection: keep-alive' --data
> 'username=sarp&password=pass1234&login=Log+in' ?compressed
>
> I was hoping not to use the cookies and just change the code bit with a
> new request to the page mentioned above and expect 302 response, however I
> am getting 500 responses saying error occurred instead.
>
> I looked on admin management console, but could not really find a way to
> disable cookies for the given client or the realm. I am guessing that one
> of those cookies are encrypting something that is required and not using it
> simply prevents logging in successfully. So how can I disable this
> requirement?
>
> Kind Regards,
> Sarp Kaya
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160217/a02ca4b5/attachment-0001.html 

From bruno at abstractj.org  Wed Feb 17 05:09:32 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 17 Feb 2016 10:09:32 +0000
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <56C42A44.7070507@gnubila.fr>
References: <56C42A44.7070507@gnubila.fr>
Message-ID: <CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>

I'm not sure if I got your question in the right way. But from my
understanding Java truststore is the standard fall back.

See item 3.2.5
https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html

On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard <jrevillard at gnubila.fr>
wrote:

> Dear all,
>
> I'm testing now a Keycloak server properly configured with https
> configuration.
> The server certificate is one which is already known by the default java
> trustore.
> Would it be possible to setup the keycloak.json adapter config to use
> this default java trustore ?
>
> Best,
> Jerome
>
> _______________________________________________
> 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/20160217/23b4599f/attachment.html 

From jrevillard at gnubila.fr  Wed Feb 17 05:19:36 2016
From: jrevillard at gnubila.fr (=?UTF-8?B?SsOpcsO0bWUgUmV2aWxsYXJk?=)
Date: Wed, 17 Feb 2016 11:19:36 +0100
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
Message-ID: <56C44938.30507@gnubila.fr>

Yes, it seems to be the case for the server, but not for the clients. 
See the trustore config description here: 
https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config

Best,
Jerome

Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
> I'm not sure if I got your question in the right way. But from my 
> understanding Java truststore is the standard fall back.
>
> See item 3.2.5 
> https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
>
> On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard 
> <jrevillard at gnubila.fr <mailto:jrevillard at gnubila.fr>> wrote:
>
>     Dear all,
>
>     I'm testing now a Keycloak server properly configured with https
>     configuration.
>     The server certificate is one which is already known by the
>     default java
>     trustore.
>     Would it be possible to setup the keycloak.json adapter config to use
>     this default java trustore ?
>
>     Best,
>     Jerome
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/0ade2e45/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3908 bytes
Desc: Signature cryptographique S/MIME
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/0ade2e45/attachment.bin 

From ivan at akvo.org  Wed Feb 17 05:34:56 2016
From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=)
Date: Wed, 17 Feb 2016 11:34:56 +0100
Subject: [keycloak-user] Undertow adapter documentation
Message-ID: <56C44CD0.2020800@akvo.org>

Hi all,

There is some Undertow related code [1] but is not documented in the
"Adapters" section.

Is Undertow a supported server? If so, any hints on how to enable the
adapter?


[1]
https://github.com/keycloak/keycloak/tree/1.8.1.Final/integration/undertow

Thanks,

-- 
Iv?n

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/84aedc43/attachment.bin 

From porfyrios.vasileiou at gmail.com  Wed Feb 17 06:37:58 2016
From: porfyrios.vasileiou at gmail.com (Porfyrios Vasileiou)
Date: Wed, 17 Feb 2016 13:37:58 +0200
Subject: [keycloak-user] LDAP username mapping from active directory fails
Message-ID: <CAHa5F_u1Nfxs8eXVq=7_xS7cowjV8=Gy1MshjkmKFzTjk6XWsw@mail.gmail.com>

Hello, i created a new ldap federation in the keycloak settings and
imported all users. The thing is that the username attribute was mapped to
the ldap cn attribute whereas the username in active directory is
sAMAccountName. Therefore i changed the ldapAttribute to that.

Now when i go to my ldap settings page and click on "Synchronize" the users
fail to update and i am getting this error:

13:31:53,899 ERROR
[org.keycloak.federation.ldap.LDAPFederationProviderFactory] (default
task-25) Failed during import user from LDAP: org.keycloak.mo
dels.ModelException: User returned from LDAP has null username! Check
configuration of your LDAP mappings. Mapped username LDAP attribute: cn,
user DN
: CN=internal2 lastname,OU=DTPH,DC=dls,DC=lan, attributes from LDAP:
{whenChanged=[20160217110433.0Z], whenCreated=[20160217110433.0Z],
sAMAccountName
=[internal2], givenName=[internal2], sn=[lastname],
userAccountControl=[512], pwdLastSet=[131001806735067575]}

If u put it back to cn it works, but i want to use sAMAccountName for the
username.

Why does this happen ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/b3a72df7/attachment.html 

From tdudgeon.ml at gmail.com  Wed Feb 17 07:30:21 2016
From: tdudgeon.ml at gmail.com (Tim Dudgeon)
Date: Wed, 17 Feb 2016 12:30:21 +0000
Subject: [keycloak-user] SSL port on docker images
Message-ID: <56C467DD.3080709@gmail.com>

Can the SSL port on the docker images be exposed?
Currently only port 8080 is exposed. Why not 8443?

Tim

From alexander.schwartz at gmx.net  Wed Feb 17 07:32:06 2016
From: alexander.schwartz at gmx.net (Alexander Schwartz)
Date: Wed, 17 Feb 2016 13:32:06 +0100
Subject: [keycloak-user] Impersonating User via API
Message-ID: <56C46846.4050204@gmx.net>

Hello Keycloak Community,

I want to use impersonate a user via API.

The start point is a logged in user with an access token.

The goal is to have an access and refresh token of an impersonated user.

In a proof-of-concept I've used the impersonation admin API, but this 
returns only cookies and redirects. When I follow the redirects I will 
eventually retrieve access and refresh token.

I wonder if there is a better suited API to obtain them directly.

Thank you very much,
Alexander

-- 
Alexander Schwartz (alexander.schwartz at gmx.net)
http://www.ahus1.de


From psilva at redhat.com  Wed Feb 17 07:35:18 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 17 Feb 2016 07:35:18 -0500 (EST)
Subject: [keycloak-user] Use keycloak as I used picketlink
In-Reply-To: <CACUY9Am1=y4V80F8oP0YrsbH79bCSVCPch0XEnn-_uzga3hw+w@mail.gmail.com>
References: <CACUY9A=F6pmT1-qyC2UVcbdt=HoYoRT3wmpgW7cpxvrBBHrV7A@mail.gmail.com>
	<CACUY9Amnq_WEcr=RP0i_HEVSeyP+bX63mTRua121-CFeMXMsvw@mail.gmail.com>
	<880645123.23989036.1455673037969.JavaMail.zimbra@redhat.com>
	<CACUY9Am1=y4V80F8oP0YrsbH79bCSVCPch0XEnn-_uzga3hw+w@mail.gmail.com>
Message-ID: <889670090.24214746.1455712518603.JavaMail.zimbra@redhat.com>

Yes, that is what you can use. But nothing stops you from creating a CDI layer on top of it to better integrate with your app.

In your example, you can easily create an Identity-like and AuthorizationManager-like beans in order to hide/centralize security logic from the rest of your app.

Thanks.

----- Original Message -----
From: "Stefano Zaccaria" <zaquas at gmail.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-user at lists.jboss.org
Sent: Wednesday, February 17, 2016 5:41:59 AM
Subject: Re: [keycloak-user] Use keycloak as I used picketlink

Thanks Pedro!
You are been so clear!!!
So, excuse for my pedantry, the old stuff that I had used with picketlink
and deltaspike I must forget:

es: @LoggedIn, CDI that call picketlink lib etc etc.

In clear I must use only the code that you suggest me... what I read in our
site, in particular in http://picketlink.org/keycloak-merge-faq/

"Q) What happens with PicketLink Java EE related capabilities
A) Based on experience gained with PicketLink project we?ll be introducing
Keycloak SDK component including libraries for easier integration with Java
EE applications"

It must interpret as the code you suggest me?

Thanks very much!



2016-02-17 2:37 GMT+01:00 Pedro Igor Silva <psilva at redhat.com>:

> Hi Stefano,
>
>     In KC you can use standard JEE security mechanisms to perform RBAC.
>
>     Another thing you can do is obtain a KeycloakSecurityContext and get
> roles or any other claim from there. Something like:
>
>         KeycloakSecurityContext securityContext =
> (KeycloakSecurityContext)
> request.getAttribute(KeycloakSecurityContext.class.getName());
>         AccessToken token = securityContext.getToken();
>         AccessToken.Access realmAccess = token.getRealmAccess();
>
>         if (realmAccess.isUserInRole("admin")) {
>             // do admin stuff
>         }
>
>     You can use a lot of information from the AccessToken to perform local
> authorization checks. Above is RBAC, but you can also use claims to perform
> ABAC, for instance.
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Stefano Zaccaria" <zaquas at gmail.com>
> To: keycloak-user at lists.jboss.org
> Sent: Tuesday, February 16, 2016 9:59:13 PM
> Subject: [keycloak-user] Use keycloak as I used picketlink
>
>
>
>
> Hello to all,
> I want to change from picketlink to keycloak
> In my ee app I use keycloack CDI to check the user roles and grant with
> BasicModel.hasRole(relationshipManager, identity.getAccount(),
> BasicModel.getRole(identityManager, "admin"))
> or
> Authorization Util.hasRole(identity, partitionManager, "admin");
> in my bean methods
> How can I made the same thing with Keycloak?
> Thanks in advantage
>
> Stefano
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>



-- 
*Stefano*


From Edgar at info.nl  Wed Feb 17 07:48:16 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Wed, 17 Feb 2016 12:48:16 +0000
Subject: [keycloak-user] LDAP username mapping from active directory
	fails
In-Reply-To: <CAHa5F_u1Nfxs8eXVq=7_xS7cowjV8=Gy1MshjkmKFzTjk6XWsw@mail.gmail.com>
References: <CAHa5F_u1Nfxs8eXVq=7_xS7cowjV8=Gy1MshjkmKFzTjk6XWsw@mail.gmail.com>
Message-ID: <868CA6DF-BB2C-4CAB-A4D3-3C661123382F@info.nl>

Hi Porfyrios,

Not completely sure but it might be this issue or related to it:
https://issues.jboss.org/browse/KEYCLOAK-2403

?

cheers

On 17 Feb 2016, at 12:37, Porfyrios Vasileiou <porfyrios.vasileiou at gmail.com<mailto:porfyrios.vasileiou at gmail.com>> wrote:

Hello, i created a new ldap federation in the keycloak settings and imported all users. The thing is that the username attribute was mapped to the ldap cn attribute whereas the username in active directory is sAMAccountName. Therefore i changed the ldapAttribute to that.

Now when i go to my ldap settings page and click on "Synchronize" the users fail to update and i am getting this error:

13:31:53,899 ERROR [org.keycloak.federation.ldap.LDAPFederationProviderFactory] (default task-25) Failed during import user from LDAP: org.keycloak.mo<http://org.keycloak.mo/>
dels.ModelException: User returned from LDAP has null username! Check configuration of your LDAP mappings. Mapped username LDAP attribute: cn, user DN
: CN=internal2 lastname,OU=DTPH,DC=dls,DC=lan, attributes from LDAP: {whenChanged=[20160217110433.0Z], whenCreated=[20160217110433.0Z], sAMAccountName
=[internal2], givenName=[internal2], sn=[lastname], userAccountControl=[512], pwdLastSet=[131001806735067575]}

If u put it back to cn it works, but i want to use sAMAccountName for the username.

Why does this happen ?
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/40f14e1d/attachment.html 

From leo.nunes at gjccorp.com.br  Wed Feb 17 08:11:55 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Wed, 17 Feb 2016 13:11:55 +0000
Subject: [keycloak-user] KeycloakSecurityContext returns NULL using Tomcat
	Adapter
Message-ID: <D2EA05F9.267CC%leo.nunes@ojc.com.br>

Hi everyone,

I have an application deployed on Tomcat 7 using the Tomcat Adapter.
When i'm logged in and I go to a non-secured URL, KeycloakSecurityContext returns null.
I deployed the same application to the Keycloak Standalone Server, there I don't have this problem.

The code below returns null when called from /movies/, and works when called from /article/
(KeycloakSecurityContext) request.getAttribute(KeycloakSecurityContext.class.getName());

In my web.xml I have only one security-constraint securing /article/*

WEB.XML:
<security-constraint>
    <web-resource-collection>
        <web-resource-name>Articles</web-resource-name>
        <url-pattern>/article/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>user</role-name>
    </auth-constraint>
</security-constraint>


________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/0c9713f2/attachment.html 

From kevin at pibenchmark.com  Wed Feb 17 08:23:14 2016
From: kevin at pibenchmark.com (Kevin Thorpe)
Date: Wed, 17 Feb 2016 13:23:14 +0000
Subject: [keycloak-user] SSL port on docker images
In-Reply-To: <56C467DD.3080709@gmail.com>
References: <56C467DD.3080709@gmail.com>
Message-ID: <CAFMa6BYuvLJ0r1DVfxyPgCLGa3EvcGsVmV-164Skrgh_YfRkQg@mail.gmail.com>

Its easy to make your own image on top to expose that port. However in our
case we use keycloak inside docker on 8080 and front it externally with our
main nginx SSL+load balancer
On 17 Feb 2016 12:31 pm, "Tim Dudgeon" <tdudgeon.ml at gmail.com> wrote:

> Can the SSL port on the docker images be exposed?
> Currently only port 8080 is exposed. Why not 8443?
>
> Tim
> _______________________________________________
> 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/20160217/070f7367/attachment-0001.html 

From RLewis at carbonite.com  Wed Feb 17 09:02:00 2016
From: RLewis at carbonite.com (Reed Lewis)
Date: Wed, 17 Feb 2016 14:02:00 +0000
Subject: [keycloak-user] Using Keycloak in AWS EC2. What are people using?
Message-ID: <46C5D66D-6E6C-4885-9E4F-F0AD1A986917@carbonite.com>

I am setting up Keycloak (great product), and need to enable Infinispan cache clustering using another method instead of multicast since AWS does not support multicast.

I have working S3-ping, but it requires my AWS access keys to be configured in the keycloak standalone-ha.xml file which I do not want to have to do because of security reasons.

I have tried to use Native-S3-Ping, https://github.com/zalando/jgroups-native-s3-ping but cannot figure out how to get the support libraries ?FILE-PING? to load

I also read about JDBC-PING which uses a shared database, which looks like a better way to do it since I am using Postgres in RDS for my datastore anyways.

What I am wondering is what are others using to work with AWS?  Can I get example configurations that work well if anyone has any?

Thank you,

Reed Lewis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/225c0ed3/attachment.html 

From nicopozo at gmail.com  Wed Feb 17 09:03:33 2016
From: nicopozo at gmail.com (=?UTF-8?Q?Nicol=C3=A1s_Pozo?=)
Date: Wed, 17 Feb 2016 11:03:33 -0300
Subject: [keycloak-user] Infinispan not working on HA environment with
	dockers.
Message-ID: <CAPLJng9O49JK+tzqs6xfNCc7QTYOqb5fkx-Obf7g8M6kybBvYQ@mail.gmail.com>

Hello all,
I'm trying to set a Keycloak HA environment up with dockers. I tried with
jboss/keycloak-ha-postgres:1.8.0.Final image.

I can't make infinispan work when I run 2 instances of my docker images. I
get the following log in every node:

Received new cluster view for channel ejb: [f9032dc82244|0] (1)
[f9032dc82244]
Received new cluster view for channel hibernate: [f9032dc82244|0] (1)
[f9032dc82244]
Received new cluster view for channel keycloak: [f9032dc82244|0] (1)
[f9032dc82244]
Received new cluster view for channel web: [f9032dc82244|0] (1)
[f9032dc82244]
Channel hibernate local address is f9032dc82244, physical addresses are [
127.0.0.1:55200]
Channel keycloak local address is f9032dc82244, physical addresses are [
127.0.0.1:55200]
Channel ejb local address is f9032dc82244, physical addresses are [
127.0.0.1:55200]
Channel web local address is f9032dc82244, physical addresses are [
127.0.0.1:55200]
Received new cluster view for channel server: [f9032dc82244|0] (1)
[f9032dc82244]
Channel server local address is f9032dc82244, physical addresses are [
127.0.0.1:55200]

This is causing my user sessions are not shared between instances and it's
not working properly.

When I run 2 instances of keycloak without dockers, they work properly.

Am I missing something? Is there any extra configuration that I need to
change?

Thanks,
Nicolas.-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/de18b822/attachment.html 

From akaya at expedia.com  Wed Feb 17 09:39:05 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Wed, 17 Feb 2016 14:39:05 +0000
Subject: [keycloak-user] Disabling status cookie
In-Reply-To: <CAM5SUC56TMCTA=A7-JGZViWNVbg2LcpZiTyjbct6KR=3LNErhQ@mail.gmail.com>
References: <D2E905E8.28CE%akaya@expedia.com> <56C31853.1080904@redhat.com>
	<D2EA47AB.291D%akaya@expedia.com>
	<CAM5SUC56TMCTA=A7-JGZViWNVbg2LcpZiTyjbct6KR=3LNErhQ@mail.gmail.com>
Message-ID: <D2EAC278.294D%akaya@expedia.com>

My issue is not "Account is not fully set up? error, I can ?afford? to set it up through the web ui. The problem is after setting it up the curl that I give does not grant me a token and gives ?Invalid user credentials? error, despite the fact that username and password are correct.
So my question is whether it is possible to get the token using "/auth/realms/{realms}/protocol/openid-connect/token<http://localhost:8080/auth/realms/demo/protocol/openid-connect/token>? or similar API when the account itself has TOTP enabled (and configured)?

From: Bruno Oliveira <bruno at abstractj.org<mailto:bruno at abstractj.org>>
Date: Wednesday, February 17, 2016 at 8:01 PM
To: Abdullah Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>>, Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Disabling status cookie

I believe that Stian recently replied here http://lists.jboss.org/pipermail/keycloak-user/2016-January/004484.html


On Wed, Feb 17, 2016 at 3:55 AM Sarp Kaya <akaya at expedia.com<mailto:akaya at expedia.com>> wrote:
Thanks for the suggestion. It works just as expected. I was also wondering how would direct grant API use TOTP? I tried using it, before configuring I received {"error_description":"Account is not fully set up","error":"invalid_grant"} however after setting the account I kept getting {"error_description":"Invalid user credentials","error":"invalid_grant"} this is how I requested:

curl -X POST 'http://localhost:8080/auth/realms/demo/protocol/openid-connect/token' --data 'username=sarp&password=pass1234&grant_type=password&client_id=admin-cli' -v

Have I done something incorrect when requesting for a token?

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>>
Date: Tuesday, February 16, 2016 at 10:38 PM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Disabling status cookie

See our direct grant API.    Here's an example:

https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java

I *STRONGLY* suggest you do not use the direct grant API for browser-based applications.  Otherwise you lose 90% of the features of Keycloak.  Use the direct grant API for REST clients, that's what it was designed for.

On 2/16/2016 1:59 AM, Sarp Kaya wrote:
Hello,

I want my users to be able to login via API calls with our without requiring a browser. I looked at examples and found customer-app-cli, however I realised that even with manual login, the current workflow requires a browser to login. I found that every time when
http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob

this page loads we get a form with a different code. In theory we should be able to just stick username and password in the body and be able to get 302 response. However when I get the curl equivalent of what browser is doing I?ve gotten the below:

curl 'http://localhost:8080/auth/realms/demo/login-actions/authenticate?code=oY8nS7rFOlwYHNJwWS6kcw88jbxluo8EuDmZ_o5TWsw.431db3e8-6234-4ba5-8818-ed0335b8ee72&execution=08d88824-1286-4455-b5d1-07240bda8efd' -H 'Cookie: KEYCLOAK_STATE_CHECKER=a2teB_8_wfAfD9VtmV0DJhqDEuM9187r58mVW24Gfrg; KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjQzMWRiM2U4LTYyMzQtNGJhNS04ODE4LWVkMDMzNWI4ZWU3MiIsImNpZCI6ImN1c3RvbWVyLXBvcnRhbC1jbGkiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZGVtby9wcm90b2NvbC9vcGVuaWQtY29ubmVjdC9vYXV0aC9vb2IiLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYTA1MzFlNTYtZjk0Zi00NmM4LWFlNGUtNjQ4MDUyNDc2ZjEwIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9hdXRoL3JlYWxtcy9kZW1vIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJyZWRpcmVjdF91cmkiOiJ1cm46aWV0Zjp3ZzpvYXV0aDoyLjA6b29iIn19.B5vuMj-fafRAS0gJ6m-OrU5cX0atABuWy252y5k7jr0' -H 'Origin: http://localhost:8080' -H 'Accept-Encoding: gzip, deflate' -H 'Accept-Language: en-US,en;q=0.8' -H 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36' -H 'Content-Type: application/x-www-form-urlencoded' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Cache-Control: max-age=0' -H 'Referer: http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob' -H 'Connection: keep-alive' --data 'username=sarp&password=pass1234&login=Log+in' ?compressed

I was hoping not to use the cookies and just change the code bit with a new request to the page mentioned above and expect 302 response, however I am getting 500 responses saying error occurred instead.

I looked on admin management console, but could not really find a way to disable cookies for the given client or the realm. I am guessing that one of those cookies are encrypting something that is required and not using it simply prevents logging in successfully. So how can I disable this requirement?

Kind Regards,
Sarp Kaya



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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/97f8262a/attachment-0001.html 

From pblair at clearme.com  Wed Feb 17 09:39:33 2016
From: pblair at clearme.com (Paul Blair)
Date: Wed, 17 Feb 2016 14:39:33 +0000
Subject: [keycloak-user] 1.8.1.Final SQL error
In-Reply-To: <CAJgngAea4aaxVfqcYHUCADBV+Fq_SN4_4Ckh8aXBh0ixRyVxFw@mail.gmail.com>
References: <D2E8FFE0.11841%pblair@clearme.com>
	<CAJgngAea4aaxVfqcYHUCADBV+Fq_SN4_4Ckh8aXBh0ixRyVxFw@mail.gmail.com>
Message-ID: <D2E9F00D.118EF%pblair@clearme.com>

Yes, when I provision the environment, Terraform brings up everything at the same time. I'll have to put a delay in for starting one of the containers.

I saw a different SQL error under similar circumstances, so I'm pretty sure it's that.

From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: Wednesday, February 17, 2016 at 2:01 AM
To: "pblair at clearme.com<mailto:pblair at clearme.com>" <pblair at clearme.com<mailto:pblair at clearme.com>>
Subject: Re: [keycloak-user] 1.8.1.Final SQL error


Did you start two Keycloak containers at the same time pointing to the same db?

On 16 Feb 2016 21:35, "Paul Blair" <pblair at clearme.com<mailto:pblair at clearme.com>> wrote:
This doesn't seem to have recurred. Not sure what happened there.

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of "pblair at clearme.com<mailto:pblair at clearme.com>" <pblair at clearme.com<mailto:pblair at clearme.com>>
Date: Tuesday, February 16, 2016 at 2:40 PM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: [keycloak-user] 1.8.1.Final SQL error

I've just installed Keycloak 1.8.1.Final in a clean environment with a new Postgres database instance.  I'm getting an error on startup that the column direct_grants_only does not exist on the CLIENT table. When I log in to the database I can confirm it's not there; otherwise the tables all seem to be set up, and the CLIENT table does have a direct_access_grants_enabled column. I've verified that the server is running WildFly 10.0.0.Final and that all the Keycloak jars under ./modules/system/layers/base/org/keycloak/keycloak-core/main are 1.8.1.Final. I've diffed all the config files where we made changes against older versions of Keycloak and applied them to 1.8.1.Final, and nothing seems relevant.

Also odd is that I have two Keycloak instances running in two separate Docker containers and that I only see this error in one of them. They were both created at the same time by Terraform in exactly the same way.

Any idea what this might be coming from?

17:04:30,706 INFO  [org.keycloak.services.resources.KeycloakApplication] (ServerService Thread Pool -- 50) Load config from /opt/jboss/wildfly/standalone/configuration/keycloak-server.json
17:04:33,048 INFO  [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 50) Updating database
17:04:43,154 ERROR [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 50) Change Set META-INF/jpa-changelog-1.2.0.Final.xml::1.2.0.Final::keycloak failed.  Error: ERROR: column "direct_grants_only" does not exist
  Position: 59 [Failed SQL: UPDATE public.CLIENT SET DIRECT_GRANTS_ONLY = FALSE WHERE DIRECT_GRANTS_ONLY is null]: liquibase.exception.DatabaseException: ERROR: column "direct_grants_only" does not exist
  Position: 59 [Failed SQL: UPDATE public.CLIENT SET DIRECT_GRANTS_ONLY = FALSE WHERE DIRECT_GRANTS_ONLY is null]
at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:316)
at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:55)
at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:122)
at liquibase.database.AbstractJdbcDatabase.execute(AbstractJdbcDatabase.java:1247)
at liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1230)
at liquibase.changelog.ChangeSet.execute(ChangeSet.java:548)
at liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:51)
at liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73)
at liquibase.Liquibase.update(Liquibase.java:210)
at liquibase.Liquibase.update(Liquibase.java:190)
at liquibase.Liquibase.update(Liquibase.java:186)
at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:153)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)
at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
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:103)
at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)
at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)
at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)
at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:139)
at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:82)
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:408)
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: org.postgresql.util.PSQLException: ERROR: column "direct_grants_only" does not exist
  Position: 59
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2198)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1927)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:561)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:405)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:397)
at org.jboss.jca.adapters.jdbc.WrappedStatement.execute(WrappedStatement.java:198)
at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:314)
... 47 more

_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/b1f49968/attachment.html 

From akaya at expedia.com  Wed Feb 17 09:41:35 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Wed, 17 Feb 2016 14:41:35 +0000
Subject: [keycloak-user] Impersonating User via API
In-Reply-To: <56C46846.4050204@gmx.net>
References: <56C46846.4050204@gmx.net>
Message-ID: <D2EAC351.2954%akaya@expedia.com>

Hi Alexander, please follow my Disabling status cookie thread
http://lists.jboss.org/pipermail/keycloak-user/2016-February/004937.html

On 2/17/16, 10:32 PM, "keycloak-user-bounces at lists.jboss.org on behalf of
Alexander Schwartz" <keycloak-user-bounces at lists.jboss.org on behalf of
alexander.schwartz at gmx.net> wrote:

>Hello Keycloak Community,
>
>I want to use impersonate a user via API.
>
>The start point is a logged in user with an access token.
>
>The goal is to have an access and refresh token of an impersonated user.
>
>In a proof-of-concept I've used the impersonation admin API, but this
>returns only cookies and redirects. When I follow the redirects I will
>eventually retrieve access and refresh token.
>
>I wonder if there is a better suited API to obtain them directly.
>
>Thank you very much,
>Alexander
>
>-- 
>Alexander Schwartz (alexander.schwartz at gmx.net)
>http://www.ahus1.de
>
>_______________________________________________
>keycloak-user mailing list
>keycloak-user at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/keycloak-user



From aikeaguinea at xsmail.com  Wed Feb 17 10:06:55 2016
From: aikeaguinea at xsmail.com (Aikeaguinea)
Date: Wed, 17 Feb 2016 10:06:55 -0500
Subject: [keycloak-user] Using Keycloak in AWS EC2. What are people
 using? / Infinispan not working on HA environment withdockers.
Message-ID: <1455721615.3814632.523858978.39C03FDB@webmail.messagingengine.com>

I just got JGroups/Infinispan with JDBC_PING working from inside a
Docker cluster in ECS on EC2. I use JDBC_PING rather than S3_PING, since
I need a database anyway and didn't want to have to set up an S3 bucket
just for this one purpose. Nicol?s, if you're on AWS the default UDP
transport for JGroups doesn't work because multicast isn't supported
inside EC2, which may be your problem.

Here are the configurations you'd need:

1. The JGroups module has to reference to the db module. So in jgroups-
   module.xml I have:

<dependencies>??????? <module name="javax.api"/>?????? <module
name="org.postgresql.jdbc"/>??? </dependencies>

2.The standalone-ha.xml has a JGroups subsystem (with TCP and JDBC_PING)
  that looks like the configuration below; I read certain variables from
  the environment, but may use the Wildfly vault tool for some of them.
  The external_addr property configurations are only needed if you're
  inside a Docker container, since Wildfly has to read the address of
  the EC2 instance hosting the container to register itself with
  JGroups. For the initialize_sql you can generally use the default, but
  for Postgres I needed a custom DDL because I needed the BYTEA data
  type which isn't in the default DDL.

<subsystem xmlns="urn:jboss:domain:jgroups:4.0">??????????? <channels
default="ee">??????????????? <channel name="ee" stack="tcp"/>
</channels>

<stacks default="tcp">??????????????? <stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp">
<property name="external_addr">${env.EXTERNAL_HOST_IP}</property>
</transport>

<protocol type="JDBC_PING">??????????????????????? <property
name="connection_driver">org.postgresql.Driver</property>
<property name="connection_url">jdbc:postgresql://${env.POSTGRES_TCP_AD-
DR}:${env.POSTGRES_TCP_PORT}/${env.POSTGRES_DATABASE}</property>
<property name="connection_username">${env.POSTGRES_USER}</property>
<property name="connection_password">${env.POSTGRES_PASSWORD}</property>
<property name="initialize_sql">??????????????????????????? CREATE TABLE
IF NOT EXISTS jgroupsping (??????????????????????????????? own_addr
VARCHAR(200) NOT NULL,??????????????????????????????? cluster_name
VARCHAR(200) NOT NULL,??????????????????????????????? ping_data BYTEA
DEFAULT NULL,??????????????????????????????? PRIMARY KEY (own_addr,
cluster_name)??????????????????????????? )
</property>??????????????????? </protocol>

<protocol type="MERGE3"/>??????????????????? <protocol type="FD_SOCK"
socket-binding="jgroups-tcp-fd">??????????????????????? <property
name="external_addr">${env.EXTERNAL_HOST_IP}</property>
</protocol>

<protocol type="FD"/>??????????????????? <protocol
type="VERIFY_SUSPECT"/>??????????????????? <protocol
type="pbcast.NAKACK2"/>??????????????????? <protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>??????????????????? <protocol
type="pbcast.GMS"/>??????????????????? <protocol type="MFC"/>
<protocol type="FRAG2"/>??????????????? </stack>??????????? </stacks>
</subsystem>

3. If you're in a Docker container, you have to expose the JGroups ports
   so they are visible from outside the container, so in standalone-
   ha.xml in the socket bindings I have changed to the public interface:

<socket-binding name="jgroups-tcp" interface="public" port="7600"/>
<socket-binding name="jgroups-tcp-fd" interface="public" port="57600"/>

4. For Docker, the startup script needs to pass the EXTERNAL_HOST_IP
   variable.? I have a wrapper start script that first queries the AWS
   instance metadata service for the host's private IP address:

export EXTERNAL_HOST_IP=$(curl -s 169.254.169.254/latest/meta-data/local-
ipv4)? exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-
ha.xml -Djboss.node.name=$HOSTNAME -Djgroups.bind_addr=global -b
$HOSTNAME

------------------------------------------------------------------------
--------------------------------------------------------------------
From: <keycloak-user-bounces at lists.jboss.org> Date: Wednesday, February
17, 2016 at 9:03 AM To: "keycloak-user at lists.jboss.org" <keycloak-
user at lists.jboss.org> Subject: [keycloak-user] Infinispan not working on
HA environment with  dockers.

Hello all, I'm trying to set a Keycloak HA environment up with dockers.
I tried with jboss/keycloak-ha-postgres:1.8.0.Final image.

I can't make infinispan work when I run 2 instances of my docker images.
I get the following log in every node:

Received new cluster view for channel ejb: [f9032dc82244|0] (1)
[f9032dc82244] Received new cluster view for channel hibernate:
[f9032dc82244|0] (1) [f9032dc82244] Received new cluster view for
channel keycloak: [f9032dc82244|0] (1) [f9032dc82244] Received new
cluster view for channel web: [f9032dc82244|0] (1) [f9032dc82244]
Channel hibernate local address is f9032dc82244, physical addresses are
[127.0.0.1:55200] Channel keycloak local address is f9032dc82244,
physical addresses are [127.0.0.1:55200] Channel ejb local address is
f9032dc82244, physical addresses are [127.0.0.1:55200] Channel web local
address is f9032dc82244, physical addresses are [127.0.0.1:55200]
Received new cluster view for channel server: [f9032dc82244|0] (1)
[f9032dc82244] Channel server local address is f9032dc82244, physical
addresses are [127.0.0.1:55200]

This is causing my user sessions are not shared between instances and
it's not working properly.

When I run 2 instances of keycloak without dockers, they work properly.

Am I missing something? Is there any extra configuration that I need
to change?

Thanks, Nicolas.-

-- 
http://www.fastmail.com - A fast, anti-spam email service.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/16e07b30/attachment-0001.html 

From aikeaguinea at xsmail.com  Wed Feb 17 11:01:03 2016
From: aikeaguinea at xsmail.com (Aikeaguinea)
Date: Wed, 17 Feb 2016 11:01:03 -0500
Subject: [keycloak-user] Using Keycloak in AWS EC2. What are people
 using? / Infinispan not working on HA environment withdockers.
In-Reply-To: <1455721615.3814632.523858978.39C03FDB@webmail.messagingengine.com>
References: <1455721615.3814632.523858978.39C03FDB@webmail.messagingengine.com>
Message-ID: <1455724863.3827648.523920298.7554D67E@webmail.messagingengine.com>

Apologies to those reading my message in plaintext; apparently all the
spaces come out as question marks. I've updated the message to use
plaintext below.

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

I just got JGroups/Infinispan with JDBC_PING working from inside a
Docker cluster in ECS on EC2. I use JDBC_PING rather than S3_PING, since
I need a database anyway and didn't want to have to set up an S3 bucket
just for this one purpose. Nicol?s, if you're on AWS the default UDP
transport for JGroups doesn't work because multicast isn't supported
inside EC2, which may be your problem.

Here are the configurations you'd need:

1. The JGroups module has to reference to the db module. So in
jgroups-module.xml I have:

  <dependencies>
    <module name="javax.api"/>
    <module name="org.postgresql.jdbc"/>
  </dependencies>

2. The standalone-ha.xml has a JGroups subsystem (with TCP and
JDBC_PING) that looks like the configuration below; I read certain
variables from the environment, but may use the Wildfly vault tool for
some of them. The external_addr property configurations are only needed
if you're inside a Docker container, since Wildfly has to read the
address of the EC2 instance hosting the container to register itself
with JGroups. For the initialize_sql you can generally use the default,
but for Postgres I needed a custom DDL because I needed the BYTEA data
type which isn't in the default DDL.

<subsystem xmlns="urn:jboss:domain:jgroups:4.0">
      <channels default="ee">
        <channel name="ee" stack="tcp"/>
      </channels>

      <stacks default="tcp">
        <stack name="tcp">
          <transport type="TCP" socket-binding="jgroups-tcp">
            <property
            name="external_addr">${env.EXTERNAL_HOST_IP}</property>
          </transport>

          <protocol type="JDBC_PING">
            <property
            name="connection_driver">org.postgresql.Driver</property>
            <property
            name="connection_url">jdbc:postgresql://${env.POSTGRES_TCP_ADDR}:${env.POSTGRES_TCP_PORT}/${env.POSTGRES_DATABASE}</property>
            <property
            name="connection_username">${env.POSTGRES_USER}</property>
            <property
            name="connection_password">${env.POSTGRES_PASSWORD}</property>
            <property name="initialize_sql">
              CREATE TABLE IF NOT EXISTS jgroupsping (
                own_addr VARCHAR(200) NOT NULL,
                cluster_name VARCHAR(200) NOT NULL,
                ping_data BYTEA DEFAULT NULL,
                PRIMARY KEY (own_addr, cluster_name)
              )
            </property>
          </protocol>

          <protocol type="MERGE3"/>
          <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd">
            <property
            name="external_addr">${env.EXTERNAL_HOST_IP}</property>
          </protocol>

          <protocol type="FD"/>
          <protocol type="VERIFY_SUSPECT"/>
          <protocol type="pbcast.NAKACK2"/>
          <protocol type="UNICAST3"/>
          <protocol type="pbcast.STABLE"/>
          <protocol type="pbcast.GMS"/>
          <protocol type="MFC"/>
          <protocol type="FRAG2"/>
        </stack>
      </stacks>
    </subsystem>

3. If you're in a Docker container, you have to expose the JGroups ports
so they are visible from outside the container, so in standalone-ha.xml
in the socket bindings I have changed to the public interface:

      <socket-binding name="jgroups-tcp" interface="public"
      port="7600"/>
      <socket-binding name="jgroups-tcp-fd" interface="public"
      port="57600"/>

4. For Docker, the startup script needs to pass the EXTERNAL_HOST_IP
variable. I have a wrapper start script that first queries the AWS
instance metadata service for the host's private IP address:

 export EXTERNAL_HOST_IP=$(curl -s
 169.254.169.254/latest/meta-data/local-ipv4)
 exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-ha.xml
 -Djboss.node.name=$HOSTNAME -Djgroups.bind_addr=global -b $HOSTNAME

> --------------------------------------------------------------------------------------------------------------------------------------------
> From: <keycloak-user-bounces at lists.jboss.org> 
> Date: Wednesday, February 17, 2016 at 9:03 AM
> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: [keycloak-user] Infinispan not working on HA environment with	dockers.
> 
> Hello all,
> I'm trying to set a Keycloak HA environment up with dockers. I tried with jboss/keycloak-ha-postgres:1.8.0.Final image.
> 
> I can't make infinispan work when I run 2 instances of my docker images. I get the following log in every node:
> 
> Received new cluster view for channel ejb: [f9032dc82244|0] (1) [f9032dc82244]
> Received new cluster view for channel hibernate: [f9032dc82244|0] (1) [f9032dc82244]
> Received new cluster view for channel keycloak: [f9032dc82244|0] (1) [f9032dc82244]
> Received new cluster view for channel web: [f9032dc82244|0] (1) [f9032dc82244]
> Channel hibernate local address is f9032dc82244, physical addresses are [127.0.0.1:55200]
> Channel keycloak local address is f9032dc82244, physical addresses are [127.0.0.1:55200]
> Channel ejb local address is f9032dc82244, physical addresses are [127.0.0.1:55200]
> Channel web local address is f9032dc82244, physical addresses are [127.0.0.1:55200]
> Received new cluster view for channel server: [f9032dc82244|0] (1) [f9032dc82244]
> Channel server local address is f9032dc82244, physical addresses are [127.0.0.1:55200]
> 
> This is causing my user sessions are not shared between instances and it's not working properly.
> 
> When I run 2 instances of keycloak without dockers, they work properly.
> 
> Am I missing something? Is there any extra configuration that I need to change?
> 
> Thanks,
> Nicolas.-
> -- 
http://www.fastmail.com - A fast, anti-spam email service.

--
? Aikeaguinea
? aikeaguinea at xsmail.com


-- 
http://www.fastmail.com - Access your email from home and the web



From sthorger at redhat.com  Wed Feb 17 11:04:08 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 17 Feb 2016 17:04:08 +0100
Subject: [keycloak-user] Disabling status cookie
In-Reply-To: <D2EAC278.294D%akaya@expedia.com>
References: <D2E905E8.28CE%akaya@expedia.com> <56C31853.1080904@redhat.com>
	<D2EA47AB.291D%akaya@expedia.com>
	<CAM5SUC56TMCTA=A7-JGZViWNVbg2LcpZiTyjbct6KR=3LNErhQ@mail.gmail.com>
	<D2EAC278.294D%akaya@expedia.com>
Message-ID: <CAJgngAfmOPz6MZ8DJLcZ+EZTFQJmvMcemTrLq6Wn4r_SkL=3ng@mail.gmail.com>

You can't get the token using direct grant if totp is enabled. We will have
to add this at some point. Feel free to create a JIRA for it.

On 17 February 2016 at 15:39, Sarp Kaya <akaya at expedia.com> wrote:

> My issue is not "Account is not fully set up? error, I can ?afford? to set
> it up through the web ui. The problem is after setting it up the curl that
> I give does not grant me a token and gives ?Invalid user credentials?
> error, despite the fact that username and password are correct.
> So my question is whether it is possible to get the token using "
> /auth/realms/{realms}/protocol/openid-connect/token
> <http://localhost:8080/auth/realms/demo/protocol/openid-connect/token>?
> or similar API when the account itself has TOTP enabled (and configured)?
>
> From: Bruno Oliveira <bruno at abstractj.org>
> Date: Wednesday, February 17, 2016 at 8:01 PM
> To: Abdullah Sarp Kaya <akaya at expedia.com>, Bill Burke <bburke at redhat.com>,
> "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>
> Subject: Re: [keycloak-user] Disabling status cookie
>
> I believe that Stian recently replied here
> http://lists.jboss.org/pipermail/keycloak-user/2016-January/004484.html
>
>
> On Wed, Feb 17, 2016 at 3:55 AM Sarp Kaya <akaya at expedia.com> wrote:
>
>> Thanks for the suggestion. It works just as expected. I was also
>> wondering how would direct grant API use TOTP? I tried using it, before
>> configuring I received {"error_description":"Account is not fully set
>> up","error":"invalid_grant"} however after setting the account I kept
>> getting {"error_description":"Invalid user
>> credentials","error":"invalid_grant"} this is how I requested:
>>
>> curl -X POST '
>> http://localhost:8080/auth/realms/demo/protocol/openid-connect/token'
>> --data
>> 'username=sarp&password=pass1234&grant_type=password&client_id=admin-cli' -v
>> Have I done something incorrect when requesting for a token?
>>
>> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Bill Burke <
>> bburke at redhat.com>
>> Date: Tuesday, February 16, 2016 at 10:38 PM
>> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>> Subject: Re: [keycloak-user] Disabling status cookie
>>
>> See our direct grant API.    Here's an example:
>>
>>
>> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java
>>
>> I *STRONGLY* suggest you do not use the direct grant API for
>> browser-based applications.  Otherwise you lose 90% of the features of
>> Keycloak.  Use the direct grant API for REST clients, that's what it was
>> designed for.
>>
>> On 2/16/2016 1:59 AM, Sarp Kaya wrote:
>>
>> Hello,
>>
>> I want my users to be able to login via API calls with our without
>> requiring a browser. I looked at examples and found customer-app-cli,
>> however I realised that even with manual login, the current workflow
>> requires a browser to login. I found that every time when
>>
>> http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
>>
>> this page loads we get a form with a different code. In theory we should
>> be able to just stick username and password in the body and be able to get
>> 302 response. However when I get the curl equivalent of what browser is
>> doing I?ve gotten the below:
>>
>> curl '
>> http://localhost:8080/auth/realms/demo/login-actions/authenticate?code=oY8nS7rFOlwYHNJwWS6kcw88jbxluo8EuDmZ_o5TWsw.431db3e8-6234-4ba5-8818-ed0335b8ee72&execution=08d88824-1286-4455-b5d1-07240bda8efd'
>> -H 'Cookie:
>> KEYCLOAK_STATE_CHECKER=a2teB_8_wfAfD9VtmV0DJhqDEuM9187r58mVW24Gfrg;
>> KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjQzMWRiM2U4LTYyMzQtNGJhNS04ODE4LWVkMDMzNWI4ZWU3MiIsImNpZCI6ImN1c3RvbWVyLXBvcnRhbC1jbGkiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZGVtby9wcm90b2NvbC9vcGVuaWQtY29ubmVjdC9vYXV0aC9vb2IiLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYTA1MzFlNTYtZjk0Zi00NmM4LWFlNGUtNjQ4MDUyNDc2ZjEwIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9hdXRoL3JlYWxtcy9kZW1vIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJyZWRpcmVjdF91cmkiOiJ1cm46aWV0Zjp3ZzpvYXV0aDoyLjA6b29iIn19.B5vuMj-fafRAS0gJ6m-OrU5cX0atABuWy252y5k7jr0'
>> -H 'Origin: http://localhost:8080' -H 'Accept-Encoding: gzip, deflate'
>> -H 'Accept-Language: en-US,en;q=0.8' -H 'Upgrade-Insecure-Requests: 1' -H
>> 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36'
>> -H 'Content-Type: application/x-www-form-urlencoded' -H 'Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
>> -H 'Cache-Control: max-age=0' -H 'Referer:
>> http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob'
>> -H 'Connection: keep-alive' --data
>> 'username=sarp&password=pass1234&login=Log+in' ?compressed
>>
>> I was hoping not to use the cookies and just change the code bit with a
>> new request to the page mentioned above and expect 302 response, however I
>> am getting 500 responses saying error occurred instead.
>>
>> I looked on admin management console, but could not really find a way to
>> disable cookies for the given client or the realm. I am guessing that one
>> of those cookies are encrypting something that is required and not using it
>> simply prevents logging in successfully. So how can I disable this
>> requirement?
>>
>> Kind Regards,
>> Sarp Kaya
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://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/20160217/b57a019b/attachment-0001.html 

From aikeaguinea at xsmail.com  Wed Feb 17 11:09:25 2016
From: aikeaguinea at xsmail.com (Aikeaguinea)
Date: Wed, 17 Feb 2016 11:09:25 -0500
Subject: [keycloak-user] Securely setting admin passwords
Message-ID: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>

It seems the add-user.sh  script for changing the admin password only
accepts the password as a -p command-line parameter. This would expose
the password in the command history, so I'd prefer not to use the
command in its current form.

Is there another way to do this?

The situation is even more complicated with Docker, since running the
script to change the Wildfly admin password requires restarting the
server, which shuts down the container. If you have an autoscaling
group, the container that gets brought up is not the container where you
changed the password, but instead the original container. This seems to
mean that the only way to have Keycloak run in Dockers in an autoscaling
group is to bake the admin passwords into the Docker image beforehand.
This isn't ideal; less so if the only way to add those passwords during
build time is to run the shell script that exposes the password on the
command line.

-- 
http://www.fastmail.com - Access your email from home and the web


From alexander.schwartz at gmx.net  Wed Feb 17 14:08:51 2016
From: alexander.schwartz at gmx.net (Alexander Schwartz)
Date: Wed, 17 Feb 2016 20:08:51 +0100
Subject: [keycloak-user] Impersonating User via API
In-Reply-To: <D2EAC351.2954%akaya@expedia.com>
References: <56C46846.4050204@gmx.net> <D2EAC351.2954%akaya@expedia.com>
Message-ID: <56C4C543.8060008@gmx.net>

Hi Sarp,

I've seen this discussion, but it doesn't solve my problem as far as I 
can see: direct grant needs a username and a password to get the access 
token for that user.

For impersonation I don't have the password of the second user. 
Basically I want to use an access token of the first user and the 
username of the second user to receive an access token for the second user.

Regards,
Alexander

Am 17.02.2016 um 15:41 schrieb Sarp Kaya:
> Hi Alexander, please follow my Disabling status cookie thread
> http://lists.jboss.org/pipermail/keycloak-user/2016-February/004937.html
>
> On 2/17/16, 10:32 PM, "keycloak-user-bounces at lists.jboss.org on behalf of
> Alexander Schwartz" <keycloak-user-bounces at lists.jboss.org on behalf of
> alexander.schwartz at gmx.net> wrote:
>
>> Hello Keycloak Community,
>>
>> I want to use impersonate a user via API.
>>
>> The start point is a logged in user with an access token.
>>
>> The goal is to have an access and refresh token of an impersonated user.
>>
>> In a proof-of-concept I've used the impersonation admin API, but this
>> returns only cookies and redirects. When I follow the redirects I will
>> eventually retrieve access and refresh token.
>>
>> I wonder if there is a better suited API to obtain them directly.
>>
>> Thank you very much,
>> Alexander
>>
>> -- 
>> Alexander Schwartz (alexander.schwartz at gmx.net)
>> http://www.ahus1.de
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Alexander Schwartz (alexander.schwartz at gmx.net)
http://www.ahus1.de


From mposolda at redhat.com  Wed Feb 17 15:33:23 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 21:33:23 +0100
Subject: [keycloak-user] Frequent LDAP bind failed socket connection
 reset exceptions in Keycloak LDAP user federation
In-Reply-To: <5F0501E4-FEB6-4840-BC64-2FF0823A0B73@info.nl>
References: <5F0501E4-FEB6-4840-BC64-2FF0823A0B73@info.nl>
Message-ID: <56C4D913.2030904@redhat.com>

Maybe try to start Keycloak with -Dhttps.protocols=SSLv3 ?

Some more details:
http://stackoverflow.com/questions/5507878/ssl-connection-reset
http://stackoverflow.com/questions/17458500/why-am-i-receiving-a-java-net-socketexception-connection-reset-error-from-web-s

Marek

On 17/02/16 09:57, Edgar Vonk - Info.nl wrote:
> hi,
>
> We are getting frequent LDAP simple bind failed, socket exceptions, when communicating with our Active Directory server using the Keycloak user federation provider. The might very well be a problem on the AD side of things or perhaps in our network, but I was wondering if it might be something in Keycloak? We have not been able to narrow it down so far.
>
> It happens quite often for example when manually synching users from AD to Keycloak but also for example when creating a new user from Keycloak to AD. When you try any such action again it always succeeds. It seems some sort of hiccup.
>
> 09:08:23,080 ERROR [org.keycloak.services] LDAP Query failed
> org.keycloak.models.ModelException: LDAP Query failed
> 	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:168)
> 	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getFirstResult(LDAPQuery.java:175)
> 	at org.keycloak.federation.ldap.LDAPFederationProvider.loadLDAPUserByUsername(LDAPFederationProvider.java:504)
>
> [..]
>
> Caused by: org.keycloak.models.ModelException: Querying of LDAP failed org.keycloak.federation.ldap.idm.query.internal.LDAPQuery at 12228106
> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:169)
> 	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:164)
> 	... 54 more
> Caused by: javax.naming.CommunicationException: simple bind failed: ldap.hf.info.nl:636 [Root exception is java.net.SocketException: Connection reset]
> 	at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788)
> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> 	at javax.naming.InitialContext.init(InitialContext.java:244)
> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.createLdapContext(LDAPOperationManager.java:473)
> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:541)
> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.search(LDAPOperationManager.java:166)
> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:160)
> 	... 55 more
> Caused by: java.net.SocketException: Connection reset
> 	at java.net.SocketInputStream.read(SocketInputStream.java:209)
> 	at java.net.SocketInputStream.read(SocketInputStream.java:141)
> 	at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> 	at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> 	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> 	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> 	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> 	at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> 	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:426)
> 	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:399)
> 	at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
> 	at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
> 	... 69 more
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From nicopozo at gmail.com  Wed Feb 17 15:37:50 2016
From: nicopozo at gmail.com (=?UTF-8?Q?Nicol=C3=A1s_Pozo?=)
Date: Wed, 17 Feb 2016 17:37:50 -0300
Subject: [keycloak-user] Using Keycloak in AWS EC2. What are people
 using? / Infinispan not working on HA environment withdockers.
In-Reply-To: <1455724863.3827648.523920298.7554D67E@webmail.messagingengine.com>
References: <1455721615.3814632.523858978.39C03FDB@webmail.messagingengine.com>
	<1455724863.3827648.523920298.7554D67E@webmail.messagingengine.com>
Message-ID: <CAPLJng-zPdr9i_MYhKL2Honc-XFcpPAh-pkobRmOSdLVCSciiQ@mail.gmail.com>

Hi,
JDBC_PING did the Job and infinispan seems to be working now. But I have
another issue.

I have 2 keycloak instances running behind a load balancer. When I get a
token from server 1 and then load balancer sends requests to server 2 using
this token, I get an error 401 because token is not valid. Is there any
other missing configuration to sinchronize tokens?

Thanks,
Nicol?s.-

2016-02-17 13:01 GMT-03:00 Aikeaguinea <aikeaguinea at xsmail.com>:

> Apologies to those reading my message in plaintext; apparently all the
> spaces come out as question marks. I've updated the message to use
> plaintext below.
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> I just got JGroups/Infinispan with JDBC_PING working from inside a
> Docker cluster in ECS on EC2. I use JDBC_PING rather than S3_PING, since
> I need a database anyway and didn't want to have to set up an S3 bucket
> just for this one purpose. Nicol?s, if you're on AWS the default UDP
> transport for JGroups doesn't work because multicast isn't supported
> inside EC2, which may be your problem.
>
> Here are the configurations you'd need:
>
> 1. The JGroups module has to reference to the db module. So in
> jgroups-module.xml I have:
>
>   <dependencies>
>     <module name="javax.api"/>
>     <module name="org.postgresql.jdbc"/>
>   </dependencies>
>
> 2. The standalone-ha.xml has a JGroups subsystem (with TCP and
> JDBC_PING) that looks like the configuration below; I read certain
> variables from the environment, but may use the Wildfly vault tool for
> some of them. The external_addr property configurations are only needed
> if you're inside a Docker container, since Wildfly has to read the
> address of the EC2 instance hosting the container to register itself
> with JGroups. For the initialize_sql you can generally use the default,
> but for Postgres I needed a custom DDL because I needed the BYTEA data
> type which isn't in the default DDL.
>
> <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
>       <channels default="ee">
>         <channel name="ee" stack="tcp"/>
>       </channels>
>
>       <stacks default="tcp">
>         <stack name="tcp">
>           <transport type="TCP" socket-binding="jgroups-tcp">
>             <property
>             name="external_addr">${env.EXTERNAL_HOST_IP}</property>
>           </transport>
>
>           <protocol type="JDBC_PING">
>             <property
>             name="connection_driver">org.postgresql.Driver</property>
>             <property
>
> name="connection_url">jdbc:postgresql://${env.POSTGRES_TCP_ADDR}:${env.POSTGRES_TCP_PORT}/${env.POSTGRES_DATABASE}</property>
>             <property
>             name="connection_username">${env.POSTGRES_USER}</property>
>             <property
>             name="connection_password">${env.POSTGRES_PASSWORD}</property>
>             <property name="initialize_sql">
>               CREATE TABLE IF NOT EXISTS jgroupsping (
>                 own_addr VARCHAR(200) NOT NULL,
>                 cluster_name VARCHAR(200) NOT NULL,
>                 ping_data BYTEA DEFAULT NULL,
>                 PRIMARY KEY (own_addr, cluster_name)
>               )
>             </property>
>           </protocol>
>
>           <protocol type="MERGE3"/>
>           <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd">
>             <property
>             name="external_addr">${env.EXTERNAL_HOST_IP}</property>
>           </protocol>
>
>           <protocol type="FD"/>
>           <protocol type="VERIFY_SUSPECT"/>
>           <protocol type="pbcast.NAKACK2"/>
>           <protocol type="UNICAST3"/>
>           <protocol type="pbcast.STABLE"/>
>           <protocol type="pbcast.GMS"/>
>           <protocol type="MFC"/>
>           <protocol type="FRAG2"/>
>         </stack>
>       </stacks>
>     </subsystem>
>
> 3. If you're in a Docker container, you have to expose the JGroups ports
> so they are visible from outside the container, so in standalone-ha.xml
> in the socket bindings I have changed to the public interface:
>
>       <socket-binding name="jgroups-tcp" interface="public"
>       port="7600"/>
>       <socket-binding name="jgroups-tcp-fd" interface="public"
>       port="57600"/>
>
> 4. For Docker, the startup script needs to pass the EXTERNAL_HOST_IP
> variable. I have a wrapper start script that first queries the AWS
> instance metadata service for the host's private IP address:
>
>  export EXTERNAL_HOST_IP=$(curl -s
>  169.254.169.254/latest/meta-data/local-ipv4)
>  exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-ha.xml
>  -Djboss.node.name=$HOSTNAME -Djgroups.bind_addr=global -b $HOSTNAME
>
> >
> --------------------------------------------------------------------------------------------------------------------------------------------
> > From: <keycloak-user-bounces at lists.jboss.org>
> > Date: Wednesday, February 17, 2016 at 9:03 AM
> > To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> > Subject: [keycloak-user] Infinispan not working on HA environment with
>       dockers.
> >
> > Hello all,
> > I'm trying to set a Keycloak HA environment up with dockers. I tried
> with jboss/keycloak-ha-postgres:1.8.0.Final image.
> >
> > I can't make infinispan work when I run 2 instances of my docker images.
> I get the following log in every node:
> >
> > Received new cluster view for channel ejb: [f9032dc82244|0] (1)
> [f9032dc82244]
> > Received new cluster view for channel hibernate: [f9032dc82244|0] (1)
> [f9032dc82244]
> > Received new cluster view for channel keycloak: [f9032dc82244|0] (1)
> [f9032dc82244]
> > Received new cluster view for channel web: [f9032dc82244|0] (1)
> [f9032dc82244]
> > Channel hibernate local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> > Channel keycloak local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> > Channel ejb local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> > Channel web local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> > Received new cluster view for channel server: [f9032dc82244|0] (1)
> [f9032dc82244]
> > Channel server local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> >
> > This is causing my user sessions are not shared between instances and
> it's not working properly.
> >
> > When I run 2 instances of keycloak without dockers, they work properly.
> >
> > Am I missing something? Is there any extra configuration that I need to
> change?
> >
> > Thanks,
> > Nicolas.-
> > --
> http://www.fastmail.com - A fast, anti-spam email service.
>
> --
>   Aikeaguinea
>   aikeaguinea at xsmail.com
>
>
> --
> http://www.fastmail.com - Access your email from home and the web
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/377372e9/attachment-0001.html 

From mposolda at redhat.com  Wed Feb 17 15:45:24 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 21:45:24 +0100
Subject: [keycloak-user] LDAP username mapping from active directory
	fails
In-Reply-To: <CAHa5F_u1Nfxs8eXVq=7_xS7cowjV8=Gy1MshjkmKFzTjk6XWsw@mail.gmail.com>
References: <CAHa5F_u1Nfxs8eXVq=7_xS7cowjV8=Gy1MshjkmKFzTjk6XWsw@mail.gmail.com>
Message-ID: <56C4DBE4.9010309@redhat.com>

I guess you changed just "Username LDAP attribute" but you didn't change 
the username mapper? See "mappers" tab under ldap federation provider.

When you create new LDAP federation provider, there are some set of 
default LDAP mappers automatically created. There is best effort to 
create set of mappers based on the initial configuration you provided. 
But once you later update the configuration, the mappers are not updated 
anymore (because it's chance you already did some changes to mapper 
configuration in the meantime).

If you can't figure mapper configuration, you can try to create 
federationProvider from the scratch with the "sAMAccountName" from the 
start.

Hope it helps,
Marek

On 17/02/16 12:37, Porfyrios Vasileiou wrote:
> Hello, i created a new ldap federation in the keycloak settings and 
> imported all users. The thing is that the username attribute was 
> mapped to the ldap cn attribute whereas the username in active 
> directory is sAMAccountName. Therefore i changed the ldapAttribute to 
> that.
>
> Now when i go to my ldap settings page and click on "Synchronize" the 
> users fail to update and i am getting this error:
>
> 13:31:53,899 ERROR 
> [org.keycloak.federation.ldap.LDAPFederationProviderFactory] (default 
> task-25) Failed during import user from LDAP: org.keycloak.mo 
> <http://org.keycloak.mo>
> dels.ModelException: User returned from LDAP has null username! Check 
> configuration of your LDAP mappings. Mapped username LDAP attribute: 
> cn, user DN
> : CN=internal2 lastname,OU=DTPH,DC=dls,DC=lan, attributes from LDAP: 
> {whenChanged=[20160217110433.0Z], whenCreated=[20160217110433.0Z], 
> sAMAccountName
> =[internal2], givenName=[internal2], sn=[lastname], 
> userAccountControl=[512], pwdLastSet=[131001806735067575]}
>
> If u put it back to cn it works, but i want to use sAMAccountName for 
> the username.
>
> Why does this happen ?
>
>
> _______________________________________________
> 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/20160217/f5bbc590/attachment.html 

From mposolda at redhat.com  Wed Feb 17 15:52:57 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 21:52:57 +0100
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
Message-ID: <56C4DDA9.2090401@redhat.com>

You can create the file in some "safe" environment (your laptop) and 
then share the file with docker via volume and copy to the 
standalone/configuration of the server? The created JSON file doesn't 
contain password in plain text, but it's encoded.

Also the "add-user.sh" script doesn't need server to be running.

Finally, uf you don't need automated way, you can set it manually after 
first startup when going to http://localhost:8080/auth

Marek


On 17/02/16 17:09, Aikeaguinea wrote:
> It seems the add-user.sh  script for changing the admin password only
> accepts the password as a -p command-line parameter. This would expose
> the password in the command history, so I'd prefer not to use the
> command in its current form.
>
> Is there another way to do this?
>
> The situation is even more complicated with Docker, since running the
> script to change the Wildfly admin password requires restarting the
> server, which shuts down the container. If you have an autoscaling
> group, the container that gets brought up is not the container where you
> changed the password, but instead the original container. This seems to
> mean that the only way to have Keycloak run in Dockers in an autoscaling
> group is to bake the admin passwords into the Docker image beforehand.
> This isn't ideal; less so if the only way to add those passwords during
> build time is to run the shell script that exposes the password on the
> command line.
>


From mposolda at redhat.com  Wed Feb 17 16:00:14 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 22:00:14 +0100
Subject: [keycloak-user] Disabling status cookie
In-Reply-To: <CAJgngAfmOPz6MZ8DJLcZ+EZTFQJmvMcemTrLq6Wn4r_SkL=3ng@mail.gmail.com>
References: <D2E905E8.28CE%akaya@expedia.com> <56C31853.1080904@redhat.com>
	<D2EA47AB.291D%akaya@expedia.com>
	<CAM5SUC56TMCTA=A7-JGZViWNVbg2LcpZiTyjbct6KR=3LNErhQ@mail.gmail.com>
	<D2EAC278.294D%akaya@expedia.com>
	<CAJgngAfmOPz6MZ8DJLcZ+EZTFQJmvMcemTrLq6Wn4r_SkL=3ng@mail.gmail.com>
Message-ID: <56C4DF5E.6030406@redhat.com>

Looks we already support it? When you go in admin console to 
"Authentication" and then choose flow "Direct grant", you can see that 
OTP authenticator is there and it's optional by default (not sure if you 
accidentally change it to REQUIRED based on your errors).

The possibilities are:
- Add parameter "totp" to the direct grant request together with 
username and password (For example 
username=sarp&password=pass1234&totp=123456&grant_type=password&client_id=admin-cli 
)
- Disable OTP Authenticator for the direct grants flow (just if you 
don't have a way to ask user for TOTP in your app).

Marek

On 17/02/16 17:04, Stian Thorgersen wrote:
> You can't get the token using direct grant if totp is enabled. We will 
> have to add this at some point. Feel free to create a JIRA for it.
>
> On 17 February 2016 at 15:39, Sarp Kaya <akaya at expedia.com 
> <mailto:akaya at expedia.com>> wrote:
>
>     My issue is not "Account is not fully set up? error, I can
>     ?afford? to set it up through the web ui. The problem is after
>     setting it up the curl that I give does not grant me a token and
>     gives ?Invalid user credentials? error, despite the fact that
>     username and password are correct.
>     So my question is whether it is possible to get the token using
>     "/auth/realms/{realms}/protocol/openid-connect/token
>     <http://localhost:8080/auth/realms/demo/protocol/openid-connect/token>?
>     or similar API when the account itself has TOTP enabled (and
>     configured)?
>
>     From: Bruno Oliveira <bruno at abstractj.org
>     <mailto:bruno at abstractj.org>>
>     Date: Wednesday, February 17, 2016 at 8:01 PM
>     To: Abdullah Sarp Kaya <akaya at expedia.com
>     <mailto:akaya at expedia.com>>, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>>, "keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>"
>     <keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>>
>
>     Subject: Re: [keycloak-user] Disabling status cookie
>
>     I believe that Stian recently replied here
>     http://lists.jboss.org/pipermail/keycloak-user/2016-January/004484.html
>
>
>     On Wed, Feb 17, 2016 at 3:55 AM Sarp Kaya <akaya at expedia.com
>     <mailto:akaya at expedia.com>> wrote:
>
>         Thanks for the suggestion. It works just as expected. I was
>         also wondering how would direct grant API use TOTP? I tried
>         using it, before configuring I received
>         {"error_description":"Account is not fully set
>         up","error":"invalid_grant"} however after setting the
>         account I kept getting {"error_description":"Invalid user
>         credentials","error":"invalid_grant"} this is how I requested:
>
>         curl -X POST
>         'http://localhost:8080/auth/realms/demo/protocol/openid-connect/token'
>         --data
>         'username=sarp&password=pass1234&grant_type=password&client_id=admin-cli'
>         -v
>
>         Have I done something incorrect when requesting for a token?
>
>         From: <keycloak-user-bounces at lists.jboss.org
>         <mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of
>         Bill Burke <bburke at redhat.com <mailto:bburke at redhat.com>>
>         Date: Tuesday, February 16, 2016 at 10:38 PM
>         To: "keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>"
>         <keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>>
>         Subject: Re: [keycloak-user] Disabling status cookie
>
>         See our direct grant API.    Here's an example:
>
>         https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java
>
>         I *STRONGLY* suggest you do not use the direct grant API for
>         browser-based applications. Otherwise you lose 90% of the
>         features of Keycloak.  Use the direct grant API for REST
>         clients, that's what it was designed for.
>
>         On 2/16/2016 1:59 AM, Sarp Kaya wrote:
>>         Hello,
>>
>>         I want my users to be able to login via API calls with our
>>         without requiring a browser. I looked at examples and found
>>         customer-app-cli, however I realised that even with manual
>>         login, the current workflow requires a browser to login. I
>>         found that every time when
>>         http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
>>
>>         this page loads we get a form with a different code. In
>>         theory we should be able to just stick username and password
>>         in the body and be able to get 302 response. However when I
>>         get the curl equivalent of what browser is doing I?ve gotten
>>         the below:
>>
>>         curl
>>         'http://localhost:8080/auth/realms/demo/login-actions/authenticate?code=oY8nS7rFOlwYHNJwWS6kcw88jbxluo8EuDmZ_o5TWsw.431db3e8-6234-4ba5-8818-ed0335b8ee72&execution=08d88824-1286-4455-b5d1-07240bda8efd'
>>         -H 'Cookie:
>>         KEYCLOAK_STATE_CHECKER=a2teB_8_wfAfD9VtmV0DJhqDEuM9187r58mVW24Gfrg;
>>         KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjQzMWRiM2U4LTYyMzQtNGJhNS04ODE4LWVkMDMzNWI4ZWU3MiIsImNpZCI6ImN1c3RvbWVyLXBvcnRhbC1jbGkiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZGVtby9wcm90b2NvbC9vcGVuaWQtY29ubmVjdC9vYXV0aC9vb2IiLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYTA1MzFlNTYtZjk0Zi00NmM4LWFlNGUtNjQ4MDUyNDc2ZjEwIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9hdXRoL3JlYWxtcy9kZW1vIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJyZWRpcmVjdF91cmkiOiJ1cm46aWV0Zjp3ZzpvYXV0aDoyLjA6b29iIn19.B5vuMj-fafRAS0gJ6m-OrU5cX0atABuWy252y5k7jr0'
>>         -H 'Origin: http://localhost:8080' -H 'Accept-Encoding: gzip,
>>         deflate' -H 'Accept-Language: en-US,en;q=0.8' -H
>>         'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0
>>         (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36
>>         (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36' -H
>>         'Content-Type: application/x-www-form-urlencoded' -H 'Accept:
>>         text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
>>         -H 'Cache-Control: max-age=0' -H 'Referer:
>>         http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob'
>>         -H 'Connection: keep-alive' --data
>>         'username=sarp&password=pass1234&login=Log+in' ?compressed
>>
>>         I was hoping not to use the cookies and just change the code
>>         bit with a new request to the page mentioned above and expect
>>         302 response, however I am getting 500 responses saying error
>>         occurred instead.
>>
>>         I looked on admin management console, but could not really
>>         find a way to disable cookies for the given client or the
>>         realm. I am guessing that one of those cookies are encrypting
>>         something that is required and not using it simply prevents
>>         logging in successfully. So how can I disable this requirement?
>>
>>         Kind Regards,
>>         Sarp Kaya
>>
>>
>>         _______________________________________________
>>         keycloak-user mailing list
>>         keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>         -- 
>         Bill Burke
>         JBoss, a division of Red Hat
>         http://bill.burkecentral.com
>
>         _______________________________________________
>         keycloak-user mailing list
>         keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/8b1493fa/attachment-0001.html 

From jaxley at expedia.com  Wed Feb 17 16:46:13 2016
From: jaxley at expedia.com (Jason Axley)
Date: Wed, 17 Feb 2016 21:46:13 +0000
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
Message-ID: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>

I followed some documentation like https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for configuring JBOSS to use LDAP over SSL to Active Directory but can?t seem to get Keycloak to honor the trust settings in the configured keystore.


2016-02-17 21:33:49,670 ERROR [org.keycloak.services.managers.LDAPConnectionTestManager] (default task-2) Error when authenticating to LDAP: simple bind failed: server.example.com:636: javax.naming.CommunicationException: simple bind failed: server.example.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

        at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)

This is the configuration I?m using for the standalone server:


           <security-realm name="LdapSSLRealm">

               <authentication>

                <truststore path="keycloak.jks" relative-to="jboss.server.config.dir" keystore-password=?password" />

               </authentication>

            </security-realm>

        </security-realms>

        <outbound-connections>

            <ldap name=?AD" url="ldaps://server.example.com:636" security-realm="LdapSSLRealm" />

        </outbound-connections>

I have all of the certs in the chain imported into the keystore:


keytool -list -keystore ../configuration/keycloak.jks

Enter keystore password:


Keystore type: JKS

Keystore provider: SUN


Your keystore contains 5 entries


cert1, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE

rootcert2, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A

mykey, Feb 12, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15

rootcert, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD

intermediateu, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D

Is there a way to find out if Keycloak/jboss is picking up this truststore config?  Seems that it?s not.  Any other ideas?

-Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/c37df95b/attachment.html 

From aikeaguinea at xsmail.com  Wed Feb 17 16:52:18 2016
From: aikeaguinea at xsmail.com (Aikeaguinea)
Date: Wed, 17 Feb 2016 16:52:18 -0500
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <mailman.7140.1455742830.3326.keycloak-user@lists.jboss.org>
References: <mailman.7140.1455742830.3326.keycloak-user@lists.jboss.org>
Message-ID: <1455745938.2099269.524233458.0C9F8B04@webmail.messagingengine.com>

Running in Amazon's Elastic Container Service with an autoscaling group,
which can bring up new EC2 instances to host the Dockers at any time
without manual intervention, makes it challenging to share the file via
volume or use the http URL.

So far I've had the Wildfly startup wrapped in a script that calls
add-user.sh before the server starts; we were thinking of using
something like CredStash (https://github.com/fugue/credstash) as the
source for the credentials. Then start-keycloak.sh would look something
like this:

     # Container needs to know its host, for JGroups
     export EXTERNAL_HOST_IP=$(curl -s
     169.254.169.254/latest/meta-data/local-ipv4)

     $WILDFLY_HOME/bin/add-user.sh --container -u admin -p $(credstash
     get $KEYCLOAK_WILDFLY_ADMIN_PWD_KEY)
     $WILDFLY_HOME/bin/add-user.sh -u admin -p $(credstash get
     $KEYCLOAK_ADMIN_PWD_KEY)

     # Allow graceful shutdown from `docker stop`, which issues SIGTERM.
     trap "$WILDFLY_HOME/bin/stop-keycloak.sh" SIGTERM
     exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-ha.xml
     -Djboss.node.name=$HOSTNAME -Djgroups.bind_addr=global -b $HOSTNAME

Still, the password is being passed in the clear on the command line,
and is visible via a process listing. Since the command is being run
inside Docker, this would ultimately expose the password in cleartext to
a docker history command. 

It looks like I'm going to have to figure out how to mount the files
from a volume. Are the relevant files
standalone/configuration/keycloak-add-user.json and
standalone/configuration/mgmt-users.properties ?

 Date: Wed, 17 Feb 2016 21:52:57 +0100
> From: Marek Posolda <mposolda at redhat.com>
> Subject: Re: [keycloak-user] Securely setting admin passwords
> To: Aikeaguinea <aikeaguinea at xsmail.com>,
> 	keycloak-user at lists.jboss.org
> Message-ID: <56C4DDA9.2090401 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
> You can create the file in some "safe" environment (your laptop) and 
> then share the file with docker via volume and copy to the 
> standalone/configuration of the server? The created JSON file doesn't 
> contain password in plain text, but it's encoded.
> 
> Also the "add-user.sh" script doesn't need server to be running.
> 
> Finally, uf you don't need automated way, you can set it manually after 
> first startup when going to http://localhost:8080/auth
> 
> Marek
> 
> 
> On 17/02/16 17:09, Aikeaguinea wrote:
> > It seems the add-user.sh  script for changing the admin password only
> > accepts the password as a -p command-line parameter. This would expose
> > the password in the command history, so I'd prefer not to use the
> > command in its current form.
> >
> > Is there another way to do this?
> >
> > The situation is even more complicated with Docker, since running the
> > script to change the Wildfly admin password requires restarting the
> > server, which shuts down the container. If you have an autoscaling
> > group, the container that gets brought up is not the container where you
> > changed the password, but instead the original container. This seems to
> > mean that the only way to have Keycloak run in Dockers in an autoscaling
> > group is to bake the admin passwords into the Docker image beforehand.
> > This isn't ideal; less so if the only way to add those passwords during
> > build time is to run the shell script that exposes the password on the
> > command line.

-- 
http://www.fastmail.com - mmm... Fastmail...


From aikeaguinea at xsmail.com  Wed Feb 17 16:53:52 2016
From: aikeaguinea at xsmail.com (Aikeaguinea)
Date: Wed, 17 Feb 2016 16:53:52 -0500
Subject: [keycloak-user] Using Keycloak in AWS EC2. What are people
 using? / Infinispan not working on HA environment withdockers.
In-Reply-To: <CAPLJng-zPdr9i_MYhKL2Honc-XFcpPAh-pkobRmOSdLVCSciiQ@mail.gmail.com>
References: <1455721615.3814632.523858978.39C03FDB@webmail.messagingengine.com>
	<1455724863.3827648.523920298.7554D67E@webmail.messagingengine.com>
	<CAPLJng-zPdr9i_MYhKL2Honc-XFcpPAh-pkobRmOSdLVCSciiQ@mail.gmail.com>
Message-ID: <1455746032.2099472.524271778.15B5FD2D@webmail.messagingengine.com>

I haven't found any way around this other than turning on session
affinity at the load balancer level.


On Wed, Feb 17, 2016, at 03:37 PM, Nicol?s Pozo wrote:
> Hi, JDBC_PING did the Job and infinispan seems to be working now. But
> I have another issue.
>
> I have 2 keycloak instances running behind a load balancer. When I get
> a token from server 1 and then load balancer sends requests to server
> 2 using this token, I get an error 401 because token is not valid. Is
> there any other missing configuration to sinchronize tokens?
>
> Thanks, Nicol?s.-
>
> 2016-02-17 13:01 GMT-03:00 Aikeaguinea <aikeaguinea at xsmail.com>:
>> Apologies to those reading my message in plaintext; apparently
>> all the
>>
spaces come out as question marks. I've updated the message to use
>>
plaintext below.
>>
>>
------------------------------------------------------------------------
--------------------------------------------------------------------
>>
>>
I just got JGroups/Infinispan with JDBC_PING working from inside a
>>
Docker cluster in ECS on EC2. I use JDBC_PING rather than S3_PING, since
>>
I need a database anyway and didn't want to have to set up an S3 bucket
>>
just for this one purpose. Nicol?s, if you're on AWS the default UDP
>>
transport for JGroups doesn't work because multicast isn't supported
>>
inside EC2, which may be your problem.
>>
>>
Here are the configurations you'd need:
>>
>>
1. The JGroups module has to reference to the db module. So in
>>
jgroups-module.xml I have:
>>
>>
<dependencies>
>>
<module name="javax.api"/>
>>
<module name="org.postgresql.jdbc"/>
>>
</dependencies>
>>
>>
2. The standalone-ha.xml has a JGroups subsystem (with TCP and
>>
JDBC_PING) that looks like the configuration below; I read certain
>>
variables from the environment, but may use the Wildfly vault tool for
>>
some of them. The external_addr property configurations are only needed
>>
if you're inside a Docker container, since Wildfly has to read the
>>
address of the EC2 instance hosting the container to register itself
>>
with JGroups. For the initialize_sql you can generally use the default,
>>
but for Postgres I needed a custom DDL because I needed the BYTEA data
>>
type which isn't in the default DDL.
>>
>>
<subsystem xmlns="urn:jboss:domain:jgroups:4.0">
>>
<channels default="ee">
>>
<channel name="ee" stack="tcp"/>
>>
</channels>
>>
>>
<stacks default="tcp">
>>
<stack name="tcp">
>>
<transport type="TCP" socket-binding="jgroups-tcp">
>>
<property
>>
name="external_addr">${env.EXTERNAL_HOST_IP}</property>
>>
</transport>
>>
>>
<protocol type="JDBC_PING">
>>
<property
>>
name="connection_driver">org.postgresql.Driver</property>
>>
<property
>>
name="connection_url">jdbc:postgresql://${env.POSTGRES_TCP_ADDR}:${env.-
POSTGRES_TCP_PORT}/${env.POSTGRES_DATABASE}</property>
>>
<property
>>
name="connection_username">${env.POSTGRES_USER}</property>
>>
<property
>>
name="connection_password">${env.POSTGRES_PASSWORD}</property>
>>
<property name="initialize_sql">
>>
CREATE TABLE IF NOT EXISTS jgroupsping (
>>
own_addr VARCHAR(200) NOT NULL,
>>
cluster_name VARCHAR(200) NOT NULL,
>>
ping_data BYTEA DEFAULT NULL,
>>
PRIMARY KEY (own_addr, cluster_name)
>>
)
>>
</property>
>>
</protocol>
>>
>>
<protocol type="MERGE3"/>
>>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd">
>>
<property
>>
name="external_addr">${env.EXTERNAL_HOST_IP}</property>
>>
</protocol>
>>
>>
<protocol type="FD"/>
>>
<protocol type="VERIFY_SUSPECT"/>
>>
<protocol type="pbcast.NAKACK2"/>
>>
<protocol type="UNICAST3"/>
>>
<protocol type="pbcast.STABLE"/>
>>
<protocol type="pbcast.GMS"/>
>>
<protocol type="MFC"/>
>>
<protocol type="FRAG2"/>
>>
</stack>
>>
</stacks>
>>
</subsystem>
>>
>>
3. If you're in a Docker container, you have to expose the JGroups ports
>>
so they are visible from outside the container, so in standalone-ha.xml
>>
in the socket bindings I have changed to the public interface:
>>
>>
<socket-binding name="jgroups-tcp" interface="public"
>>
port="7600"/>
>>
<socket-binding name="jgroups-tcp-fd" interface="public"
>>
port="57600"/>
>>
>>
4. For Docker, the startup script needs to pass the EXTERNAL_HOST_IP
>>
variable. I have a wrapper start script that first queries the AWS
>>
instance metadata service for the host's private IP address:
>>
>>
export EXTERNAL_HOST_IP=$(curl -s
>> 169.254.169.254/latest/meta-data/local-ipv4)
>>
exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-ha.xml
>>
-Djboss.node.name=$HOSTNAME -Djgroups.bind_addr=global -b $HOSTNAME
>>
>>
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
>>
> From: <keycloak-user-bounces at lists.jboss.org>
>>
> Date: Wednesday, February 17, 2016 at 9:03 AM
>>
> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>>
> Subject: [keycloak-user] Infinispan not working on HA environment with
> dockers.
>>
>
>>
> Hello all,
>>
> I'm trying to set a Keycloak HA environment up with dockers. I tried
> with jboss/keycloak-ha-postgres:1.8.0.Final image.
>>
>
>>
> I can't make infinispan work when I run 2 instances of my docker
> images. I get the following log in every node:
>>
>
>>
> Received new cluster view for channel ejb: [f9032dc82244|0] (1)
> [f9032dc82244]
>>
> Received new cluster view for channel hibernate: [f9032dc82244|0] (1)
> [f9032dc82244]
>>
> Received new cluster view for channel keycloak: [f9032dc82244|0] (1)
> [f9032dc82244]
>>
> Received new cluster view for channel web: [f9032dc82244|0] (1)
> [f9032dc82244]
>>
> Channel hibernate local address is f9032dc82244, physical addresses
> are [127.0.0.1:55200]
>>
> Channel keycloak local address is f9032dc82244, physical addresses are
> [127.0.0.1:55200]
>>
> Channel ejb local address is f9032dc82244, physical addresses are
> [127.0.0.1:55200]
>>
> Channel web local address is f9032dc82244, physical addresses are
> [127.0.0.1:55200]
>>
> Received new cluster view for channel server: [f9032dc82244|0] (1)
> [f9032dc82244]
>>
> Channel server local address is f9032dc82244, physical addresses are
> [127.0.0.1:55200]
>>
>
>>
> This is causing my user sessions are not shared between instances and
> it's not working properly.
>>
>
>>
> When I run 2 instances of keycloak without dockers, they work
> properly.
>>
>
>>
> Am I missing something? Is there any extra configuration that I need
> to change?
>>
>
>>
> Thanks,
>>
> Nicolas.-
>>
> --
>> http://www.fastmail.com - A fast, anti-spam email service.
>>
>> --
>>
Aikeaguinea
>> aikeaguinea at xsmail.com
>>
>>
>>
--
>> http://www.fastmail.com - Access your email from home and the web
 
--
? Aikeaguinea
? aikeaguinea at xsmail.com
 
 

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
                          love email again

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/9863a8f1/attachment-0001.html 

From bburke at redhat.com  Wed Feb 17 17:06:28 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Feb 2016 17:06:28 -0500
Subject: [keycloak-user] Using Keycloak in AWS EC2. What are people
 using? / Infinispan not working on HA environment withdockers.
In-Reply-To: <1455746032.2099472.524271778.15B5FD2D@webmail.messagingengine.com>
References: <1455721615.3814632.523858978.39C03FDB@webmail.messagingengine.com>
	<1455724863.3827648.523920298.7554D67E@webmail.messagingengine.com>
	<CAPLJng-zPdr9i_MYhKL2Honc-XFcpPAh-pkobRmOSdLVCSciiQ@mail.gmail.com>
	<1455746032.2099472.524271778.15B5FD2D@webmail.messagingengine.com>
Message-ID: <56C4EEE4.2040205@redhat.com>

What is the error event when the token is not valid?  I'm guess that 
this is happening on code to token.  If so, that may mean that the 
clustered cache is still not set up correctly.

On 2/17/2016 4:53 PM, Aikeaguinea wrote:
> I haven't found any way around this other than turning on session 
> affinity at the load balancer level.
> On Wed, Feb 17, 2016, at 03:37 PM, Nicol?s Pozo wrote:
>> Hi,
>> JDBC_PING did the Job and infinispan seems to be working now. But I 
>> have another issue.
>> I have 2 keycloak instances running behind a load balancer. When I 
>> get a token from server 1 and then load balancer sends requests to 
>> server 2 using this token, I get an error 401 because token is not 
>> valid. Is there any other missing configuration to sinchronize tokens?
>> Thanks,
>> Nicol?s.-
>> 2016-02-17 13:01 GMT-03:00 Aikeaguinea <aikeaguinea at xsmail.com 
>> <mailto:aikeaguinea at xsmail.com>>:
>>
>>     Apologies to those reading my message in plaintext; apparently
>>     all the
>>     spaces come out as question marks. I've updated the message to use
>>     plaintext below.
>>     --------------------------------------------------------------------------------------------------------------------------------------------
>>     I just got JGroups/Infinispan with JDBC_PING working from inside a
>>     Docker cluster in ECS on EC2. I use JDBC_PING rather than
>>     S3_PING, since
>>     I need a database anyway and didn't want to have to set up an S3
>>     bucket
>>     just for this one purpose. Nicol?s, if you're on AWS the default UDP
>>     transport for JGroups doesn't work because multicast isn't supported
>>     inside EC2, which may be your problem.
>>     Here are the configurations you'd need:
>>     1. The JGroups module has to reference to the db module. So in
>>     jgroups-module.xml I have:
>>       <dependencies>
>>         <module name="javax.api"/>
>>         <module name="org.postgresql.jdbc"/>
>>       </dependencies>
>>     2. The standalone-ha.xml has a JGroups subsystem (with TCP and
>>     JDBC_PING) that looks like the configuration below; I read certain
>>     variables from the environment, but may use the Wildfly vault
>>     tool for
>>     some of them. The external_addr property configurations are only
>>     needed
>>     if you're inside a Docker container, since Wildfly has to read the
>>     address of the EC2 instance hosting the container to register itself
>>     with JGroups. For the initialize_sql you can generally use the
>>     default,
>>     but for Postgres I needed a custom DDL because I needed the BYTEA
>>     data
>>     type which isn't in the default DDL.
>>     <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
>>           <channels default="ee">
>>             <channel name="ee" stack="tcp"/>
>>           </channels>
>>           <stacks default="tcp">
>>             <stack name="tcp">
>>               <transport type="TCP" socket-binding="jgroups-tcp">
>>                 <property
>>     name="external_addr">${env.EXTERNAL_HOST_IP}</property>
>>               </transport>
>>               <protocol type="JDBC_PING">
>>                 <property
>>     name="connection_driver">org.postgresql.Driver</property>
>>                 <property
>>     name="connection_url">jdbc:postgresql://${env.POSTGRES_TCP_ADDR}:${env.POSTGRES_TCP_PORT}/${env.POSTGRES_DATABASE}</property>
>>                 <property
>>     name="connection_username">${env.POSTGRES_USER}</property>
>>                 <property
>>     name="connection_password">${env.POSTGRES_PASSWORD}</property>
>>                 <property name="initialize_sql">
>>                   CREATE TABLE IF NOT EXISTS jgroupsping (
>>                     own_addr VARCHAR(200) NOT NULL,
>>                     cluster_name VARCHAR(200) NOT NULL,
>>                     ping_data BYTEA DEFAULT NULL,
>>                     PRIMARY KEY (own_addr, cluster_name)
>>                   )
>>                 </property>
>>               </protocol>
>>               <protocol type="MERGE3"/>
>>               <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd">
>>                 <property
>>     name="external_addr">${env.EXTERNAL_HOST_IP}</property>
>>               </protocol>
>>               <protocol type="FD"/>
>>               <protocol type="VERIFY_SUSPECT"/>
>>               <protocol type="pbcast.NAKACK2"/>
>>               <protocol type="UNICAST3"/>
>>               <protocol type="pbcast.STABLE"/>
>>               <protocol type="pbcast.GMS"/>
>>               <protocol type="MFC"/>
>>               <protocol type="FRAG2"/>
>>             </stack>
>>           </stacks>
>>         </subsystem>
>>     3. If you're in a Docker container, you have to expose the
>>     JGroups ports
>>     so they are visible from outside the container, so in
>>     standalone-ha.xml
>>     in the socket bindings I have changed to the public interface:
>>           <socket-binding name="jgroups-tcp" interface="public"
>>           port="7600"/>
>>           <socket-binding name="jgroups-tcp-fd" interface="public"
>>           port="57600"/>
>>     4. For Docker, the startup script needs to pass the EXTERNAL_HOST_IP
>>     variable. I have a wrapper start script that first queries the AWS
>>     instance metadata service for the host's private IP address:
>>      export EXTERNAL_HOST_IP=$(curl -s
>>     169.254.169.254/latest/meta-data/local-ipv4
>>     <http://169.254.169.254/latest/meta-data/local-ipv4>)
>>      exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-ha.xml
>>      -Djboss.node.name <http://Djboss.node.name>=$HOSTNAME
>>     -Djgroups.bind_addr=global -b $HOSTNAME
>>     >
>>     --------------------------------------------------------------------------------------------------------------------------------------------
>>     > From: <keycloak-user-bounces at lists.jboss.org
>>     <mailto:keycloak-user-bounces at lists.jboss.org>>
>>     > Date: Wednesday, February 17, 2016 at 9:03 AM
>>     > To: "keycloak-user at lists.jboss.org
>>     <mailto:keycloak-user at lists.jboss.org>"
>>     <keycloak-user at lists.jboss.org
>>     <mailto:keycloak-user at lists.jboss.org>>
>>     > Subject: [keycloak-user] Infinispan not working on HA
>>     environment with        dockers.
>>     >
>>     > Hello all,
>>     > I'm trying to set a Keycloak HA environment up with dockers. I
>>     tried with jboss/keycloak-ha-postgres:1.8.0.Final image.
>>     >
>>     > I can't make infinispan work when I run 2 instances of my
>>     docker images. I get the following log in every node:
>>     >
>>     > Received new cluster view for channel ejb: [f9032dc82244|0] (1)
>>     [f9032dc82244]
>>     > Received new cluster view for channel hibernate:
>>     [f9032dc82244|0] (1) [f9032dc82244]
>>     > Received new cluster view for channel keycloak:
>>     [f9032dc82244|0] (1) [f9032dc82244]
>>     > Received new cluster view for channel web: [f9032dc82244|0] (1)
>>     [f9032dc82244]
>>     > Channel hibernate local address is f9032dc82244, physical
>>     addresses are [127.0.0.1:55200 <http://127.0.0.1:55200>]
>>     > Channel keycloak local address is f9032dc82244, physical
>>     addresses are [127.0.0.1:55200 <http://127.0.0.1:55200>]
>>     > Channel ejb local address is f9032dc82244, physical addresses
>>     are [127.0.0.1:55200 <http://127.0.0.1:55200>]
>>     > Channel web local address is f9032dc82244, physical addresses
>>     are [127.0.0.1:55200 <http://127.0.0.1:55200>]
>>     > Received new cluster view for channel server: [f9032dc82244|0]
>>     (1) [f9032dc82244]
>>     > Channel server local address is f9032dc82244, physical
>>     addresses are [127.0.0.1:55200 <http://127.0.0.1:55200>]
>>     >
>>     > This is causing my user sessions are not shared between
>>     instances and it's not working properly.
>>     >
>>     > When I run 2 instances of keycloak without dockers, they work
>>     properly.
>>     >
>>     > Am I missing something? Is there any extra configuration that I
>>     need to change?
>>     >
>>     > Thanks,
>>     > Nicolas.-
>>     > --
>>     http://www.fastmail.com - A fast, anti-spam email service.
>>     --
>>       Aikeaguinea
>>     aikeaguinea at xsmail.com <mailto:aikeaguinea at xsmail.com>
>>
>>
>>     --
>>     http://www.fastmail.com - Access your email from home and the web
>>
> --
>   Aikeaguinea
>   aikeaguinea at xsmail.com
> -- 
> http://www.fastmail.com - Or how I learned to stop worrying and
>                            love email again
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160217/d60fb3da/attachment-0001.html 

From mposolda at redhat.com  Thu Feb 18 02:02:14 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 18 Feb 2016 08:02:14 +0100
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <1455745938.2099269.524233458.0C9F8B04@webmail.messagingengine.com>
References: <mailman.7140.1455742830.3326.keycloak-user@lists.jboss.org>
	<1455745938.2099269.524233458.0C9F8B04@webmail.messagingengine.com>
Message-ID: <56C56C76.7050905@redhat.com>

On 17/02/16 22:52, Aikeaguinea wrote:
> Running in Amazon's Elastic Container Service with an autoscaling group,
> which can bring up new EC2 instances to host the Dockers at any time
> without manual intervention, makes it challenging to share the file via
> volume or use the http URL.
>
> So far I've had the Wildfly startup wrapped in a script that calls
> add-user.sh before the server starts; we were thinking of using
> something like CredStash (https://github.com/fugue/credstash) as the
> source for the credentials. Then start-keycloak.sh would look something
> like this:
>
>       # Container needs to know its host, for JGroups
>       export EXTERNAL_HOST_IP=$(curl -s
>       169.254.169.254/latest/meta-data/local-ipv4)
>
>       $WILDFLY_HOME/bin/add-user.sh --container -u admin -p $(credstash
>       get $KEYCLOAK_WILDFLY_ADMIN_PWD_KEY)
>       $WILDFLY_HOME/bin/add-user.sh -u admin -p $(credstash get
>       $KEYCLOAK_ADMIN_PWD_KEY)
>
>       # Allow graceful shutdown from `docker stop`, which issues SIGTERM.
>       trap "$WILDFLY_HOME/bin/stop-keycloak.sh" SIGTERM
>       exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-ha.xml
>       -Djboss.node.name=$HOSTNAME -Djgroups.bind_addr=global -b $HOSTNAME
>
> Still, the password is being passed in the clear on the command line,
> and is visible via a process listing. Since the command is being run
> inside Docker, this would ultimately expose the password in cleartext to
> a docker history command.
>
> It looks like I'm going to have to figure out how to mount the files
> from a volume. Are the relevant files
> standalone/configuration/keycloak-add-user.json and
> standalone/configuration/mgmt-users.properties ?
Just the keycloak-add-user.json . The second one is for wildfly 
functionality and not related to keycloak.

Marek
>
>   Date: Wed, 17 Feb 2016 21:52:57 +0100
>> From: Marek Posolda <mposolda at redhat.com>
>> Subject: Re: [keycloak-user] Securely setting admin passwords
>> To: Aikeaguinea <aikeaguinea at xsmail.com>,
>> 	keycloak-user at lists.jboss.org
>> Message-ID: <56C4DDA9.2090401 at redhat.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> You can create the file in some "safe" environment (your laptop) and
>> then share the file with docker via volume and copy to the
>> standalone/configuration of the server? The created JSON file doesn't
>> contain password in plain text, but it's encoded.
>>
>> Also the "add-user.sh" script doesn't need server to be running.
>>
>> Finally, uf you don't need automated way, you can set it manually after
>> first startup when going to http://localhost:8080/auth
>>
>> Marek
>>
>>
>> On 17/02/16 17:09, Aikeaguinea wrote:
>>> It seems the add-user.sh  script for changing the admin password only
>>> accepts the password as a -p command-line parameter. This would expose
>>> the password in the command history, so I'd prefer not to use the
>>> command in its current form.
>>>
>>> Is there another way to do this?
>>>
>>> The situation is even more complicated with Docker, since running the
>>> script to change the Wildfly admin password requires restarting the
>>> server, which shuts down the container. If you have an autoscaling
>>> group, the container that gets brought up is not the container where you
>>> changed the password, but instead the original container. This seems to
>>> mean that the only way to have Keycloak run in Dockers in an autoscaling
>>> group is to bake the admin passwords into the Docker image beforehand.
>>> This isn't ideal; less so if the only way to add those passwords during
>>> build time is to run the shell script that exposes the password on the
>>> command line.


From mposolda at redhat.com  Thu Feb 18 02:10:12 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 18 Feb 2016 08:10:12 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
Message-ID: <56C56E54.8040901@redhat.com>

On 17/02/16 22:46, Jason Axley wrote:
> I followed some documentation like 
> https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for 
> configuring JBOSS to use LDAP over SSL to Active Directory but can?t 
> seem to get Keycloak to honor the trust settings in the configured 
> keystore.
>
> 2016-02-17 21:33:49,670 ERROR 
> [org.keycloak.services.managers.LDAPConnectionTestManager] (default 
> task-2) Error when authenticating to LDAP: simple bind failed: 
> server.example.com:636: javax.naming.CommunicationException: simple 
> bind failed: server.example.com:636 [Root exception is 
> javax.net.ssl.SSLHandshakeException: 
> sun.security.validator.ValidatorException: PKIX path building failed: 
> sun.security.provider.certpath.SunCertPathBuilderException: unable to 
> find valid certification path to requested target]
>
>         at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>
>
> This is the configuration I?m using for the standalone server:
>
> <security-realm name="LdapSSLRealm">
>
> <authentication>
>
> <truststore 
> path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"/>
>
> </authentication>
>
> </security-realm>
>
> </security-realms>
>
> <outbound-connections>
>
> <ldap 
> name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"/>
>
> </outbound-connections>
>
>
> I have all of the certs in the chain imported into the keystore:
>
> keytool -list -keystore ../configuration/keycloak.jks
>
> Enter keystore password:
>
>
> Keystore type: JKS
>
> Keystore provider: SUN
>
>
> Your keystore contains 5 entries
>
>
> cert1, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1): 
> D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>
> rootcert2, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1): 
> 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>
> mykey, Feb 12, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1): 
> 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>
> rootcert, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1): 
> 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>
> intermediateu, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1): 
> E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>
>
> Is there a way to find out if Keycloak/jboss is picking up this 
> truststore config?  Seems that it?s not.  Any other ideas?
Yes, it seems that it's not picking it. AFAIK we don't support retrieve 
truststore from the wildfly configuration of security-realm in 
standalone.xml . Maybe we should...

At this moment, what should work to configure truststore is either:
- Configure truststore SPI in keycloak-server.json. See 
http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
- add system properties |javax.net.ssl.trustStore and 
||javax.net.ssl.trustStorePassword

Marek
|
> -Jason
>
>
>
> _______________________________________________
> 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/20160218/1eb87e22/attachment.html 

From sthorger at redhat.com  Thu Feb 18 02:15:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 18 Feb 2016 08:15:07 +0100
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
Message-ID: <CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>

On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com> wrote:

> It seems the add-user.sh  script for changing the admin password only
> accepts the password as a -p command-line parameter. This would expose
> the password in the command history, so I'd prefer not to use the
> command in its current form.
>

That's a mistake we'll fix that. If not specified it should prompt for it.
Added https://issues.jboss.org/browse/KEYCLOAK-2501


>
> Is there another way to do this?
>
> The situation is even more complicated with Docker, since running the
> script to change the Wildfly admin password requires restarting the
> server, which shuts down the container. If you have an autoscaling
> group, the container that gets brought up is not the container where you
> changed the password, but instead the original container. This seems to
> mean that the only way to have Keycloak run in Dockers in an autoscaling
> group is to bake the admin passwords into the Docker image beforehand.
> This isn't ideal; less so if the only way to add those passwords during
> build time is to run the shell script that exposes the password on the
> command line.
>

You need to set the password once for your database. This can be done prior
to accessing the admin console the first time. Take a look at
https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
you can use docker exec to do this.


>
> --
> http://www.fastmail.com - Access your email from home and the web
>
> _______________________________________________
> 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/20160218/04907aaf/attachment-0001.html 

From Edgar at info.nl  Thu Feb 18 03:59:58 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 18 Feb 2016 08:59:58 +0000
Subject: [keycloak-user] Frequent LDAP bind failed socket connection
 reset exceptions in Keycloak LDAP user federation
In-Reply-To: <56C4D913.2030904@redhat.com>
References: <5F0501E4-FEB6-4840-BC64-2FF0823A0B73@info.nl>
	<56C4D913.2030904@redhat.com>
Message-ID: <33C45922-BFAB-4755-B404-9D8E59D5B20A@info.nl>

Thanks! However it does not seem to help in our case so I think it is something different in our situation..

> On 17 Feb 2016, at 21:33, Marek Posolda <mposolda at redhat.com> wrote:
> 
> Maybe try to start Keycloak with -Dhttps.protocols=SSLv3 ?
> 
> Some more details:
> http://stackoverflow.com/questions/5507878/ssl-connection-reset
> http://stackoverflow.com/questions/17458500/why-am-i-receiving-a-java-net-socketexception-connection-reset-error-from-web-s
> 
> Marek
> 
> On 17/02/16 09:57, Edgar Vonk - Info.nl wrote:
>> hi,
>> 
>> We are getting frequent LDAP simple bind failed, socket exceptions, when communicating with our Active Directory server using the Keycloak user federation provider. The might very well be a problem on the AD side of things or perhaps in our network, but I was wondering if it might be something in Keycloak? We have not been able to narrow it down so far.
>> 
>> It happens quite often for example when manually synching users from AD to Keycloak but also for example when creating a new user from Keycloak to AD. When you try any such action again it always succeeds. It seems some sort of hiccup.
>> 
>> 09:08:23,080 ERROR [org.keycloak.services] LDAP Query failed
>> org.keycloak.models.ModelException: LDAP Query failed
>> 	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:168)
>> 	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getFirstResult(LDAPQuery.java:175)
>> 	at org.keycloak.federation.ldap.LDAPFederationProvider.loadLDAPUserByUsername(LDAPFederationProvider.java:504)
>> 
>> [..]
>> 
>> Caused by: org.keycloak.models.ModelException: Querying of LDAP failed org.keycloak.federation.ldap.idm.query.internal.LDAPQuery at 12228106
>> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:169)
>> 	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:164)
>> 	... 54 more
>> Caused by: javax.naming.CommunicationException: simple bind failed: ldap.hf.info.nl:636 [Root exception is java.net.SocketException: Connection reset]
>> 	at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788)
>> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
>> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
>> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
>> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
>> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
>> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>> 	at javax.naming.InitialContext.init(InitialContext.java:244)
>> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.createLdapContext(LDAPOperationManager.java:473)
>> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:541)
>> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.search(LDAPOperationManager.java:166)
>> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:160)
>> 	... 55 more
>> Caused by: java.net.SocketException: Connection reset
>> 	at java.net.SocketInputStream.read(SocketInputStream.java:209)
>> 	at java.net.SocketInputStream.read(SocketInputStream.java:141)
>> 	at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
>> 	at sun.security.ssl.InputRecord.read(InputRecord.java:503)
>> 	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
>> 	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
>> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
>> 	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>> 	at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
>> 	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:426)
>> 	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:399)
>> 	at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
>> 	at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
>> 	... 69 more
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 



From tdudgeon.ml at gmail.com  Thu Feb 18 04:42:25 2016
From: tdudgeon.ml at gmail.com (Tim Dudgeon)
Date: Thu, 18 Feb 2016 09:42:25 +0000
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
	<CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
Message-ID: <56C59201.4070008@gmail.com>

On 18/02/2016 07:15, Stian Thorgersen wrote:
> You need to set the password once for your database. This can be done 
> prior to accessing the admin console the first time. Take a look at 
> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md, 
> you can use docker exec to do this.

That info was very useful (been struggling with good way to do this for 
days).
I was unaware of it because it was not in the main README that get's 
propagated to Docker Hub.
Could all key config info like this get put in the main README.md?
https://github.com/jboss-dockerfiles/keycloak/blob/master/README.md

Tim

From tdudgeon.ml at gmail.com  Thu Feb 18 04:45:28 2016
From: tdudgeon.ml at gmail.com (Tim Dudgeon)
Date: Thu, 18 Feb 2016 09:45:28 +0000
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <1455745938.2099269.524233458.0C9F8B04@webmail.messagingengine.com>
References: <mailman.7140.1455742830.3326.keycloak-user@lists.jboss.org>
	<1455745938.2099269.524233458.0C9F8B04@webmail.messagingengine.com>
Message-ID: <56C592B8.6040609@gmail.com>

I was also struggling with this, but another post pointed to this info 
that allows the user/pass to be defined using environment variables. 
Should solve the problem?
https://github.com/jboss-dockerfiles/keycloak/tree/master/server

Tim


On 17/02/2016 21:52, Aikeaguinea wrote:
> Running in Amazon's Elastic Container Service with an autoscaling group,
> which can bring up new EC2 instances to host the Dockers at any time
> without manual intervention, makes it challenging to share the file via
> volume or use the http URL.
>
> So far I've had the Wildfly startup wrapped in a script that calls
> add-user.sh before the server starts; we were thinking of using
> something like CredStash (https://github.com/fugue/credstash) as the
> source for the credentials. Then start-keycloak.sh would look something
> like this:
>
>       # Container needs to know its host, for JGroups
>       export EXTERNAL_HOST_IP=$(curl -s
>       169.254.169.254/latest/meta-data/local-ipv4)
>
>       $WILDFLY_HOME/bin/add-user.sh --container -u admin -p $(credstash
>       get $KEYCLOAK_WILDFLY_ADMIN_PWD_KEY)
>       $WILDFLY_HOME/bin/add-user.sh -u admin -p $(credstash get
>       $KEYCLOAK_ADMIN_PWD_KEY)
>
>       # Allow graceful shutdown from `docker stop`, which issues SIGTERM.
>       trap "$WILDFLY_HOME/bin/stop-keycloak.sh" SIGTERM
>       exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-ha.xml
>       -Djboss.node.name=$HOSTNAME -Djgroups.bind_addr=global -b $HOSTNAME
>
> Still, the password is being passed in the clear on the command line,
> and is visible via a process listing. Since the command is being run
> inside Docker, this would ultimately expose the password in cleartext to
> a docker history command.
>
> It looks like I'm going to have to figure out how to mount the files
> from a volume. Are the relevant files
> standalone/configuration/keycloak-add-user.json and
> standalone/configuration/mgmt-users.properties ?
>
>   Date: Wed, 17 Feb 2016 21:52:57 +0100
>> From: Marek Posolda <mposolda at redhat.com>
>> Subject: Re: [keycloak-user] Securely setting admin passwords
>> To: Aikeaguinea <aikeaguinea at xsmail.com>,
>> 	keycloak-user at lists.jboss.org
>> Message-ID: <56C4DDA9.2090401 at redhat.com>
>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>
>> You can create the file in some "safe" environment (your laptop) and
>> then share the file with docker via volume and copy to the
>> standalone/configuration of the server? The created JSON file doesn't
>> contain password in plain text, but it's encoded.
>>
>> Also the "add-user.sh" script doesn't need server to be running.
>>
>> Finally, uf you don't need automated way, you can set it manually after
>> first startup when going to http://localhost:8080/auth
>>
>> Marek
>>
>>
>> On 17/02/16 17:09, Aikeaguinea wrote:
>>> It seems the add-user.sh  script for changing the admin password only
>>> accepts the password as a -p command-line parameter. This would expose
>>> the password in the command history, so I'd prefer not to use the
>>> command in its current form.
>>>
>>> Is there another way to do this?
>>>
>>> The situation is even more complicated with Docker, since running the
>>> script to change the Wildfly admin password requires restarting the
>>> server, which shuts down the container. If you have an autoscaling
>>> group, the container that gets brought up is not the container where you
>>> changed the password, but instead the original container. This seems to
>>> mean that the only way to have Keycloak run in Dockers in an autoscaling
>>> group is to bake the admin passwords into the Docker image beforehand.
>>> This isn't ideal; less so if the only way to add those passwords during
>>> build time is to run the shell script that exposes the password on the
>>> command line.


From leo.nunes at gjccorp.com.br  Thu Feb 18 06:50:42 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Thu, 18 Feb 2016 11:50:42 +0000
Subject: [keycloak-user] KeycloakSecurityContext returns NULL using Tomcat
	Adapter
Message-ID: <D2EB446E.2687E%leo.nunes@ojc.com.br>

Stian,

I have an application deployed on Tomcat 7 using the Tomcat Adapter.
When i'm logged in and I go to a non-secured URL, KeycloakSecurityContext returns null.
I deployed the same application to the Keycloak Standalone Server, there I don't have this problem.

At Tomcat the code below returns null when called from /movies/, and works when called from /article/
At Keycloak Standalone Server /movies/ and /article/ works fine.
(KeycloakSecurityContext) request.getAttribute(KeycloakSecurityContext.class.getName());

Why is this happening?

In my web.xml I have only one security-constraint securing /article/*

WEB.XML:
<security-constraint>
    <web-resource-collection>
        <web-resource-name>Articles</web-resource-name>
        <url-pattern>/article/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>user</role-name>
    </auth-constraint>
</security-constraint>


--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/b1fc4a60/attachment.html 

From Edgar at info.nl  Thu Feb 18 07:05:06 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 18 Feb 2016 12:05:06 +0000
Subject: [keycloak-user] Frequent LDAP bind failed socket connection
 reset exceptions in Keycloak LDAP user federation
In-Reply-To: <33C45922-BFAB-4755-B404-9D8E59D5B20A@info.nl>
References: <5F0501E4-FEB6-4840-BC64-2FF0823A0B73@info.nl>
	<56C4D913.2030904@redhat.com>
	<33C45922-BFAB-4755-B404-9D8E59D5B20A@info.nl>
Message-ID: <3EB8D14E-8EE5-4172-8D2B-29531E9F5795@info.nl>

Hi Marek,

We now start Keycloak with -Djdk.tls.client.protocols=TLSv1 and so far I have not seen the connection reset exceptions so hopefully this fixes it.

See: 
https://confluence.atlassian.com/display/JIRAKB/JIRA+Connection+reset+error+when+synchronising+with+Active+Directory+2012r2
https://social.technet.microsoft.com/Forums/windowsserver/en-US/b6ffa278-4a04-4609-ac35-8390f5ba9cb6/ldap-over-ssl-on-windows-2012r2-server-dcs-tls-12-not-working?forum=winserversecurity

cheers

Edgar

> On 18 Feb 2016, at 09:59, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:
> 
> Thanks! However it does not seem to help in our case so I think it is something different in our situation..
> 
>> On 17 Feb 2016, at 21:33, Marek Posolda <mposolda at redhat.com> wrote:
>> 
>> Maybe try to start Keycloak with -Dhttps.protocols=SSLv3 ?
>> 
>> Some more details:
>> http://stackoverflow.com/questions/5507878/ssl-connection-reset
>> http://stackoverflow.com/questions/17458500/why-am-i-receiving-a-java-net-socketexception-connection-reset-error-from-web-s
>> 
>> Marek
>> 
>> On 17/02/16 09:57, Edgar Vonk - Info.nl wrote:
>>> hi,
>>> 
>>> We are getting frequent LDAP simple bind failed, socket exceptions, when communicating with our Active Directory server using the Keycloak user federation provider. The might very well be a problem on the AD side of things or perhaps in our network, but I was wondering if it might be something in Keycloak? We have not been able to narrow it down so far.
>>> 
>>> It happens quite often for example when manually synching users from AD to Keycloak but also for example when creating a new user from Keycloak to AD. When you try any such action again it always succeeds. It seems some sort of hiccup.
>>> 
>>> 09:08:23,080 ERROR [org.keycloak.services] LDAP Query failed
>>> org.keycloak.models.ModelException: LDAP Query failed
>>> 	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:168)
>>> 	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getFirstResult(LDAPQuery.java:175)
>>> 	at org.keycloak.federation.ldap.LDAPFederationProvider.loadLDAPUserByUsername(LDAPFederationProvider.java:504)
>>> 
>>> [..]
>>> 
>>> Caused by: org.keycloak.models.ModelException: Querying of LDAP failed org.keycloak.federation.ldap.idm.query.internal.LDAPQuery at 12228106
>>> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:169)
>>> 	at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:164)
>>> 	... 54 more
>>> Caused by: javax.naming.CommunicationException: simple bind failed: ldap.hf.info.nl:636 [Root exception is java.net.SocketException: Connection reset]
>>> 	at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>>> 	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788)
>>> 	at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
>>> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
>>> 	at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
>>> 	at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
>>> 	at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
>>> 	at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
>>> 	at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>>> 	at javax.naming.InitialContext.init(InitialContext.java:244)
>>> 	at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
>>> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.createLdapContext(LDAPOperationManager.java:473)
>>> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:541)
>>> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.search(LDAPOperationManager.java:166)
>>> 	at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:160)
>>> 	... 55 more
>>> Caused by: java.net.SocketException: Connection reset
>>> 	at java.net.SocketInputStream.read(SocketInputStream.java:209)
>>> 	at java.net.SocketInputStream.read(SocketInputStream.java:141)
>>> 	at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
>>> 	at sun.security.ssl.InputRecord.read(InputRecord.java:503)
>>> 	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
>>> 	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>>> 	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
>>> 	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
>>> 	at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>>> 	at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
>>> 	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:426)
>>> 	at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:399)
>>> 	at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
>>> 	at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
>>> 	... 69 more
>>> _______________________________________________
>>> 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 juraj.janosik77 at gmail.com  Thu Feb 18 07:27:49 2016
From: juraj.janosik77 at gmail.com (Juraj Janosik)
Date: Thu, 18 Feb 2016 13:27:49 +0100
Subject: [keycloak-user] Update The Client: Inconsistent behaviour by
 deleting of attributes via REST admin command in 1.9.0.RC1
Message-ID: <CALQqei2MQCMR_udFaP4S=15W95rj=xnr95v7_cZuta2FG_Axhw@mail.gmail.com>

Hi,

I created a JIRA issue for this problem..

For detailed description please check
https://issues.jboss.org/browse/KEYCLOAK-2503

*Basic description:*

I want to delete 2 (custom) attributes defined via client representation in
body parameter "attributes" via REST admin command "Update the client" (PUT
method).
1.) customAttr_1 via not defining in JSON's request body
2.) customAttr_2 via setting with value empty string ""

Execution of Update The Client REST request performs successfully with
status code 204 No Content.

Next I want to check the client representation via GET method.
The response returns customAttr_1 and does not return customAttr_2.
But If I want to re-create the deleted customAttr_2 (via UPDATE the
client), I receive HTTP status code 409 Conflict.
Conclusion:
1.) customAttr_1 not deleted
2.) customAttr_2 not present in GET response, but still present in DB in
table CLIENT_ATTRIBUTES with value Null.

Best Regards,
Juraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/6959d7d8/attachment.html 

From juraj.janosik77 at gmail.com  Thu Feb 18 07:42:16 2016
From: juraj.janosik77 at gmail.com (Juraj Janosik)
Date: Thu, 18 Feb 2016 13:42:16 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration: Displaying of
 "attributes" from Client Representation
Message-ID: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>

Hi,

is there any plan to support for displaying of "attributes" from Client
Representation
(like users configuration) in Admin Console?

Thanks.

Best Regards,
Juraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/2c5f1f24/attachment.html 

From sthorger at redhat.com  Thu Feb 18 08:12:02 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 18 Feb 2016 14:12:02 +0100
Subject: [keycloak-user] KeycloakSecurityContext returns NULL using
	Tomcat Adapter
In-Reply-To: <D2EB446E.2687E%leo.nunes@ojc.com.br>
References: <D2EB446E.2687E%leo.nunes@ojc.com.br>
Message-ID: <CAJgngAfFTpg+ciX0Gh-jL1RkwxYaY2qGYjYVhNUGhX6DFDp4HA@mail.gmail.com>

This is down to the fact that there are differences between different
containers. In reality you can only guarantee that KeycloakSecurityContext
as long as the request requires authentication. Add a security-constraint
for movies and you're fine.

On 18 February 2016 at 12:50, LEONARDO NUNES <leo.nunes at gjccorp.com.br>
wrote:

> Stian,
>
> I have an application deployed on Tomcat 7 using the Tomcat Adapter.
> When i'm logged in and I go to a non-secured URL, KeycloakSecurityContext
> returns null.
> I deployed the same application to the Keycloak Standalone Server, there I
> don't have this problem.
>
> At Tomcat the code below returns null when called from /movies/, and works
> when called from /article/
> At Keycloak Standalone Server /movies/ and /article/ works fine.
> (KeycloakSecurityContext)
> request.getAttribute(KeycloakSecurityContext.class.getName());
>
> Why is this happening?
>
> In my web.xml I have only one security-constraint securing /article/*
>
> WEB.XML:
> <security-constraint>
>     <web-resource-collection>
>         <web-resource-name>Articles</web-resource-name>
>         <url-pattern>/article/*</url-pattern>
>     </web-resource-collection>
>     <auth-constraint>
>         <role-name>user</role-name>
>     </auth-constraint>
> </security-constraint>
>
>
> --
> Leonardo Nunes
> ------------------------------
>
>
> *Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem,
> n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar
> qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por
> engano, por favor avise imediatamente o remetente, respondendo o e-mail e
> em seguida apague-o. Agradecemos sua coopera??o. This message may contain
> confidential and/or privileged information. If you are not the addressee or
> authorized to receive this for the addressee, you must not use, copy,
> disclose or take any action based on this message or any information
> herein. If you have received this message in error, please advise the
> sender immediately by reply e-mail and delete this message. Thank you for
> your cooperation*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/a4c04e50/attachment.html 

From leo.nunes at gjccorp.com.br  Thu Feb 18 08:22:23 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Thu, 18 Feb 2016 13:22:23 +0000
Subject: [keycloak-user] KeycloakSecurityContext returns NULL using
	Tomcat Adapter
In-Reply-To: <CAJgngAfFTpg+ciX0Gh-jL1RkwxYaY2qGYjYVhNUGhX6DFDp4HA@mail.gmail.com>
Message-ID: <D2EB5868.26884%leo.nunes@ojc.com.br>

Hi Stian, thanks for your replay.

The problem is that /movies is a page that doesn't require the user to be logged in.
But when he is logged in and goes to /movies, I need retrieve user information.
If I add a security-constraint for movies the user will be redirected to the login page, and this can't happen.

Is there another way I can do this?




From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: quinta-feira, 18 de fevereiro de 2016 11:12
To: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: KeycloakSecurityContext returns NULL using Tomcat Adapter

This is down to the fact that there are differences between different containers. In reality you can only guarantee that KeycloakSecurityContext as long as the request requires authentication. Add a security-constraint for movies and you're fine.

On 18 February 2016 at 12:50, LEONARDO NUNES <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>> wrote:
Stian,

I have an application deployed on Tomcat 7 using the Tomcat Adapter.
When i'm logged in and I go to a non-secured URL, KeycloakSecurityContext returns null.
I deployed the same application to the Keycloak Standalone Server, there I don't have this problem.

At Tomcat the code below returns null when called from /movies/, and works when called from /article/
At Keycloak Standalone Server /movies/ and /article/ works fine.
(KeycloakSecurityContext) request.getAttribute(KeycloakSecurityContext.class.getName());

Why is this happening?

In my web.xml I have only one security-constraint securing /article/*

WEB.XML:
<security-constraint>
    <web-resource-collection>
        <web-resource-name>Articles</web-resource-name>
        <url-pattern>/article/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>user</role-name>
    </auth-constraint>
</security-constraint>


--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/e7eb8f09/attachment-0001.html 

From ssilvert at redhat.com  Thu Feb 18 08:46:14 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 Feb 2016 08:46:14 -0500
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
	<CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
Message-ID: <56C5CB26.9010803@redhat.com>

On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>
>
> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com 
> <mailto:aikeaguinea at xsmail.com>> wrote:
>
>     It seems the add-user.sh  script for changing the admin password only
>     accepts the password as a -p command-line parameter. This would expose
>     the password in the command history, so I'd prefer not to use the
>     command in its current form.
>
>
> That's a mistake we'll fix that. If not specified it should prompt for 
> it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
After attending several security talks the last couple of days, I've 
become rather sensitized to this kind of issue.  I feel quite strongly 
that we should never allow the password to be written to history in 
plain text.   I'm also afraid it could cause us to flunk government 
certifications.

On Windows, this really isn't a problem because command history is not 
saved.  After a CMD session ends, the history is lost (unless you 
install some third-party tool).

Perhaps there is a way to temporarily disable logging of command history 
in the add-user-keycloak.sh?

>
>     Is there another way to do this?
>
>     The situation is even more complicated with Docker, since running the
>     script to change the Wildfly admin password requires restarting the
>     server, which shuts down the container. If you have an autoscaling
>     group, the container that gets brought up is not the container
>     where you
>     changed the password, but instead the original container. This
>     seems to
>     mean that the only way to have Keycloak run in Dockers in an
>     autoscaling
>     group is to bake the admin passwords into the Docker image beforehand.
>     This isn't ideal; less so if the only way to add those passwords
>     during
>     build time is to run the shell script that exposes the password on the
>     command line.
>
>
> You need to set the password once for your database. This can be done 
> prior to accessing the admin console the first time. Take a look at 
> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md, 
> you can use docker exec to do this.
>
>
>     --
>     http://www.fastmail.com - Access your email from home and the web
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/18dbea77/attachment.html 

From bburke at redhat.com  Thu Feb 18 09:08:22 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 18 Feb 2016 09:08:22 -0500
Subject: [keycloak-user] KeycloakSecurityContext returns NULL using
 Tomcat Adapter
In-Reply-To: <D2EB5868.26884%leo.nunes@ojc.com.br>
References: <D2EB5868.26884%leo.nunes@ojc.com.br>
Message-ID: <56C5D056.1030209@redhat.com>

Log a jira.  I'll look into fixing it in the next few weeks.

On 2/18/2016 8:22 AM, LEONARDO NUNES wrote:
> Hi Stian, thanks for your replay.
>
> The problem is that /movies is a page that doesn't require the user to 
> be logged in.
> But when he is logged in and goes to /movies, I need retrieve user 
> information.
> If I add a security-constraint for movies the user will be redirected 
> to the login page, and this can't happen.
>
> Is there another way I can do this?
>
>
>
>
> From: Stian Thorgersen <sthorger at redhat.com <mailto:sthorger at redhat.com>>
> Reply-To: "stian at redhat.com <mailto:stian at redhat.com>" 
> <stian at redhat.com <mailto:stian at redhat.com>>
> Date: quinta-feira, 18 de fevereiro de 2016 11:12
> To: Leonardo Nunes <leo.nunes at gjccorp.com.br 
> <mailto:leo.nunes at gjccorp.com.br>>
> Cc: "keycloak-user at lists.jboss.org 
> <mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org 
> <mailto:keycloak-user at lists.jboss.org>>
> Subject: Re: KeycloakSecurityContext returns NULL using Tomcat Adapter
>
> This is down to the fact that there are differences between different 
> containers. In reality you can only guarantee 
> that KeycloakSecurityContext as long as the request requires 
> authentication. Add a security-constraint for movies and you're fine.
>
> On 18 February 2016 at 12:50, LEONARDO NUNES <leo.nunes at gjccorp.com.br 
> <mailto:leo.nunes at gjccorp.com.br>> wrote:
>
>     Stian,
>
>     I have an application deployed on Tomcat 7 using the Tomcat Adapter.
>     When i'm logged in and I go to a non-secured URL,
>     KeycloakSecurityContext returns null.
>     I deployed the same application to the Keycloak Standalone Server,
>     there I don't have this problem.
>
>     At Tomcat the code below returns null when called from /movies/,
>     and works when called from /article/
>     At Keycloak Standalone Server /movies/ and /article/ works fine.
>     (KeycloakSecurityContext)
>     request.getAttribute(KeycloakSecurityContext.class.getName());
>
>     Why is this happening?
>
>     In my web.xml I have only one security-constraint securing /article/*
>
>     WEB.XML:
>     <security-constraint>
>         <web-resource-collection>
>     <web-resource-name>Articles</web-resource-name>
>     <url-pattern>/article/*</url-pattern>
>         </web-resource-collection>
>         <auth-constraint>
>     <role-name>user</role-name>
>         </auth-constraint>
>     </security-constraint>
>
>
>     -- 
>     Leonardo Nunes
>     ------------------------------------------------------------------------
>     /Esta mensagem pode conter informa??o confidencial e/ou
>     privilegiada. Se voc? n?o for o destinat?rio ou a pessoa
>     autorizada a receber esta mensagem, n?o poder? usar, copiar ou
>     divulgar as informa??es nela contidas ou tomar qualquer a??o
>     baseada nessas informa??es. Se voc? recebeu esta mensagem por
>     engano, por favor avise imediatamente o remetente, respondendo o
>     e-mail e em seguida apague-o. Agradecemos sua coopera??o.
>
>     This message may contain confidential and/or privileged
>     information. If you are not the addressee or authorized to receive
>     this for the addressee, you must not use, copy, disclose or take
>     any action based on this message or any information herein. If you
>     have received this message in error, please advise the sender
>     immediately by reply e-mail and delete this message. Thank you for
>     your cooperation/
>
>
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/1bb30056/attachment.html 

From bruno at abstractj.org  Thu Feb 18 09:10:38 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 18 Feb 2016 14:10:38 +0000
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <56C5CB26.9010803@redhat.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
	<CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
	<56C5CB26.9010803@redhat.com>
Message-ID: <CAM5SUC6U1Xt02e4yX0wq=KrXmg_FbU_DA7FTisq=_O0PHwzKug@mail.gmail.com>

I think the Jira created by Stian pretty much fixes the problem. Nope?

Something like:

./add-user-keycloak.sh -u user
Password: ******

Or

./add-user-keycloak-sh
Username: joe
Password: ******

If this can't fix the issue, is also possible to disable bash_history
temporarily. But I wouldn't take this route, because this is pretty much
system administration responsibility.


On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com> wrote:

> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>
>
>
> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com> wrote:
>
>> It seems the add-user.sh  script for changing the admin password only
>> accepts the password as a -p command-line parameter. This would expose
>> the password in the command history, so I'd prefer not to use the
>> command in its current form.
>>
>
> That's a mistake we'll fix that. If not specified it should prompt for it.
> Added https://issues.jboss.org/browse/KEYCLOAK-2501
>
> After attending several security talks the last couple of days, I've
> become rather sensitized to this kind of issue.  I feel quite strongly that
> we should never allow the password to be written to history in plain
> text.   I'm also afraid it could cause us to flunk government
> certifications.
>
> On Windows, this really isn't a problem because command history is not
> saved.  After a CMD session ends, the history is lost (unless you install
> some third-party tool).
>
> Perhaps there is a way to temporarily disable logging of command history
> in the add-user-keycloak.sh?
>
>
>
>
>>
>> Is there another way to do this?
>>
>> The situation is even more complicated with Docker, since running the
>> script to change the Wildfly admin password requires restarting the
>> server, which shuts down the container. If you have an autoscaling
>> group, the container that gets brought up is not the container where you
>> changed the password, but instead the original container. This seems to
>> mean that the only way to have Keycloak run in Dockers in an autoscaling
>> group is to bake the admin passwords into the Docker image beforehand.
>> This isn't ideal; less so if the only way to add those passwords during
>> build time is to run the shell script that exposes the password on the
>> command line.
>>
>
> You need to set the password once for your database. This can be done
> prior to accessing the admin console the first time. Take a look at
> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
> you can use docker exec to do this.
>
>
>>
>> --
>> http://www.fastmail.com - Access your email from home and the web
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160218/39257221/attachment-0001.html 

From ssilvert at redhat.com  Thu Feb 18 09:18:40 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 Feb 2016 09:18:40 -0500
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <CAM5SUC6U1Xt02e4yX0wq=KrXmg_FbU_DA7FTisq=_O0PHwzKug@mail.gmail.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
	<CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
	<56C5CB26.9010803@redhat.com>
	<CAM5SUC6U1Xt02e4yX0wq=KrXmg_FbU_DA7FTisq=_O0PHwzKug@mail.gmail.com>
Message-ID: <56C5D2C0.2020104@redhat.com>

On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
> I think the Jira created by Stian pretty much fixes the problem. Nope?
Stian's JIRA says that if it is not specified on the command line then 
do the prompt.  But if we still allow setting it from the command line 
then the password can still be saved to the log in plain text.  Security 
auditors will always frown on that.

So I'm saying we should either disallow setting on the command line or 
somehow disable saving to the log.  We shouldn't rely on an 
administrator to do the right thing.

>
> Something like:
>
> ./add-user-keycloak.sh -u user
> Password: ******
>
> Or
>
> ./add-user-keycloak-sh
> Username: joe
> Password: ******
>
> If this can't fix the issue, is also possible to disable bash_history 
> temporarily. But I wouldn't take this route, because this is pretty 
> much system administration responsibility.
>
>
> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>
>>
>>     On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com
>>     <mailto:aikeaguinea at xsmail.com>> wrote:
>>
>>         It seems the add-user.sh  script for changing the admin
>>         password only
>>         accepts the password as a -p command-line parameter. This
>>         would expose
>>         the password in the command history, so I'd prefer not to use the
>>         command in its current form.
>>
>>
>>     That's a mistake we'll fix that. If not specified it should
>>     prompt for it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
>     After attending several security talks the last couple of days,
>     I've become rather sensitized to this kind of issue.  I feel quite
>     strongly that we should never allow the password to be written to
>     history in plain text.   I'm also afraid it could cause us to
>     flunk government certifications.
>
>     On Windows, this really isn't a problem because command history is
>     not saved.  After a CMD session ends, the history is lost (unless
>     you install some third-party tool).
>
>     Perhaps there is a way to temporarily disable logging of command
>     history in the add-user-keycloak.sh?
>
>
>>
>>         Is there another way to do this?
>>
>>         The situation is even more complicated with Docker, since
>>         running the
>>         script to change the Wildfly admin password requires
>>         restarting the
>>         server, which shuts down the container. If you have an
>>         autoscaling
>>         group, the container that gets brought up is not the
>>         container where you
>>         changed the password, but instead the original container.
>>         This seems to
>>         mean that the only way to have Keycloak run in Dockers in an
>>         autoscaling
>>         group is to bake the admin passwords into the Docker image
>>         beforehand.
>>         This isn't ideal; less so if the only way to add those
>>         passwords during
>>         build time is to run the shell script that exposes the
>>         password on the
>>         command line.
>>
>>
>>     You need to set the password once for your database. This can be
>>     done prior to accessing the admin console the first time. Take a
>>     look at
>>     https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>     you can use docker exec to do this.
>>
>>
>>         --
>>         http://www.fastmail.com - Access your email from home and the web
>>
>>         _______________________________________________
>>         keycloak-user mailing list
>>         keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org  <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/175e4b7c/attachment.html 

From bruno at abstractj.org  Thu Feb 18 09:29:55 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 18 Feb 2016 14:29:55 +0000
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <56C5D2C0.2020104@redhat.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
	<CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
	<56C5CB26.9010803@redhat.com>
	<CAM5SUC6U1Xt02e4yX0wq=KrXmg_FbU_DA7FTisq=_O0PHwzKug@mail.gmail.com>
	<56C5D2C0.2020104@redhat.com>
Message-ID: <CAM5SUC7LJhXqqgH9fAu0uparx=CgWckbAFwZR6VcwEbAX51g1Q@mail.gmail.com>

I can be wrong, but this is not only our responsibility. For example, on
Linux you are prompted for the password with passwd, but at the same time
you could circumvent this using: echo 12345678 | sudo passwd admin --stdin.

In this scenario security auditors won't blame the OS for this, but pretty
much sysadmins and bad security practices. Anyways, whatever people think
is the best, I'm fine.

On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com> wrote:

> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>
> I think the Jira created by Stian pretty much fixes the problem. Nope?
>
> Stian's JIRA says that if it is not specified on the command line then do
> the prompt.  But if we still allow setting it from the command line then
> the password can still be saved to the log in plain text.  Security
> auditors will always frown on that.
>
> So I'm saying we should either disallow setting on the command line or
> somehow disable saving to the log.  We shouldn't rely on an administrator
> to do the right thing.
>
>
>
> Something like:
>
> ./add-user-keycloak.sh -u user
> Password: ******
>
> Or
>
> ./add-user-keycloak-sh
> Username: joe
> Password: ******
>
> If this can't fix the issue, is also possible to disable bash_history
> temporarily. But I wouldn't take this route, because this is pretty much
> system administration responsibility.
>
>
> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>
>>
>>
>> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com> wrote:
>>
>>> It seems the add-user.sh  script for changing the admin password only
>>> accepts the password as a -p command-line parameter. This would expose
>>> the password in the command history, so I'd prefer not to use the
>>> command in its current form.
>>>
>>
>> That's a mistake we'll fix that. If not specified it should prompt for
>> it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
>>
>> After attending several security talks the last couple of days, I've
>> become rather sensitized to this kind of issue.  I feel quite strongly that
>> we should never allow the password to be written to history in plain
>> text.   I'm also afraid it could cause us to flunk government
>> certifications.
>>
>> On Windows, this really isn't a problem because command history is not
>> saved.  After a CMD session ends, the history is lost (unless you install
>> some third-party tool).
>>
>> Perhaps there is a way to temporarily disable logging of command history
>> in the add-user-keycloak.sh?
>>
>>
>>
>>
>>>
>>> Is there another way to do this?
>>>
>>> The situation is even more complicated with Docker, since running the
>>> script to change the Wildfly admin password requires restarting the
>>> server, which shuts down the container. If you have an autoscaling
>>> group, the container that gets brought up is not the container where you
>>> changed the password, but instead the original container. This seems to
>>> mean that the only way to have Keycloak run in Dockers in an autoscaling
>>> group is to bake the admin passwords into the Docker image beforehand.
>>> This isn't ideal; less so if the only way to add those passwords during
>>> build time is to run the shell script that exposes the password on the
>>> command line.
>>>
>>
>> You need to set the password once for your database. This can be done
>> prior to accessing the admin console the first time. Take a look at
>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>> you can use docker exec to do this.
>>
>>
>>>
>>> --
>>> http://www.fastmail.com - Access your email from home and the web
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160218/e312ab57/attachment-0001.html 

From ssilvert at redhat.com  Thu Feb 18 09:45:02 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 Feb 2016 09:45:02 -0500
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <CAM5SUC7LJhXqqgH9fAu0uparx=CgWckbAFwZR6VcwEbAX51g1Q@mail.gmail.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
	<CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
	<56C5CB26.9010803@redhat.com>
	<CAM5SUC6U1Xt02e4yX0wq=KrXmg_FbU_DA7FTisq=_O0PHwzKug@mail.gmail.com>
	<56C5D2C0.2020104@redhat.com>
	<CAM5SUC7LJhXqqgH9fAu0uparx=CgWckbAFwZR6VcwEbAX51g1Q@mail.gmail.com>
Message-ID: <56C5D8EE.1020805@redhat.com>

On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
> I can be wrong, but this is not only our responsibility. For example, 
> on Linux you are prompted for the password with passwd, but at the 
> same time you could circumvent this using: echo 12345678 | sudo passwd 
> admin --stdin.
>
> In this scenario security auditors won't blame the OS for this, but 
> pretty much sysadmins and bad security practices. Anyways, whatever 
> people think is the best, I'm fine.
I agree with you there.  In that case you are doing something extra to 
shoot yourself in the foot.  We can't guard against that.

We just shouldn't put the gun in your hand.
>
> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>     I think the Jira created by Stian pretty much fixes the problem.
>>     Nope?
>     Stian's JIRA says that if it is not specified on the command line
>     then do the prompt.  But if we still allow setting it from the
>     command line then the password can still be saved to the log in
>     plain text.  Security auditors will always frown on that.
>
>     So I'm saying we should either disallow setting on the command
>     line or somehow disable saving to the log.  We shouldn't rely on
>     an administrator to do the right thing.
>
>
>>
>>     Something like:
>>
>>     ./add-user-keycloak.sh -u user
>>     Password: ******
>>
>>     Or
>>
>>     ./add-user-keycloak-sh
>>     Username: joe
>>     Password: ******
>>
>>     If this can't fix the issue, is also possible to disable
>>     bash_history temporarily. But I wouldn't take this route, because
>>     this is pretty much system administration responsibility.
>>
>>
>>     On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert
>>     <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>
>>         On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>
>>>
>>>         On 17 February 2016 at 17:09, Aikeaguinea
>>>         <aikeaguinea at xsmail.com <mailto:aikeaguinea at xsmail.com>> wrote:
>>>
>>>             It seems the add-user.sh  script for changing the admin
>>>             password only
>>>             accepts the password as a -p command-line parameter.
>>>             This would expose
>>>             the password in the command history, so I'd prefer not
>>>             to use the
>>>             command in its current form.
>>>
>>>
>>>         That's a mistake we'll fix that. If not specified it should
>>>         prompt for it. Added
>>>         https://issues.jboss.org/browse/KEYCLOAK-2501
>>         After attending several security talks the last couple of
>>         days, I've become rather sensitized to this kind of issue.  I
>>         feel quite strongly that we should never allow the password
>>         to be written to history in plain text. I'm also afraid it
>>         could cause us to flunk government certifications.
>>
>>         On Windows, this really isn't a problem because command
>>         history is not saved.  After a CMD session ends, the history
>>         is lost (unless you install some third-party tool).
>>
>>         Perhaps there is a way to temporarily disable logging of
>>         command history in the add-user-keycloak.sh?
>>
>>
>>>
>>>             Is there another way to do this?
>>>
>>>             The situation is even more complicated with Docker,
>>>             since running the
>>>             script to change the Wildfly admin password requires
>>>             restarting the
>>>             server, which shuts down the container. If you have an
>>>             autoscaling
>>>             group, the container that gets brought up is not the
>>>             container where you
>>>             changed the password, but instead the original
>>>             container. This seems to
>>>             mean that the only way to have Keycloak run in Dockers
>>>             in an autoscaling
>>>             group is to bake the admin passwords into the Docker
>>>             image beforehand.
>>>             This isn't ideal; less so if the only way to add those
>>>             passwords during
>>>             build time is to run the shell script that exposes the
>>>             password on the
>>>             command line.
>>>
>>>
>>>         You need to set the password once for your database. This
>>>         can be done prior to accessing the admin console the first
>>>         time. Take a look at
>>>         https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>>         you can use docker exec to do this.
>>>
>>>
>>>             --
>>>             http://www.fastmail.com - Access your email from home
>>>             and the web
>>>
>>>             _______________________________________________
>>>             keycloak-user mailing list
>>>             keycloak-user at lists.jboss.org
>>>             <mailto:keycloak-user at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         keycloak-user mailing list
>>>         keycloak-user at lists.jboss.org  <mailto:keycloak-user at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>         _______________________________________________
>>         keycloak-user mailing list
>>         keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/3df8df5c/attachment.html 

From nicopozo at gmail.com  Thu Feb 18 10:43:45 2016
From: nicopozo at gmail.com (=?UTF-8?Q?Nicol=C3=A1s_Pozo?=)
Date: Thu, 18 Feb 2016 12:43:45 -0300
Subject: [keycloak-user] Using Keycloak in AWS EC2. What are people
 using? / Infinispan not working on HA environment withdockers.
In-Reply-To: <56C4EEE4.2040205@redhat.com>
References: <1455721615.3814632.523858978.39C03FDB@webmail.messagingengine.com>
	<1455724863.3827648.523920298.7554D67E@webmail.messagingengine.com>
	<CAPLJng-zPdr9i_MYhKL2Honc-XFcpPAh-pkobRmOSdLVCSciiQ@mail.gmail.com>
	<1455746032.2099472.524271778.15B5FD2D@webmail.messagingengine.com>
	<56C4EEE4.2040205@redhat.com>
Message-ID: <CAPLJng9dgd1JVaAjLyHiOHocVva3+_Nk-fznSSzG2tktn7WJBA@mail.gmail.com>

We have discovered the issue. Both keycloak instances had 1:30' difference
and this caused the token validation error.

We've synchronized both servers time and everything is working perfect now!

Thanks you all for your help!
Nicolas.-

2016-02-17 19:06 GMT-03:00 Bill Burke <bburke at redhat.com>:

> What is the error event when the token is not valid?  I'm guess that this
> is happening on code to token.  If so, that may mean that the clustered
> cache is still not set up correctly.
>
>
> On 2/17/2016 4:53 PM, Aikeaguinea wrote:
>
> I haven't found any way around this other than turning on session affinity
> at the load balancer level.
>
>
> On Wed, Feb 17, 2016, at 03:37 PM, Nicol?s Pozo wrote:
>
> Hi,
> JDBC_PING did the Job and infinispan seems to be working now. But I have
> another issue.
>
> I have 2 keycloak instances running behind a load balancer. When I get a
> token from server 1 and then load balancer sends requests to server 2 using
> this token, I get an error 401 because token is not valid. Is there any
> other missing configuration to sinchronize tokens?
>
> Thanks,
> Nicol?s.-
>
> 2016-02-17 13:01 GMT-03:00 Aikeaguinea <aikeaguinea at xsmail.com>:
>
> Apologies to those reading my message in plaintext; apparently all the
> spaces come out as question marks. I've updated the message to use
> plaintext below.
>
>
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> I just got JGroups/Infinispan with JDBC_PING working from inside a
> Docker cluster in ECS on EC2. I use JDBC_PING rather than S3_PING, since
> I need a database anyway and didn't want to have to set up an S3 bucket
> just for this one purpose. Nicol?s, if you're on AWS the default UDP
> transport for JGroups doesn't work because multicast isn't supported
> inside EC2, which may be your problem.
>
> Here are the configurations you'd need:
>
> 1. The JGroups module has to reference to the db module. So in
> jgroups-module.xml I have:
>
>   <dependencies>
>     <module name="javax.api"/>
>     <module name="org.postgresql.jdbc"/>
>   </dependencies>
>
> 2. The standalone-ha.xml has a JGroups subsystem (with TCP and
> JDBC_PING) that looks like the configuration below; I read certain
> variables from the environment, but may use the Wildfly vault tool for
> some of them. The external_addr property configurations are only needed
> if you're inside a Docker container, since Wildfly has to read the
> address of the EC2 instance hosting the container to register itself
> with JGroups. For the initialize_sql you can generally use the default,
> but for Postgres I needed a custom DDL because I needed the BYTEA data
> type which isn't in the default DDL.
>
> <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
>       <channels default="ee">
>         <channel name="ee" stack="tcp"/>
>       </channels>
>
>       <stacks default="tcp">
>         <stack name="tcp">
>           <transport type="TCP" socket-binding="jgroups-tcp">
>             <property
>             name="external_addr">${env.EXTERNAL_HOST_IP}</property>
>           </transport>
>
>           <protocol type="JDBC_PING">
>             <property
>             name="connection_driver">org.postgresql.Driver</property>
>             <property
>
> name="connection_url">jdbc:postgresql://${env.POSTGRES_TCP_ADDR}:${env.POSTGRES_TCP_PORT}/${env.POSTGRES_DATABASE}</property>
>             <property
>             name="connection_username">${env.POSTGRES_USER}</property>
>             <property
>             name="connection_password">${env.POSTGRES_PASSWORD}</property>
>             <property name="initialize_sql">
>               CREATE TABLE IF NOT EXISTS jgroupsping (
>                 own_addr VARCHAR(200) NOT NULL,
>                 cluster_name VARCHAR(200) NOT NULL,
>                 ping_data BYTEA DEFAULT NULL,
>                 PRIMARY KEY (own_addr, cluster_name)
>               )
>             </property>
>           </protocol>
>
>           <protocol type="MERGE3"/>
>           <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd">
>             <property
>             name="external_addr">${env.EXTERNAL_HOST_IP}</property>
>           </protocol>
>
>           <protocol type="FD"/>
>           <protocol type="VERIFY_SUSPECT"/>
>           <protocol type="pbcast.NAKACK2"/>
>           <protocol type="UNICAST3"/>
>           <protocol type="pbcast.STABLE"/>
>           <protocol type="pbcast.GMS"/>
>           <protocol type="MFC"/>
>           <protocol type="FRAG2"/>
>         </stack>
>       </stacks>
>     </subsystem>
>
> 3. If you're in a Docker container, you have to expose the JGroups ports
> so they are visible from outside the container, so in standalone-ha.xml
> in the socket bindings I have changed to the public interface:
>
>       <socket-binding name="jgroups-tcp" interface="public"
>       port="7600"/>
>       <socket-binding name="jgroups-tcp-fd" interface="public"
>       port="57600"/>
>
> 4. For Docker, the startup script needs to pass the EXTERNAL_HOST_IP
> variable. I have a wrapper start script that first queries the AWS
> instance metadata service for the host's private IP address:
>
>  export EXTERNAL_HOST_IP=$(curl -s
> 169.254.169.254/latest/meta-data/local-ipv4)
>  exec $WILDFLY_HOME/bin/standalone.sh -c standalone-keycloak-ha.xml
>  -Djboss.node.name=$HOSTNAME -Djgroups.bind_addr=global -b $HOSTNAME
>
> >
> --------------------------------------------------------------------------------------------------------------------------------------------
> > From: <keycloak-user-bounces at lists.jboss.org>
> > Date: Wednesday, February 17, 2016 at 9:03 AM
> > To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> > Subject: [keycloak-user] Infinispan not working on HA environment with
>       dockers.
> >
> > Hello all,
> > I'm trying to set a Keycloak HA environment up with dockers. I tried
> with jboss/keycloak-ha-postgres:1.8.0.Final image.
> >
> > I can't make infinispan work when I run 2 instances of my docker images.
> I get the following log in every node:
> >
> > Received new cluster view for channel ejb: [f9032dc82244|0] (1)
> [f9032dc82244]
> > Received new cluster view for channel hibernate: [f9032dc82244|0] (1)
> [f9032dc82244]
> > Received new cluster view for channel keycloak: [f9032dc82244|0] (1)
> [f9032dc82244]
> > Received new cluster view for channel web: [f9032dc82244|0] (1)
> [f9032dc82244]
> > Channel hibernate local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> > Channel keycloak local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> > Channel ejb local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> > Channel web local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> > Received new cluster view for channel server: [f9032dc82244|0] (1)
> [f9032dc82244]
> > Channel server local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> >
> > This is causing my user sessions are not shared between instances and
> it's not working properly.
> >
> > When I run 2 instances of keycloak without dockers, they work properly.
> >
> > Am I missing something? Is there any extra configuration that I need to
> change?
> >
> > Thanks,
> > Nicolas.-
> > --
> http://www.fastmail.com - A fast, anti-spam email service.
>
> --
>   Aikeaguinea
> aikeaguinea at xsmail.com
>
>
> --
> http://www.fastmail.com - Access your email from home and the web
>
>
> --
>   Aikeaguinea
>   aikeaguinea at xsmail.com
>
>
>
> -- http://www.fastmail.com - Or how I learned to stop worrying and
>                           love email again
>
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160218/0bcbca5b/attachment-0001.html 

From bruno at abstractj.org  Thu Feb 18 10:53:49 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 18 Feb 2016 15:53:49 +0000
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <56C5D8EE.1020805@redhat.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
	<CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
	<56C5CB26.9010803@redhat.com>
	<CAM5SUC6U1Xt02e4yX0wq=KrXmg_FbU_DA7FTisq=_O0PHwzKug@mail.gmail.com>
	<56C5D2C0.2020104@redhat.com>
	<CAM5SUC7LJhXqqgH9fAu0uparx=CgWckbAFwZR6VcwEbAX51g1Q@mail.gmail.com>
	<56C5D8EE.1020805@redhat.com>
Message-ID: <CAM5SUC4mRDo=OntdUX2nRewpJSkw2nycQGJ7Tmsw-3bQ1W2e4A@mail.gmail.com>

It's about balance. I'm not arguing here against it, I just don't see how
it could strengthen security. Nothing will stop people to get their own gun
and automate it with stdin :)

On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com> wrote:

> On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>
> I can be wrong, but this is not only our responsibility. For example, on
> Linux you are prompted for the password with passwd, but at the same time
> you could circumvent this using: echo 12345678 | sudo passwd admin --stdin.
>
> In this scenario security auditors won't blame the OS for this, but pretty
> much sysadmins and bad security practices. Anyways, whatever people think
> is the best, I'm fine.
>
> I agree with you there.  In that case you are doing something extra to
> shoot yourself in the foot.  We can't guard against that.
>
> We just shouldn't put the gun in your hand.
>
>
> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>
>> I think the Jira created by Stian pretty much fixes the problem. Nope?
>>
>> Stian's JIRA says that if it is not specified on the command line then do
>> the prompt.  But if we still allow setting it from the command line then
>> the password can still be saved to the log in plain text.  Security
>> auditors will always frown on that.
>>
>> So I'm saying we should either disallow setting on the command line or
>> somehow disable saving to the log.  We shouldn't rely on an administrator
>> to do the right thing.
>>
>>
>>
>> Something like:
>>
>> ./add-user-keycloak.sh -u user
>> Password: ******
>>
>> Or
>>
>> ./add-user-keycloak-sh
>> Username: joe
>> Password: ******
>>
>> If this can't fix the issue, is also possible to disable bash_history
>> temporarily. But I wouldn't take this route, because this is pretty much
>> system administration responsibility.
>>
>>
>> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com>
>> wrote:
>>
>>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com>
>>> wrote:
>>>
>>>> It seems the add-user.sh  script for changing the admin password only
>>>> accepts the password as a -p command-line parameter. This would expose
>>>> the password in the command history, so I'd prefer not to use the
>>>> command in its current form.
>>>>
>>>
>>> That's a mistake we'll fix that. If not specified it should prompt for
>>> it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
>>>
>>> After attending several security talks the last couple of days, I've
>>> become rather sensitized to this kind of issue.  I feel quite strongly that
>>> we should never allow the password to be written to history in plain
>>> text.   I'm also afraid it could cause us to flunk government
>>> certifications.
>>>
>>> On Windows, this really isn't a problem because command history is not
>>> saved.  After a CMD session ends, the history is lost (unless you install
>>> some third-party tool).
>>>
>>> Perhaps there is a way to temporarily disable logging of command history
>>> in the add-user-keycloak.sh?
>>>
>>>
>>>
>>>
>>>>
>>>> Is there another way to do this?
>>>>
>>>> The situation is even more complicated with Docker, since running the
>>>> script to change the Wildfly admin password requires restarting the
>>>> server, which shuts down the container. If you have an autoscaling
>>>> group, the container that gets brought up is not the container where you
>>>> changed the password, but instead the original container. This seems to
>>>> mean that the only way to have Keycloak run in Dockers in an autoscaling
>>>> group is to bake the admin passwords into the Docker image beforehand.
>>>> This isn't ideal; less so if the only way to add those passwords during
>>>> build time is to run the shell script that exposes the password on the
>>>> command line.
>>>>
>>>
>>> You need to set the password once for your database. This can be done
>>> prior to accessing the admin console the first time. Take a look at
>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>> you can use docker exec to do this.
>>>
>>>
>>>>
>>>> --
>>>> http://www.fastmail.com - Access your email from home and the web
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160218/2f334da4/attachment.html 

From jaxley at expedia.com  Thu Feb 18 11:04:19 2016
From: jaxley at expedia.com (Jason Axley)
Date: Thu, 18 Feb 2016 16:04:19 +0000
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <56C56E54.8040901@redhat.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
Message-ID: <7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>

I got the keystore working in the keycloak-server.json config to enable SMTP TLS connections to Amazon SES so I know that is being picked up:


"truststore": {

      "file": {

          "file": "${jboss.server.config.dir}/keycloak.jks",

          "password": ?password",

  "hostname-verification-policy": "WILDCARD",

  "disabled": false

      }

  }

But, this same configuration is not applied to the LDAP connections.  I finally got it to work by adding the Java keystore arguments to the startup:


nohup ../bin/standalone.sh -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks -Djavax.net.ssl.trustStorePassword=password

Would seem to be a bug to not apply the same keystore configuration to the LDAP connections?

-Jason

From: Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>>
Date: Wednesday, February 17, 2016 at 11:10 PM
To: Jason Axley <jaxley at expedia.com<mailto:jaxley at expedia.com>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] LDAPS configuration fails "Test authentication"

On 17/02/16 22:46, Jason Axley wrote:
I followed some documentation like https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for configuring JBOSS to use LDAP over SSL to Active Directory but can?t seem to get Keycloak to honor the trust settings in the configured keystore.


2016-02-17 21:33:49,670 ERROR [org.keycloak.services.managers.LDAPConnectionTestManager] (default task-2) Error when authenticating to LDAP: simple bind failed: server.example.com:636: javax.naming.CommunicationException: simple bind failed: server.example.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

        at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)

This is the configuration I?m using for the standalone server:


           <security-realm name="LdapSSLRealm">

               <authentication>

                <truststore path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password" />

               </authentication>

            </security-realm>

        </security-realms>

        <outbound-connections>

            <ldap name=?AD"url="ldaps://server.example.com:636"<ldaps://server.example.com:636>security-realm="LdapSSLRealm" />

        </outbound-connections>

I have all of the certs in the chain imported into the keystore:


keytool -list -keystore ../configuration/keycloak.jks

Enter keystore password:


Keystore type: JKS

Keystore provider: SUN


Your keystore contains 5 entries


cert1, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE

rootcert2, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A

mykey, Feb 12, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15

rootcert, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD

intermediateu, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D

Is there a way to find out if Keycloak/jboss is picking up this truststore config?  Seems that it?s not.  Any other ideas?
Yes, it seems that it's not picking it. AFAIK we don't support retrieve truststore from the wildfly configuration of security-realm in standalone.xml . Maybe we should...

At this moment, what should work to configure truststore is either:
- Configure truststore SPI in keycloak-server.json. See http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
- add system properties javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword

Marek
-Jason



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/11764fda/attachment-0001.html 

From mposolda at redhat.com  Thu Feb 18 11:15:34 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 18 Feb 2016 17:15:34 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
Message-ID: <56C5EE26.8060703@redhat.com>

That's possible. Could you please create JIRA for this?

Which LDAP server are you using btv? Not sure if it's related, but maybe 
yes...

Thanks,
Marek

On 18/02/16 17:04, Jason Axley wrote:
> I got the keystore working in the keycloak-server.json config to 
> enable SMTP TLS connections to Amazon SES so I know that is being 
> picked up:
>
> "truststore": {
>
>       "file": {
>
>           "file": "${jboss.server.config.dir}/keycloak.jks",
>
>           "password": ?password",
>
> "hostname-verification-policy": "WILDCARD",
>
> "disabled": false
>
>       }
>
>   }
>
>
> But, this same configuration is not applied to the LDAP connections. 
>  I finally got it to work by adding the Java keystore arguments to the 
> startup:
>
> nohup ../bin/standalone.sh 
> -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks 
> -Djavax.net.ssl.trustStorePassword=password
>
>
> Would seem to be a bug to not apply the same keystore configuration to 
> the LDAP connections?
>
> -Jason
>
> From: Marek Posolda <mposolda at redhat.com <mailto:mposolda at redhat.com>>
> Date: Wednesday, February 17, 2016 at 11:10 PM
> To: Jason Axley <jaxley at expedia.com <mailto:jaxley at expedia.com>>, 
> "keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>" 
> <keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>>
> Subject: Re: [keycloak-user] LDAPS configuration fails "Test 
> authentication"
>
> On 17/02/16 22:46, Jason Axley wrote:
>> I followed some documentation like 
>> https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for 
>> configuring JBOSS to use LDAP over SSL to Active Directory but can?t 
>> seem to get Keycloak to honor the trust settings in the configured 
>> keystore.
>>
>> 2016-02-17 21:33:49,670 ERROR 
>> [org.keycloak.services.managers.LDAPConnectionTestManager] (default 
>> task-2) Error when authenticating to LDAP: simple bind failed: 
>> server.example.com:636: javax.naming.CommunicationException: simple 
>> bind failed: server.example.com:636 [Root exception is 
>> javax.net.ssl.SSLHandshakeException: 
>> sun.security.validator.ValidatorException: PKIX path building failed: 
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to 
>> find valid certification path to requested target]
>>
>>         at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>>
>>
>> This is the configuration I?m using for the standalone server:
>>
>> <security-realm name="LdapSSLRealm">
>>
>> <authentication>
>>
>> <truststore 
>> path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"/>
>>
>> </authentication>
>>
>> </security-realm>
>>
>> </security-realms>
>>
>> <outbound-connections>
>>
>> <ldap 
>> name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"/>
>>
>> </outbound-connections>
>>
>>
>> I have all of the certs in the chain imported into the keystore:
>>
>> keytool -list -keystore ../configuration/keycloak.jks
>>
>> Enter keystore password:
>>
>>
>> Keystore type: JKS
>>
>> Keystore provider: SUN
>>
>>
>> Your keystore contains 5 entries
>>
>>
>> cert1, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1): 
>> D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>>
>> rootcert2, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1): 
>> 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>>
>> mykey, Feb 12, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1): 
>> 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>>
>> rootcert, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1): 
>> 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>>
>> intermediateu, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1): 
>> E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>>
>>
>> Is there a way to find out if Keycloak/jboss is picking up this 
>> truststore config?  Seems that it?s not.  Any other ideas?
> Yes, it seems that it's not picking it. AFAIK we don't support 
> retrieve truststore from the wildfly configuration of security-realm 
> in standalone.xml . Maybe we should...
>
> At this moment, what should work to configure truststore is either:
> - Configure truststore SPI in keycloak-server.json. See 
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
> - add system properties |javax.net.ssl.trustStore and | 
> |javax.net.ssl.trustStorePassword
>
> Marek
> |
>> -Jason
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-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/20160218/290a638c/attachment.html 

From jaxley at expedia.com  Thu Feb 18 11:20:01 2016
From: jaxley at expedia.com (Jason Axley)
Date: Thu, 18 Feb 2016 16:20:01 +0000
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <56C5EE26.8060703@redhat.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
	<56C5EE26.8060703@redhat.com>
Message-ID: <B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>

Will do.

This is Active Directory.

-Jason

From: Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>>
Date: Thursday, February 18, 2016 at 8:15 AM
To: Jason Axley <jaxley at expedia.com<mailto:jaxley at expedia.com>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] LDAPS configuration fails "Test authentication"

That's possible. Could you please create JIRA for this?

Which LDAP server are you using btv? Not sure if it's related, but maybe yes...

Thanks,
Marek

On 18/02/16 17:04, Jason Axley wrote:
I got the keystore working in the keycloak-server.json config to enable SMTP TLS connections to Amazon SES so I know that is being picked up:


"truststore": {

      "file": {

          "file": "${jboss.server.config.dir}/keycloak.jks",

          "password": ?password",

  "hostname-verification-policy": "WILDCARD",

  "disabled": false

      }

  }

But, this same configuration is not applied to the LDAP connections.  I finally got it to work by adding the Java keystore arguments to the startup:


nohup ../bin/standalone.sh -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks -Djavax.net.ssl.trustStorePassword=password

Would seem to be a bug to not apply the same keystore configuration to the LDAP connections?

-Jason

From: Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>>
Date: Wednesday, February 17, 2016 at 11:10 PM
To: Jason Axley <<mailto:jaxley at expedia.com>jaxley at expedia.com<mailto:jaxley at expedia.com>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] LDAPS configuration fails "Test authentication"

On 17/02/16 22:46, Jason Axley wrote:
I followed some documentation like <https://developer.jboss.org/wiki/LDAPSecurityRealmExamples> https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for configuring JBOSS to use LDAP over SSL to Active Directory but can?t seem to get Keycloak to honor the trust settings in the configured keystore.


2016-02-17 21:33:49,670 ERROR [org.keycloak.services.managers.LDAPConnectionTestManager] (default task-2) Error when authenticating to LDAP: simple bind failed: server.example.com:636: javax.naming.CommunicationException: simple bind failed: server.example.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

        at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)

This is the configuration I?m using for the standalone server:


           <security-realm name="LdapSSLRealm">

               <authentication>

                <truststore path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password" />

               </authentication>

            </security-realm>

        </security-realms>

        <outbound-connections>

            <ldap name=?AD"url=<ldaps://server.example.com:636>"ldaps://server.example.com:636"<ldaps://server.example.com:636>security-realm="LdapSSLRealm" />

        </outbound-connections>

I have all of the certs in the chain imported into the keystore:


keytool -list -keystore ../configuration/keycloak.jks

Enter keystore password:


Keystore type: JKS

Keystore provider: SUN


Your keystore contains 5 entries


cert1, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE

rootcert2, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A

mykey, Feb 12, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15

rootcert, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD

intermediateu, Feb 17, 2016, trustedCertEntry,

Certificate fingerprint (SHA1): E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D

Is there a way to find out if Keycloak/jboss is picking up this truststore config?  Seems that it?s not.  Any other ideas?
Yes, it seems that it's not picking it. AFAIK we don't support retrieve truststore from the wildfly configuration of security-realm in standalone.xml . Maybe we should...

At this moment, what should work to configure truststore is either:
- Configure truststore SPI in keycloak-server.json. See <http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
- add system properties javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword

Marek
-Jason



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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/6a2e48a7/attachment-0001.html 

From sthorger at redhat.com  Thu Feb 18 12:14:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 18 Feb 2016 18:14:12 +0100
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <CAM5SUC4mRDo=OntdUX2nRewpJSkw2nycQGJ7Tmsw-3bQ1W2e4A@mail.gmail.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
	<CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
	<56C5CB26.9010803@redhat.com>
	<CAM5SUC6U1Xt02e4yX0wq=KrXmg_FbU_DA7FTisq=_O0PHwzKug@mail.gmail.com>
	<56C5D2C0.2020104@redhat.com>
	<CAM5SUC7LJhXqqgH9fAu0uparx=CgWckbAFwZR6VcwEbAX51g1Q@mail.gmail.com>
	<56C5D8EE.1020805@redhat.com>
	<CAM5SUC4mRDo=OntdUX2nRewpJSkw2nycQGJ7Tmsw-3bQ1W2e4A@mail.gmail.com>
Message-ID: <CAJgngAdHFL7jZegfB7uCuzyD3zrBqhDO1BgkGxDw=7S9e2mn1Q@mail.gmail.com>

It's security vs usability as usual. Allowing passing the password directly
is convenient for developers, for Docker image, for provisioning tools,
etc.. So we're not going to remove that it's required, but I do appreciate
that if not used correctly it's a potential security risk. The worst case
scenario here is really that someone gets an admins favorite password, as
someone that has access to getting the bash history of that particular user
will also be able to run the add-user script themselves. So if the admin
wants to print his favorite password in clear text in the bash history we
should not stop him.

It's not our responsibility to clear the bash history, so we should not do
that either.

On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org> wrote:

> It's about balance. I'm not arguing here against it, I just don't see how
> it could strengthen security. Nothing will stop people to get their own gun
> and automate it with stdin :)
>
> On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>>
>> I can be wrong, but this is not only our responsibility. For example, on
>> Linux you are prompted for the password with passwd, but at the same time
>> you could circumvent this using: echo 12345678 | sudo passwd admin --stdin.
>>
>> In this scenario security auditors won't blame the OS for this, but
>> pretty much sysadmins and bad security practices. Anyways, whatever people
>> think is the best, I'm fine.
>>
>> I agree with you there.  In that case you are doing something extra to
>> shoot yourself in the foot.  We can't guard against that.
>>
>> We just shouldn't put the gun in your hand.
>>
>>
>> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com>
>> wrote:
>>
>>> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>>
>>> I think the Jira created by Stian pretty much fixes the problem. Nope?
>>>
>>> Stian's JIRA says that if it is not specified on the command line then
>>> do the prompt.  But if we still allow setting it from the command line then
>>> the password can still be saved to the log in plain text.  Security
>>> auditors will always frown on that.
>>>
>>> So I'm saying we should either disallow setting on the command line or
>>> somehow disable saving to the log.  We shouldn't rely on an administrator
>>> to do the right thing.
>>>
>>>
>>>
>>> Something like:
>>>
>>> ./add-user-keycloak.sh -u user
>>> Password: ******
>>>
>>> Or
>>>
>>> ./add-user-keycloak-sh
>>> Username: joe
>>> Password: ******
>>>
>>> If this can't fix the issue, is also possible to disable bash_history
>>> temporarily. But I wouldn't take this route, because this is pretty much
>>> system administration responsibility.
>>>
>>>
>>> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>>
>>>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com>
>>>> wrote:
>>>>
>>>>> It seems the add-user.sh  script for changing the admin password only
>>>>> accepts the password as a -p command-line parameter. This would expose
>>>>> the password in the command history, so I'd prefer not to use the
>>>>> command in its current form.
>>>>>
>>>>
>>>> That's a mistake we'll fix that. If not specified it should prompt for
>>>> it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
>>>>
>>>> After attending several security talks the last couple of days, I've
>>>> become rather sensitized to this kind of issue.  I feel quite strongly that
>>>> we should never allow the password to be written to history in plain
>>>> text.   I'm also afraid it could cause us to flunk government
>>>> certifications.
>>>>
>>>> On Windows, this really isn't a problem because command history is not
>>>> saved.  After a CMD session ends, the history is lost (unless you install
>>>> some third-party tool).
>>>>
>>>> Perhaps there is a way to temporarily disable logging of command
>>>> history in the add-user-keycloak.sh?
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Is there another way to do this?
>>>>>
>>>>> The situation is even more complicated with Docker, since running the
>>>>> script to change the Wildfly admin password requires restarting the
>>>>> server, which shuts down the container. If you have an autoscaling
>>>>> group, the container that gets brought up is not the container where
>>>>> you
>>>>> changed the password, but instead the original container. This seems to
>>>>> mean that the only way to have Keycloak run in Dockers in an
>>>>> autoscaling
>>>>> group is to bake the admin passwords into the Docker image beforehand.
>>>>> This isn't ideal; less so if the only way to add those passwords during
>>>>> build time is to run the shell script that exposes the password on the
>>>>> command line.
>>>>>
>>>>
>>>> You need to set the password once for your database. This can be done
>>>> prior to accessing the admin console the first time. Take a look at
>>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>>> you can use docker exec to do this.
>>>>
>>>>
>>>>>
>>>>> --
>>>>> http://www.fastmail.com - Access your email from home and the web
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160218/86268210/attachment.html 

From ssilvert at redhat.com  Thu Feb 18 12:26:16 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 Feb 2016 12:26:16 -0500
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <CAJgngAdHFL7jZegfB7uCuzyD3zrBqhDO1BgkGxDw=7S9e2mn1Q@mail.gmail.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
	<CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
	<56C5CB26.9010803@redhat.com>
	<CAM5SUC6U1Xt02e4yX0wq=KrXmg_FbU_DA7FTisq=_O0PHwzKug@mail.gmail.com>
	<56C5D2C0.2020104@redhat.com>
	<CAM5SUC7LJhXqqgH9fAu0uparx=CgWckbAFwZR6VcwEbAX51g1Q@mail.gmail.com>
	<56C5D8EE.1020805@redhat.com>
	<CAM5SUC4mRDo=OntdUX2nRewpJSkw2nycQGJ7Tmsw-3bQ1W2e4A@mail.gmail.com>
	<CAJgngAdHFL7jZegfB7uCuzyD3zrBqhDO1BgkGxDw=7S9e2mn1Q@mail.gmail.com>
Message-ID: <56C5FEB8.7060509@redhat.com>

On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
> It's security vs usability as usual. Allowing passing the password 
> directly is convenient for developers, for Docker image, for 
> provisioning tools, etc.. So we're not going to remove that it's 
> required, but I do appreciate that if not used correctly it's a 
> potential security risk. The worst case scenario here is really that 
> someone gets an admins favorite password, as someone that has access 
> to getting the bash history of that particular user will also be able 
> to run the add-user script themselves. So if the admin wants to print 
> his favorite password in clear text in the bash history we should not 
> stop him.
>
> It's not our responsibility to clear the bash history, so we should 
> not do that either.
If there is a way to stop that one command from being saved in the bash 
history then we should do it.

At the very least, we should print a warning message to let the 
administrator know he has done something that is potentially insecure.

>
> On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org 
> <mailto:bruno at abstractj.org>> wrote:
>
>     It's about balance. I'm not arguing here against it, I just don't
>     see how it could strengthen security. Nothing will stop people to
>     get their own gun and automate it with stdin :)
>
>     On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com
>     <mailto:ssilvert at redhat.com>> wrote:
>
>         On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>>         I can be wrong, but this is not only our responsibility. For
>>         example, on Linux you are prompted for the password with
>>         passwd, but at the same time you could circumvent this using:
>>         echo 12345678 | sudo passwd admin --stdin.
>>
>>         In this scenario security auditors won't blame the OS for
>>         this, but pretty much sysadmins and bad security practices.
>>         Anyways, whatever people think is the best, I'm fine.
>         I agree with you there.  In that case you are doing something
>         extra to shoot yourself in the foot.  We can't guard against that.
>
>         We just shouldn't put the gun in your hand.
>
>>
>>         On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert
>>         <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>
>>             On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>>             I think the Jira created by Stian pretty much fixes the
>>>             problem. Nope?
>>             Stian's JIRA says that if it is not specified on the
>>             command line then do the prompt.  But if we still allow
>>             setting it from the command line then the password can
>>             still be saved to the log in plain text.  Security
>>             auditors will always frown on that.
>>
>>             So I'm saying we should either disallow setting on the
>>             command line or somehow disable saving to the log.  We
>>             shouldn't rely on an administrator to do the right thing.
>>
>>
>>>
>>>             Something like:
>>>
>>>             ./add-user-keycloak.sh -u user
>>>             Password: ******
>>>
>>>             Or
>>>
>>>             ./add-user-keycloak-sh
>>>             Username: joe
>>>             Password: ******
>>>
>>>             If this can't fix the issue, is also possible to disable
>>>             bash_history temporarily. But I wouldn't take this
>>>             route, because this is pretty much system administration
>>>             responsibility.
>>>
>>>
>>>             On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert
>>>             <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>                 On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>>                 On 17 February 2016 at 17:09, Aikeaguinea
>>>>                 <aikeaguinea at xsmail.com
>>>>                 <mailto:aikeaguinea at xsmail.com>> wrote:
>>>>
>>>>                     It seems the add-user.sh script for changing
>>>>                     the admin password only
>>>>                     accepts the password as a -p command-line
>>>>                     parameter. This would expose
>>>>                     the password in the command history, so I'd
>>>>                     prefer not to use the
>>>>                     command in its current form.
>>>>
>>>>
>>>>                 That's a mistake we'll fix that. If not specified
>>>>                 it should prompt for it. Added
>>>>                 https://issues.jboss.org/browse/KEYCLOAK-2501
>>>                 After attending several security talks the last
>>>                 couple of days, I've become rather sensitized to
>>>                 this kind of issue. I feel quite strongly that we
>>>                 should never allow the password to be written to
>>>                 history in plain text.   I'm also afraid it could
>>>                 cause us to flunk government certifications.
>>>
>>>                 On Windows, this really isn't a problem because
>>>                 command history is not saved.  After a CMD session
>>>                 ends, the history is lost (unless you install some
>>>                 third-party tool).
>>>
>>>                 Perhaps there is a way to temporarily disable
>>>                 logging of command history in the add-user-keycloak.sh?
>>>
>>>
>>>>
>>>>                     Is there another way to do this?
>>>>
>>>>                     The situation is even more complicated with
>>>>                     Docker, since running the
>>>>                     script to change the Wildfly admin password
>>>>                     requires restarting the
>>>>                     server, which shuts down the container. If you
>>>>                     have an autoscaling
>>>>                     group, the container that gets brought up is
>>>>                     not the container where you
>>>>                     changed the password, but instead the original
>>>>                     container. This seems to
>>>>                     mean that the only way to have Keycloak run in
>>>>                     Dockers in an autoscaling
>>>>                     group is to bake the admin passwords into the
>>>>                     Docker image beforehand.
>>>>                     This isn't ideal; less so if the only way to
>>>>                     add those passwords during
>>>>                     build time is to run the shell script that
>>>>                     exposes the password on the
>>>>                     command line.
>>>>
>>>>
>>>>                 You need to set the password once for your
>>>>                 database. This can be done prior to accessing the
>>>>                 admin console the first time. Take a look at
>>>>                 https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>>>                 you can use docker exec to do this.
>>>>
>>>>
>>>>                     --
>>>>                     http://www.fastmail.com - Access your email
>>>>                     from home and the web
>>>>
>>>>                     _______________________________________________
>>>>                     keycloak-user mailing list
>>>>                     keycloak-user at lists.jboss.org
>>>>                     <mailto:keycloak-user at lists.jboss.org>
>>>>                     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 keycloak-user mailing list
>>>>                 keycloak-user at lists.jboss.org  <mailto:keycloak-user at lists.jboss.org>
>>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>                 _______________________________________________
>>>                 keycloak-user mailing list
>>>                 keycloak-user at lists.jboss.org
>>>                 <mailto:keycloak-user at lists.jboss.org>
>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/784bdcb7/attachment-0001.html 

From ssilvert at redhat.com  Thu Feb 18 12:45:52 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 Feb 2016 12:45:52 -0500
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <56C5FEB8.7060509@redhat.com>
References: <1455725365.3829411.523928258.51D05320@webmail.messagingengine.com>
	<CAJgngAeP0CGdzwk+HhGycY-GBounRoGtRZCB97HWNo89CZEAKw@mail.gmail.com>
	<56C5CB26.9010803@redhat.com>
	<CAM5SUC6U1Xt02e4yX0wq=KrXmg_FbU_DA7FTisq=_O0PHwzKug@mail.gmail.com>
	<56C5D2C0.2020104@redhat.com>
	<CAM5SUC7LJhXqqgH9fAu0uparx=CgWckbAFwZR6VcwEbAX51g1Q@mail.gmail.com>
	<56C5D8EE.1020805@redhat.com>
	<CAM5SUC4mRDo=OntdUX2nRewpJSkw2nycQGJ7Tmsw-3bQ1W2e4A@mail.gmail.com>
	<CAJgngAdHFL7jZegfB7uCuzyD3zrBqhDO1BgkGxDw=7S9e2mn1Q@mail.gmail.com>
	<56C5FEB8.7060509@redhat.com>
Message-ID: <56C60350.3050903@redhat.com>

On 2/18/2016 12:26 PM, Stan Silvert wrote:
> On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
>> It's security vs usability as usual. Allowing passing the password 
>> directly is convenient for developers, for Docker image, for 
>> provisioning tools, etc.. So we're not going to remove that it's 
>> required, but I do appreciate that if not used correctly it's a 
>> potential security risk. The worst case scenario here is really that 
>> someone gets an admins favorite password, as someone that has access 
>> to getting the bash history of that particular user will also be able 
>> to run the add-user script themselves.
BTW, the problem is not necessarily that someone broke in to the system 
in question.  They might have obtained the history from an offline 
backup or some other static reference.
>> So if the admin wants to print his favorite password in clear text in 
>> the bash history we should not stop him.
>>
>> It's not our responsibility to clear the bash history, so we should 
>> not do that either.
> If there is a way to stop that one command from being saved in the 
> bash history then we should do it.
>
> At the very least, we should print a warning message to let the 
> administrator know he has done something that is potentially insecure.
>
>>
>> On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org 
>> <mailto:bruno at abstractj.org>> wrote:
>>
>>     It's about balance. I'm not arguing here against it, I just don't
>>     see how it could strengthen security. Nothing will stop people to
>>     get their own gun and automate it with stdin :)
>>
>>     On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert
>>     <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>
>>         On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>>>         I can be wrong, but this is not only our responsibility. For
>>>         example, on Linux you are prompted for the password with
>>>         passwd, but at the same time you could circumvent this
>>>         using: echo 12345678 | sudo passwd admin --stdin.
>>>
>>>         In this scenario security auditors won't blame the OS for
>>>         this, but pretty much sysadmins and bad security practices.
>>>         Anyways, whatever people think is the best, I'm fine.
>>         I agree with you there.  In that case you are doing something
>>         extra to shoot yourself in the foot. We can't guard against that.
>>
>>         We just shouldn't put the gun in your hand.
>>
>>>
>>>         On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert
>>>         <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>             On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>>>             I think the Jira created by Stian pretty much fixes the
>>>>             problem. Nope?
>>>             Stian's JIRA says that if it is not specified on the
>>>             command line then do the prompt.  But if we still allow
>>>             setting it from the command line then the password can
>>>             still be saved to the log in plain text.  Security
>>>             auditors will always frown on that.
>>>
>>>             So I'm saying we should either disallow setting on the
>>>             command line or somehow disable saving to the log.  We
>>>             shouldn't rely on an administrator to do the right thing.
>>>
>>>
>>>>
>>>>             Something like:
>>>>
>>>>             ./add-user-keycloak.sh -u user
>>>>             Password: ******
>>>>
>>>>             Or
>>>>
>>>>             ./add-user-keycloak-sh
>>>>             Username: joe
>>>>             Password: ******
>>>>
>>>>             If this can't fix the issue, is also possible to
>>>>             disable bash_history temporarily. But I wouldn't take
>>>>             this route, because this is pretty much system
>>>>             administration responsibility.
>>>>
>>>>
>>>>             On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert
>>>>             <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>>>
>>>>                 On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>>                 On 17 February 2016 at 17:09, Aikeaguinea
>>>>>                 <aikeaguinea at xsmail.com
>>>>>                 <mailto:aikeaguinea at xsmail.com>> wrote:
>>>>>
>>>>>                     It seems the add-user.sh script for changing
>>>>>                     the admin password only
>>>>>                     accepts the password as a -p command-line
>>>>>                     parameter. This would expose
>>>>>                     the password in the command history, so I'd
>>>>>                     prefer not to use the
>>>>>                     command in its current form.
>>>>>
>>>>>
>>>>>                 That's a mistake we'll fix that. If not specified
>>>>>                 it should prompt for it. Added
>>>>>                 https://issues.jboss.org/browse/KEYCLOAK-2501
>>>>                 After attending several security talks the last
>>>>                 couple of days, I've become rather sensitized to
>>>>                 this kind of issue.  I feel quite strongly that we
>>>>                 should never allow the password to be written to
>>>>                 history in plain text.   I'm also afraid it could
>>>>                 cause us to flunk government certifications.
>>>>
>>>>                 On Windows, this really isn't a problem because
>>>>                 command history is not saved.  After a CMD session
>>>>                 ends, the history is lost (unless you install some
>>>>                 third-party tool).
>>>>
>>>>                 Perhaps there is a way to temporarily disable
>>>>                 logging of command history in the add-user-keycloak.sh?
>>>>
>>>>
>>>>>
>>>>>                     Is there another way to do this?
>>>>>
>>>>>                     The situation is even more complicated with
>>>>>                     Docker, since running the
>>>>>                     script to change the Wildfly admin password
>>>>>                     requires restarting the
>>>>>                     server, which shuts down the container. If you
>>>>>                     have an autoscaling
>>>>>                     group, the container that gets brought up is
>>>>>                     not the container where you
>>>>>                     changed the password, but instead the original
>>>>>                     container. This seems to
>>>>>                     mean that the only way to have Keycloak run in
>>>>>                     Dockers in an autoscaling
>>>>>                     group is to bake the admin passwords into the
>>>>>                     Docker image beforehand.
>>>>>                     This isn't ideal; less so if the only way to
>>>>>                     add those passwords during
>>>>>                     build time is to run the shell script that
>>>>>                     exposes the password on the
>>>>>                     command line.
>>>>>
>>>>>
>>>>>                 You need to set the password once for your
>>>>>                 database. This can be done prior to accessing the
>>>>>                 admin console the first time. Take a look at
>>>>>                 https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>>>>                 you can use docker exec to do this.
>>>>>
>>>>>
>>>>>                     --
>>>>>                     http://www.fastmail.com - Access your email
>>>>>                     from home and the web
>>>>>
>>>>>                     _______________________________________________
>>>>>                     keycloak-user mailing list
>>>>>                     keycloak-user at lists.jboss.org
>>>>>                     <mailto:keycloak-user at lists.jboss.org>
>>>>>                     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                 _______________________________________________
>>>>>                 keycloak-user mailing list
>>>>>                 keycloak-user at lists.jboss.org  <mailto:keycloak-user at lists.jboss.org>
>>>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>                 _______________________________________________
>>>>                 keycloak-user mailing list
>>>>                 keycloak-user at lists.jboss.org
>>>>                 <mailto:keycloak-user at lists.jboss.org>
>>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/2feed60d/attachment-0001.html 

From mstrukel at redhat.com  Thu Feb 18 13:12:49 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Thu, 18 Feb 2016 19:12:49 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
	<56C5EE26.8060703@redhat.com>
	<B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>
Message-ID: <CA+1OW+jkb-JB3pSmOQDQgJh+APigSUevHBVCUeYQrdHFEac4_A@mail.gmail.com>

LDAP store needs to have configuration property 'securityProtocol' set
to 'ssl' for truststore to be used.

See: https://github.com/keycloak/keycloak/blob/1.9.0.CR1/federation/ldap/src/main/java/org/keycloak/federation/ldap/idm/store/ldap/LDAPOperationManager.java#L488



On Thu, Feb 18, 2016 at 5:20 PM, Jason Axley <jaxley at expedia.com> wrote:
> Will do.
>
> This is Active Directory.
>
> -Jason
>
> From: Marek Posolda <mposolda at redhat.com>
> Date: Thursday, February 18, 2016 at 8:15 AM
>
> To: Jason Axley <jaxley at expedia.com>, "keycloak-user at lists.jboss.org"
> <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] LDAPS configuration fails "Test authentication"
>
> That's possible. Could you please create JIRA for this?
>
> Which LDAP server are you using btv? Not sure if it's related, but maybe
> yes...
>
> Thanks,
> Marek
>
> On 18/02/16 17:04, Jason Axley wrote:
>
> I got the keystore working in the keycloak-server.json config to enable SMTP
> TLS connections to Amazon SES so I know that is being picked up:
>
> "truststore": {
>
>       "file": {
>
>           "file": "${jboss.server.config.dir}/keycloak.jks",
>
>           "password": ?password",
>
>   "hostname-verification-policy": "WILDCARD",
>
>   "disabled": false
>
>       }
>
>   }
>
>
> But, this same configuration is not applied to the LDAP connections.  I
> finally got it to work by adding the Java keystore arguments to the startup:
>
> nohup ../bin/standalone.sh
> -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks
> -Djavax.net.ssl.trustStorePassword=password
>
>
> Would seem to be a bug to not apply the same keystore configuration to the
> LDAP connections?
>
> -Jason
>
> From: Marek Posolda <mposolda at redhat.com>
> Date: Wednesday, February 17, 2016 at 11:10 PM
> To: Jason Axley <jaxley at expedia.com>, "keycloak-user at lists.jboss.org"
> <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] LDAPS configuration fails "Test authentication"
>
> On 17/02/16 22:46, Jason Axley wrote:
>
> I followed some documentation like
> https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for configuring
> JBOSS to use LDAP over SSL to Active Directory but can?t seem to get
> Keycloak to honor the trust settings in the configured keystore.
>
> 2016-02-17 21:33:49,670 ERROR
> [org.keycloak.services.managers.LDAPConnectionTestManager] (default task-2)
> Error when authenticating to LDAP: simple bind failed:
> server.example.com:636: javax.naming.CommunicationException: simple bind
> failed: server.example.com:636 [Root exception is
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target]
>
>         at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>
>
> This is the configuration I?m using for the standalone server:
>
>            <security-realm name="LdapSSLRealm">
>
>                <authentication>
>
>                 <truststore
> path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"
> />
>
>                </authentication>
>
>             </security-realm>
>
>         </security-realms>
>
>         <outbound-connections>
>
>             <ldap
> name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"
> />
>
>         </outbound-connections>
>
>
> I have all of the certs in the chain imported into the keystore:
>
> keytool -list -keystore ../configuration/keycloak.jks
>
> Enter keystore password:
>
>
> Keystore type: JKS
>
> Keystore provider: SUN
>
>
> Your keystore contains 5 entries
>
>
> cert1, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1):
> D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>
> rootcert2, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1):
> 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>
> mykey, Feb 12, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1):
> 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>
> rootcert, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1):
> 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>
> intermediateu, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1):
> E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>
>
> Is there a way to find out if Keycloak/jboss is picking up this truststore
> config?  Seems that it?s not.  Any other ideas?
>
> Yes, it seems that it's not picking it. AFAIK we don't support retrieve
> truststore from the wildfly configuration of security-realm in
> standalone.xml . Maybe we should...
>
> At this moment, what should work to configure truststore is either:
> - Configure truststore SPI in keycloak-server.json. See
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
> - add system properties javax.net.ssl.trustStore and
> javax.net.ssl.trustStorePassword
>
> Marek
>
> -Jason
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.orghttps://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 jeremy at jeremysimon.com  Thu Feb 18 14:11:20 2016
From: jeremy at jeremysimon.com (Jeremy Simon)
Date: Thu, 18 Feb 2016 14:11:20 -0500
Subject: [keycloak-user] custom protocol mappers
Message-ID: <CAPFuFv_6=7J=mqT_db567+qq-DMkn0HYTJ_xQJrrK9j0mui20A@mail.gmail.com>

Hi All,

What is the best way to go about writing a custom protocol mapper?  I
hadn't seen any documentation for it.

Basically I was thinking about grabbing some multivalued attribute on
the userdetails object and mushing it into a CSV string for a SAML
attribute.

jeremy
jeremy at jeremysimon.com
www.JeremySimon.com

From bruno at abstractj.org  Thu Feb 18 14:32:11 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 18 Feb 2016 19:32:11 +0000
Subject: [keycloak-user] custom protocol mappers
In-Reply-To: <CAPFuFv_6=7J=mqT_db567+qq-DMkn0HYTJ_xQJrrK9j0mui20A@mail.gmail.com>
References: <CAPFuFv_6=7J=mqT_db567+qq-DMkn0HYTJ_xQJrrK9j0mui20A@mail.gmail.com>
Message-ID: <CAM5SUC5=yLF4HDBjmbv5VBpatTgiaZNwzXSuwPmC7SFfZFy2AQ@mail.gmail.com>

I'm not sure if it helps, but Bill answered this recently here
http://lists.jboss.org/pipermail/keycloak-user/2016-February/004890.html

On Thu, Feb 18, 2016 at 5:12 PM Jeremy Simon <jeremy at jeremysimon.com> wrote:

> Hi All,
>
> What is the best way to go about writing a custom protocol mapper?  I
> hadn't seen any documentation for it.
>
> Basically I was thinking about grabbing some multivalued attribute on
> the userdetails object and mushing it into a CSV string for a SAML
> attribute.
>
> jeremy
> jeremy at jeremysimon.com
> www.JeremySimon.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/20160218/f04f8a3e/attachment.html 

From ibaskine at microstrategy.com  Thu Feb 18 14:45:37 2016
From: ibaskine at microstrategy.com (Baskin, Ilia)
Date: Thu, 18 Feb 2016 19:45:37 +0000
Subject: [keycloak-user] Issue 1391
Message-ID: <CY1PR07MB220042571E06AA7321A5C601C4AF0@CY1PR07MB2200.namprd07.prod.outlook.com>

Hi,

This issue<https://issues.jboss.org/browse/KEYCLOAK-1391> has been fixed only for SpringSecurity adapter. Are there plans to fix it for other adapters too?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/30128075/attachment.html 

From mposolda at redhat.com  Thu Feb 18 16:17:28 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 18 Feb 2016 22:17:28 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <CA+1OW+jkb-JB3pSmOQDQgJh+APigSUevHBVCUeYQrdHFEac4_A@mail.gmail.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
	<56C5EE26.8060703@redhat.com>
	<B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>
	<CA+1OW+jkb-JB3pSmOQDQgJh+APigSUevHBVCUeYQrdHFEac4_A@mail.gmail.com>
Message-ID: <56C634E8.1070501@redhat.com>

Ah, but we're not set securityProtocol anywhere in the LDAP provider 
admin console ATM, so it can't work now. I will take a look for 1.9 and 
retest with Active Directory. Thanks Marko for pointing this.

Marek

On 18/02/16 19:12, Marko Strukelj wrote:
> LDAP store needs to have configuration property 'securityProtocol' set
> to 'ssl' for truststore to be used.
>
> See: https://github.com/keycloak/keycloak/blob/1.9.0.CR1/federation/ldap/src/main/java/org/keycloak/federation/ldap/idm/store/ldap/LDAPOperationManager.java#L488
>
>
>
> On Thu, Feb 18, 2016 at 5:20 PM, Jason Axley <jaxley at expedia.com> wrote:
>> Will do.
>>
>> This is Active Directory.
>>
>> -Jason
>>
>> From: Marek Posolda <mposolda at redhat.com>
>> Date: Thursday, February 18, 2016 at 8:15 AM
>>
>> To: Jason Axley <jaxley at expedia.com>, "keycloak-user at lists.jboss.org"
>> <keycloak-user at lists.jboss.org>
>> Subject: Re: [keycloak-user] LDAPS configuration fails "Test authentication"
>>
>> That's possible. Could you please create JIRA for this?
>>
>> Which LDAP server are you using btv? Not sure if it's related, but maybe
>> yes...
>>
>> Thanks,
>> Marek
>>
>> On 18/02/16 17:04, Jason Axley wrote:
>>
>> I got the keystore working in the keycloak-server.json config to enable SMTP
>> TLS connections to Amazon SES so I know that is being picked up:
>>
>> "truststore": {
>>
>>        "file": {
>>
>>            "file": "${jboss.server.config.dir}/keycloak.jks",
>>
>>            "password": ?password",
>>
>>    "hostname-verification-policy": "WILDCARD",
>>
>>    "disabled": false
>>
>>        }
>>
>>    }
>>
>>
>> But, this same configuration is not applied to the LDAP connections.  I
>> finally got it to work by adding the Java keystore arguments to the startup:
>>
>> nohup ../bin/standalone.sh
>> -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks
>> -Djavax.net.ssl.trustStorePassword=password
>>
>>
>> Would seem to be a bug to not apply the same keystore configuration to the
>> LDAP connections?
>>
>> -Jason
>>
>> From: Marek Posolda <mposolda at redhat.com>
>> Date: Wednesday, February 17, 2016 at 11:10 PM
>> To: Jason Axley <jaxley at expedia.com>, "keycloak-user at lists.jboss.org"
>> <keycloak-user at lists.jboss.org>
>> Subject: Re: [keycloak-user] LDAPS configuration fails "Test authentication"
>>
>> On 17/02/16 22:46, Jason Axley wrote:
>>
>> I followed some documentation like
>> https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for configuring
>> JBOSS to use LDAP over SSL to Active Directory but can?t seem to get
>> Keycloak to honor the trust settings in the configured keystore.
>>
>> 2016-02-17 21:33:49,670 ERROR
>> [org.keycloak.services.managers.LDAPConnectionTestManager] (default task-2)
>> Error when authenticating to LDAP: simple bind failed:
>> server.example.com:636: javax.naming.CommunicationException: simple bind
>> failed: server.example.com:636 [Root exception is
>> javax.net.ssl.SSLHandshakeException:
>> sun.security.validator.ValidatorException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
>> valid certification path to requested target]
>>
>>          at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>>
>>
>> This is the configuration I?m using for the standalone server:
>>
>>             <security-realm name="LdapSSLRealm">
>>
>>                 <authentication>
>>
>>                  <truststore
>> path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"
>> />
>>
>>                 </authentication>
>>
>>              </security-realm>
>>
>>          </security-realms>
>>
>>          <outbound-connections>
>>
>>              <ldap
>> name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"
>> />
>>
>>          </outbound-connections>
>>
>>
>> I have all of the certs in the chain imported into the keystore:
>>
>> keytool -list -keystore ../configuration/keycloak.jks
>>
>> Enter keystore password:
>>
>>
>> Keystore type: JKS
>>
>> Keystore provider: SUN
>>
>>
>> Your keystore contains 5 entries
>>
>>
>> cert1, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1):
>> D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>>
>> rootcert2, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1):
>> 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>>
>> mykey, Feb 12, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1):
>> 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>>
>> rootcert, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1):
>> 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>>
>> intermediateu, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1):
>> E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>>
>>
>> Is there a way to find out if Keycloak/jboss is picking up this truststore
>> config?  Seems that it?s not.  Any other ideas?
>>
>> Yes, it seems that it's not picking it. AFAIK we don't support retrieve
>> truststore from the wildfly configuration of security-realm in
>> standalone.xml . Maybe we should...
>>
>> At this moment, what should work to configure truststore is either:
>> - Configure truststore SPI in keycloak-server.json. See
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
>> - add system properties javax.net.ssl.trustStore and
>> javax.net.ssl.trustStorePassword
>>
>> Marek
>>
>> -Jason
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user


From mposolda at redhat.com  Thu Feb 18 16:24:37 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 18 Feb 2016 22:24:37 +0100
Subject: [keycloak-user] ZipException: Unsupported compression method
In-Reply-To: <56A79A3A.5080705@kroehling.de>
References: <56A79A3A.5080705@kroehling.de>
Message-ID: <56C63695.90208@redhat.com>

It's fixed in latest master and will be available in 1.9.0.Final release.

Btv. you can ignore this exception message, it doesn't have any real impact.

Marek

On 26/01/16 17:09, Juraci Paix?o Kr?hling wrote:
> We are seeing this exception "from time to time" on the logs.
> Unfortunately, I don't have much information about it, as I couldn't
> reproduce it consistently (yet), but perhaps someone has also seen this
> before? We are using KC 1.8.0.CR1.
>
> http://fpaste.org/314926/45382345/
>
> ERROR [stderr] (default task-62) java.util.zip.ZipException: Unsupported
> compression method
> ERROR [stderr] (default task-62)        at
> java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:169)
> ERROR [stderr] (default task-62)        at
> java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:79)
> ERROR [stderr] (default task-62)        at
> java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:91)
> ERROR [stderr] (default task-62)        at
> org.keycloak.common.util.Base64.decode(Base64.java:1274)
> ERROR [stderr] (default task-62)        at
> org.keycloak.common.util.Base64.decode(Base64.java:1224)
> ERROR [stderr] (default task-62)        at
> org.keycloak.common.util.Base64Url.decode(Base64Url.java:35)
> ERROR [stderr] (default task-62)        at
> org.keycloak.jose.jws.JWSInput.<init>(JWSInput.java:35)
> ERROR [stderr] (default task-62)        at
> org.keycloak.RSATokenVerifier.toAccessToken(RSATokenVerifier.java:52)
> ERROR [stderr] (default task-62)        at
> org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:22)
> ERROR [stderr] (default task-62)        at
> org.keycloak.RSATokenVerifier.verifyToken(RSATokenVerifier.java:18)
>
>
> - Juca.
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From mstrukel at redhat.com  Thu Feb 18 16:40:47 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Thu, 18 Feb 2016 22:40:47 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <56C634E8.1070501@redhat.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
	<56C5EE26.8060703@redhat.com>
	<B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>
	<CA+1OW+jkb-JB3pSmOQDQgJh+APigSUevHBVCUeYQrdHFEac4_A@mail.gmail.com>
	<56C634E8.1070501@redhat.com>
Message-ID: <CA+1OW+jMk6=qC4Cfsq9-Ef2u6o_YE_232_P_PrZ_4MMF8wam4A@mail.gmail.com>

I saw it set during my manual LDAP connectivity tests, that's why I
added this "ssl".equals(protocol) check.

But maybe it would be more appropriate to solve truststore activation
in some other way?

On Thu, Feb 18, 2016 at 10:17 PM, Marek Posolda <mposolda at redhat.com> wrote:
> Ah, but we're not set securityProtocol anywhere in the LDAP provider admin
> console ATM, so it can't work now. I will take a look for 1.9 and retest
> with Active Directory. Thanks Marko for pointing this.
>
> Marek
>
>
> On 18/02/16 19:12, Marko Strukelj wrote:
>>
>> LDAP store needs to have configuration property 'securityProtocol' set
>> to 'ssl' for truststore to be used.
>>
>> See:
>> https://github.com/keycloak/keycloak/blob/1.9.0.CR1/federation/ldap/src/main/java/org/keycloak/federation/ldap/idm/store/ldap/LDAPOperationManager.java#L488
>>
>>
>>
>> On Thu, Feb 18, 2016 at 5:20 PM, Jason Axley <jaxley at expedia.com> wrote:
>>>
>>> Will do.
>>>
>>> This is Active Directory.
>>>
>>> -Jason
>>>
>>> From: Marek Posolda <mposolda at redhat.com>
>>> Date: Thursday, February 18, 2016 at 8:15 AM
>>>
>>> To: Jason Axley <jaxley at expedia.com>, "keycloak-user at lists.jboss.org"
>>> <keycloak-user at lists.jboss.org>
>>> Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>>> authentication"
>>>
>>> That's possible. Could you please create JIRA for this?
>>>
>>> Which LDAP server are you using btv? Not sure if it's related, but maybe
>>> yes...
>>>
>>> Thanks,
>>> Marek
>>>
>>> On 18/02/16 17:04, Jason Axley wrote:
>>>
>>> I got the keystore working in the keycloak-server.json config to enable
>>> SMTP
>>> TLS connections to Amazon SES so I know that is being picked up:
>>>
>>> "truststore": {
>>>
>>>        "file": {
>>>
>>>            "file": "${jboss.server.config.dir}/keycloak.jks",
>>>
>>>            "password": ?password",
>>>
>>>    "hostname-verification-policy": "WILDCARD",
>>>
>>>    "disabled": false
>>>
>>>        }
>>>
>>>    }
>>>
>>>
>>> But, this same configuration is not applied to the LDAP connections.  I
>>> finally got it to work by adding the Java keystore arguments to the
>>> startup:
>>>
>>> nohup ../bin/standalone.sh
>>>
>>> -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks
>>> -Djavax.net.ssl.trustStorePassword=password
>>>
>>>
>>> Would seem to be a bug to not apply the same keystore configuration to
>>> the
>>> LDAP connections?
>>>
>>> -Jason
>>>
>>> From: Marek Posolda <mposolda at redhat.com>
>>> Date: Wednesday, February 17, 2016 at 11:10 PM
>>> To: Jason Axley <jaxley at expedia.com>, "keycloak-user at lists.jboss.org"
>>> <keycloak-user at lists.jboss.org>
>>> Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>>> authentication"
>>>
>>> On 17/02/16 22:46, Jason Axley wrote:
>>>
>>> I followed some documentation like
>>> https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for
>>> configuring
>>> JBOSS to use LDAP over SSL to Active Directory but can?t seem to get
>>> Keycloak to honor the trust settings in the configured keystore.
>>>
>>> 2016-02-17 21:33:49,670 ERROR
>>> [org.keycloak.services.managers.LDAPConnectionTestManager] (default
>>> task-2)
>>> Error when authenticating to LDAP: simple bind failed:
>>> server.example.com:636: javax.naming.CommunicationException: simple bind
>>> failed: server.example.com:636 [Root exception is
>>> javax.net.ssl.SSLHandshakeException:
>>> sun.security.validator.ValidatorException: PKIX path building failed:
>>> sun.security.provider.certpath.SunCertPathBuilderException: unable to
>>> find
>>> valid certification path to requested target]
>>>
>>>          at
>>> com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>>>
>>>
>>> This is the configuration I?m using for the standalone server:
>>>
>>>             <security-realm name="LdapSSLRealm">
>>>
>>>                 <authentication>
>>>
>>>                  <truststore
>>>
>>> path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"
>>> />
>>>
>>>                 </authentication>
>>>
>>>              </security-realm>
>>>
>>>          </security-realms>
>>>
>>>          <outbound-connections>
>>>
>>>              <ldap
>>>
>>> name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"
>>> />
>>>
>>>          </outbound-connections>
>>>
>>>
>>> I have all of the certs in the chain imported into the keystore:
>>>
>>> keytool -list -keystore ../configuration/keycloak.jks
>>>
>>> Enter keystore password:
>>>
>>>
>>> Keystore type: JKS
>>>
>>> Keystore provider: SUN
>>>
>>>
>>> Your keystore contains 5 entries
>>>
>>>
>>> cert1, Feb 17, 2016, trustedCertEntry,
>>>
>>> Certificate fingerprint (SHA1):
>>> D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>>>
>>> rootcert2, Feb 17, 2016, trustedCertEntry,
>>>
>>> Certificate fingerprint (SHA1):
>>> 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>>>
>>> mykey, Feb 12, 2016, trustedCertEntry,
>>>
>>> Certificate fingerprint (SHA1):
>>> 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>>>
>>> rootcert, Feb 17, 2016, trustedCertEntry,
>>>
>>> Certificate fingerprint (SHA1):
>>> 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>>>
>>> intermediateu, Feb 17, 2016, trustedCertEntry,
>>>
>>> Certificate fingerprint (SHA1):
>>> E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>>>
>>>
>>> Is there a way to find out if Keycloak/jboss is picking up this
>>> truststore
>>> config?  Seems that it?s not.  Any other ideas?
>>>
>>> Yes, it seems that it's not picking it. AFAIK we don't support retrieve
>>> truststore from the wildfly configuration of security-realm in
>>> standalone.xml . Maybe we should...
>>>
>>> At this moment, what should work to configure truststore is either:
>>> - Configure truststore SPI in keycloak-server.json. See
>>>
>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
>>> - add system properties javax.net.ssl.trustStore and
>>> javax.net.ssl.trustStorePassword
>>>
>>> Marek
>>>
>>> -Jason
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>>
>>> keycloak-user at lists.jboss.orghttps://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 jaxley at expedia.com  Thu Feb 18 16:49:55 2016
From: jaxley at expedia.com (Jason Axley)
Date: Thu, 18 Feb 2016 21:49:55 +0000
Subject: [keycloak-user] SAML attribute mapping debugging
Message-ID: <C5F62503-E003-4814-99B9-C108AE85D6D8@expedia.com>

I?ve set up incoming SAML authentication using Microsoft ADFS as the IdP.  However, the attribute mappings I?ve configured are not picking up the data.  A couple things are not clear:

  1.  How can one debug the mappings to find out why they did not find the data?
  2.  Where is the ?user model? documented to know which fields are available to map to?  I pulled out some things from existing LDAP mappings but would be nice to know what else is there to map (e.g. AD or other LDAP Groups)

For example, I?ve set up an email mapper that is configured:

Mapper Type:  Attribute Importer
Attribute Name:  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Friendly Name:  emailaddress
User Attribute Name:  email

Doesn?t work?

-Jason

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160218/79f6821d/attachment.html 

From jeremy at jeremysimon.com  Thu Feb 18 22:12:07 2016
From: jeremy at jeremysimon.com (Jeremy Simon)
Date: Thu, 18 Feb 2016 22:12:07 -0500
Subject: [keycloak-user] custom protocol mappers
In-Reply-To: <CAM5SUC5=yLF4HDBjmbv5VBpatTgiaZNwzXSuwPmC7SFfZFy2AQ@mail.gmail.com>
References: <CAPFuFv_6=7J=mqT_db567+qq-DMkn0HYTJ_xQJrrK9j0mui20A@mail.gmail.com>
	<CAM5SUC5=yLF4HDBjmbv5VBpatTgiaZNwzXSuwPmC7SFfZFy2AQ@mail.gmail.com>
Message-ID: <CAPFuFv_TkvC16oM1qFHUmLnUjYCtz-8BmB6rMkR5rzQ5Mr5auQ@mail.gmail.com>

Yes this helps.  Thank you.  ...like a goof, I searched last year's
archives but not my inbox!

jeremy
jeremy at jeremysimon.com
www.JeremySimon.com


On Thu, Feb 18, 2016 at 2:32 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> I'm not sure if it helps, but Bill answered this recently here
> http://lists.jboss.org/pipermail/keycloak-user/2016-February/004890.html
>
> On Thu, Feb 18, 2016 at 5:12 PM Jeremy Simon <jeremy at jeremysimon.com> wrote:
>>
>> Hi All,
>>
>> What is the best way to go about writing a custom protocol mapper?  I
>> hadn't seen any documentation for it.
>>
>> Basically I was thinking about grabbing some multivalued attribute on
>> the userdetails object and mushing it into a CSV string for a SAML
>> attribute.
>>
>> jeremy
>> jeremy at jeremysimon.com
>> www.JeremySimon.com
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From mposolda at redhat.com  Fri Feb 19 02:48:07 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 Feb 2016 08:48:07 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <CA+1OW+jMk6=qC4Cfsq9-Ef2u6o_YE_232_P_PrZ_4MMF8wam4A@mail.gmail.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
	<56C5EE26.8060703@redhat.com>
	<B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>
	<CA+1OW+jkb-JB3pSmOQDQgJh+APigSUevHBVCUeYQrdHFEac4_A@mail.gmail.com>
	<56C634E8.1070501@redhat.com>
	<CA+1OW+jMk6=qC4Cfsq9-Ef2u6o_YE_232_P_PrZ_4MMF8wam4A@mail.gmail.com>
Message-ID: <56C6C8B7.4040909@redhat.com>

On 18/02/16 22:40, Marko Strukelj wrote:
> I saw it set during my manual LDAP connectivity tests, that's why I
> added this "ssl".equals(protocol) check.
>
> But maybe it would be more appropriate to solve truststore activation
> in some other way?
Yeah. I am thinking about something simple like just add on/off flag 
"Use Truststore SPI" to the LDAP provider configuration. When on, it 
will use the snippet you added to set 
"org.keycloak.connections.truststore.SSLSocketFactory" .

That property "securityProtocol" is just the leftover from Picketlink, 
which wasn't never used in practice. Even Picketlink didn't use it 
AFAIR. It's fine to be removed.

Marek
>
> On Thu, Feb 18, 2016 at 10:17 PM, Marek Posolda <mposolda at redhat.com> wrote:
>> Ah, but we're not set securityProtocol anywhere in the LDAP provider admin
>> console ATM, so it can't work now. I will take a look for 1.9 and retest
>> with Active Directory. Thanks Marko for pointing this.
>>
>> Marek
>>
>>
>> On 18/02/16 19:12, Marko Strukelj wrote:
>>> LDAP store needs to have configuration property 'securityProtocol' set
>>> to 'ssl' for truststore to be used.
>>>
>>> See:
>>> https://github.com/keycloak/keycloak/blob/1.9.0.CR1/federation/ldap/src/main/java/org/keycloak/federation/ldap/idm/store/ldap/LDAPOperationManager.java#L488
>>>
>>>
>>>
>>> On Thu, Feb 18, 2016 at 5:20 PM, Jason Axley <jaxley at expedia.com> wrote:
>>>> Will do.
>>>>
>>>> This is Active Directory.
>>>>
>>>> -Jason
>>>>
>>>> From: Marek Posolda <mposolda at redhat.com>
>>>> Date: Thursday, February 18, 2016 at 8:15 AM
>>>>
>>>> To: Jason Axley <jaxley at expedia.com>, "keycloak-user at lists.jboss.org"
>>>> <keycloak-user at lists.jboss.org>
>>>> Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>>>> authentication"
>>>>
>>>> That's possible. Could you please create JIRA for this?
>>>>
>>>> Which LDAP server are you using btv? Not sure if it's related, but maybe
>>>> yes...
>>>>
>>>> Thanks,
>>>> Marek
>>>>
>>>> On 18/02/16 17:04, Jason Axley wrote:
>>>>
>>>> I got the keystore working in the keycloak-server.json config to enable
>>>> SMTP
>>>> TLS connections to Amazon SES so I know that is being picked up:
>>>>
>>>> "truststore": {
>>>>
>>>>         "file": {
>>>>
>>>>             "file": "${jboss.server.config.dir}/keycloak.jks",
>>>>
>>>>             "password": ?password",
>>>>
>>>>     "hostname-verification-policy": "WILDCARD",
>>>>
>>>>     "disabled": false
>>>>
>>>>         }
>>>>
>>>>     }
>>>>
>>>>
>>>> But, this same configuration is not applied to the LDAP connections.  I
>>>> finally got it to work by adding the Java keystore arguments to the
>>>> startup:
>>>>
>>>> nohup ../bin/standalone.sh
>>>>
>>>> -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks
>>>> -Djavax.net.ssl.trustStorePassword=password
>>>>
>>>>
>>>> Would seem to be a bug to not apply the same keystore configuration to
>>>> the
>>>> LDAP connections?
>>>>
>>>> -Jason
>>>>
>>>> From: Marek Posolda <mposolda at redhat.com>
>>>> Date: Wednesday, February 17, 2016 at 11:10 PM
>>>> To: Jason Axley <jaxley at expedia.com>, "keycloak-user at lists.jboss.org"
>>>> <keycloak-user at lists.jboss.org>
>>>> Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>>>> authentication"
>>>>
>>>> On 17/02/16 22:46, Jason Axley wrote:
>>>>
>>>> I followed some documentation like
>>>> https://developer.jboss.org/wiki/LDAPSecurityRealmExamples for
>>>> configuring
>>>> JBOSS to use LDAP over SSL to Active Directory but can?t seem to get
>>>> Keycloak to honor the trust settings in the configured keystore.
>>>>
>>>> 2016-02-17 21:33:49,670 ERROR
>>>> [org.keycloak.services.managers.LDAPConnectionTestManager] (default
>>>> task-2)
>>>> Error when authenticating to LDAP: simple bind failed:
>>>> server.example.com:636: javax.naming.CommunicationException: simple bind
>>>> failed: server.example.com:636 [Root exception is
>>>> javax.net.ssl.SSLHandshakeException:
>>>> sun.security.validator.ValidatorException: PKIX path building failed:
>>>> sun.security.provider.certpath.SunCertPathBuilderException: unable to
>>>> find
>>>> valid certification path to requested target]
>>>>
>>>>           at
>>>> com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>>>>
>>>>
>>>> This is the configuration I?m using for the standalone server:
>>>>
>>>>              <security-realm name="LdapSSLRealm">
>>>>
>>>>                  <authentication>
>>>>
>>>>                   <truststore
>>>>
>>>> path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"
>>>> />
>>>>
>>>>                  </authentication>
>>>>
>>>>               </security-realm>
>>>>
>>>>           </security-realms>
>>>>
>>>>           <outbound-connections>
>>>>
>>>>               <ldap
>>>>
>>>> name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"
>>>> />
>>>>
>>>>           </outbound-connections>
>>>>
>>>>
>>>> I have all of the certs in the chain imported into the keystore:
>>>>
>>>> keytool -list -keystore ../configuration/keycloak.jks
>>>>
>>>> Enter keystore password:
>>>>
>>>>
>>>> Keystore type: JKS
>>>>
>>>> Keystore provider: SUN
>>>>
>>>>
>>>> Your keystore contains 5 entries
>>>>
>>>>
>>>> cert1, Feb 17, 2016, trustedCertEntry,
>>>>
>>>> Certificate fingerprint (SHA1):
>>>> D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>>>>
>>>> rootcert2, Feb 17, 2016, trustedCertEntry,
>>>>
>>>> Certificate fingerprint (SHA1):
>>>> 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>>>>
>>>> mykey, Feb 12, 2016, trustedCertEntry,
>>>>
>>>> Certificate fingerprint (SHA1):
>>>> 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>>>>
>>>> rootcert, Feb 17, 2016, trustedCertEntry,
>>>>
>>>> Certificate fingerprint (SHA1):
>>>> 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>>>>
>>>> intermediateu, Feb 17, 2016, trustedCertEntry,
>>>>
>>>> Certificate fingerprint (SHA1):
>>>> E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>>>>
>>>>
>>>> Is there a way to find out if Keycloak/jboss is picking up this
>>>> truststore
>>>> config?  Seems that it?s not.  Any other ideas?
>>>>
>>>> Yes, it seems that it's not picking it. AFAIK we don't support retrieve
>>>> truststore from the wildfly configuration of security-realm in
>>>> standalone.xml . Maybe we should...
>>>>
>>>> At this moment, what should work to configure truststore is either:
>>>> - Configure truststore SPI in keycloak-server.json. See
>>>>
>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
>>>> - add system properties javax.net.ssl.trustStore and
>>>> javax.net.ssl.trustStorePassword
>>>>
>>>> Marek
>>>>
>>>> -Jason
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>>
>>>> keycloak-user at lists.jboss.orghttps://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/20160219/b8a3a388/attachment-0001.html 

From mstrukel at redhat.com  Fri Feb 19 03:42:05 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 19 Feb 2016 09:42:05 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <56C6C8B7.4040909@redhat.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
	<56C5EE26.8060703@redhat.com>
	<B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>
	<CA+1OW+jkb-JB3pSmOQDQgJh+APigSUevHBVCUeYQrdHFEac4_A@mail.gmail.com>
	<56C634E8.1070501@redhat.com>
	<CA+1OW+jMk6=qC4Cfsq9-Ef2u6o_YE_232_P_PrZ_4MMF8wam4A@mail.gmail.com>
	<56C6C8B7.4040909@redhat.com>
Message-ID: <CA+1OW+gBzD4ieN6yrHQi+s3sHsSF1Fr+L+16UaYJyuUeQzaXMQ@mail.gmail.com>

I was thinking something like truststore use be 'on' by default. Then
checking URL - if it starts with ldaps:// it means truststore
SSLSocketFactory should be set.

But not sure if that's really correct - maybe there are some other LDAP
providers that are activated by some other url scheme, not 'ldap:' /
'ldaps:'.
The switch you suggest could then be there so that truststore use can be
turned off if someone wants to delegate it to default java implementation.

On Fri, Feb 19, 2016 at 8:48 AM, Marek Posolda <mposolda at redhat.com> wrote:

> On 18/02/16 22:40, Marko Strukelj wrote:
>
> I saw it set during my manual LDAP connectivity tests, that's why I
> added this "ssl".equals(protocol) check.
>
> But maybe it would be more appropriate to solve truststore activation
> in some other way?
>
> Yeah. I am thinking about something simple like just add on/off flag "Use
> Truststore SPI" to the LDAP provider configuration. When on, it will use
> the snippet you added to set
> "org.keycloak.connections.truststore.SSLSocketFactory" .
>
> That property "securityProtocol" is just the leftover from Picketlink,
> which wasn't never used in practice. Even Picketlink didn't use it AFAIR.
> It's fine to be removed.
>
> Marek
>
>
> On Thu, Feb 18, 2016 at 10:17 PM, Marek Posolda <mposolda at redhat.com> <mposolda at redhat.com> wrote:
>
> Ah, but we're not set securityProtocol anywhere in the LDAP provider admin
> console ATM, so it can't work now. I will take a look for 1.9 and retest
> with Active Directory. Thanks Marko for pointing this.
>
> Marek
>
>
> On 18/02/16 19:12, Marko Strukelj wrote:
>
> LDAP store needs to have configuration property 'securityProtocol' set
> to 'ssl' for truststore to be used.
>
> See:https://github.com/keycloak/keycloak/blob/1.9.0.CR1/federation/ldap/src/main/java/org/keycloak/federation/ldap/idm/store/ldap/LDAPOperationManager.java#L488
>
>
>
> On Thu, Feb 18, 2016 at 5:20 PM, Jason Axley <jaxley at expedia.com> <jaxley at expedia.com> wrote:
>
> Will do.
>
> This is Active Directory.
>
> -Jason
>
> From: Marek Posolda <mposolda at redhat.com> <mposolda at redhat.com>
> Date: Thursday, February 18, 2016 at 8:15 AM
>
> To: Jason Axley <jaxley at expedia.com> <jaxley at expedia.com>, "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org><keycloak-user at lists.jboss.org> <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] LDAPS configuration fails "Test
> authentication"
>
> That's possible. Could you please create JIRA for this?
>
> Which LDAP server are you using btv? Not sure if it's related, but maybe
> yes...
>
> Thanks,
> Marek
>
> On 18/02/16 17:04, Jason Axley wrote:
>
> I got the keystore working in the keycloak-server.json config to enable
> SMTP
> TLS connections to Amazon SES so I know that is being picked up:
>
> "truststore": {
>
>        "file": {
>
>            "file": "${jboss.server.config.dir}/keycloak.jks",
>
>            "password": ?password",
>
>    "hostname-verification-policy": "WILDCARD",
>
>    "disabled": false
>
>        }
>
>    }
>
>
> But, this same configuration is not applied to the LDAP connections.  I
> finally got it to work by adding the Java keystore arguments to the
> startup:
>
> nohup ../bin/standalone.sh
>
> -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks
> -Djavax.net.ssl.trustStorePassword=password
>
>
> Would seem to be a bug to not apply the same keystore configuration to
> the
> LDAP connections?
>
> -Jason
>
> From: Marek Posolda <mposolda at redhat.com> <mposolda at redhat.com>
> Date: Wednesday, February 17, 2016 at 11:10 PM
> To: Jason Axley <jaxley at expedia.com> <jaxley at expedia.com>, "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org><keycloak-user at lists.jboss.org> <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] LDAPS configuration fails "Test
> authentication"
>
> On 17/02/16 22:46, Jason Axley wrote:
>
> I followed some documentation likehttps://developer.jboss.org/wiki/LDAPSecurityRealmExamples for
> configuring
> JBOSS to use LDAP over SSL to Active Directory but can?t seem to get
> Keycloak to honor the trust settings in the configured keystore.
>
> 2016-02-17 21:33:49,670 ERROR
> [org.keycloak.services.managers.LDAPConnectionTestManager] (default
> task-2)
> Error when authenticating to LDAP: simple bind failed:server.example.com:636: javax.naming.CommunicationException: simple bind
> failed: server.example.com:636 [Root exception is
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find
> valid certification path to requested target]
>
>          at
> com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>
>
> This is the configuration I?m using for the standalone server:
>
>             <security-realm name="LdapSSLRealm">
>
>                 <authentication>
>
>                  <truststore
>
> path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"
> />
>
>                 </authentication>
>
>              </security-realm>
>
>          </security-realms>
>
>          <outbound-connections>
>
>              <ldap
>
> name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"
> />
>
>          </outbound-connections>
>
>
> I have all of the certs in the chain imported into the keystore:
>
> keytool -list -keystore ../configuration/keycloak.jks
>
> Enter keystore password:
>
>
> Keystore type: JKS
>
> Keystore provider: SUN
>
>
> Your keystore contains 5 entries
>
>
> cert1, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1):
> D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>
> rootcert2, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1):
> 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>
> mykey, Feb 12, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1):
> 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>
> rootcert, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1):
> 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>
> intermediateu, Feb 17, 2016, trustedCertEntry,
>
> Certificate fingerprint (SHA1):
> E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>
>
> Is there a way to find out if Keycloak/jboss is picking up this
> truststore
> config?  Seems that it?s not.  Any other ideas?
>
> Yes, it seems that it's not picking it. AFAIK we don't support retrieve
> truststore from the wildfly configuration of security-realm in
> standalone.xml . Maybe we should...
>
> At this moment, what should work to configure truststore is either:
> - Configure truststore SPI in keycloak-server.json. See
> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
> - add system properties javax.net.ssl.trustStore and
> javax.net.ssl.trustStorePassword
>
> Marek
>
> -Jason
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> 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/20160219/1d5dc27d/attachment.html 

From gregor at jarisch.net  Fri Feb 19 04:33:41 2016
From: gregor at jarisch.net (Gregor Jarisch)
Date: Fri, 19 Feb 2016 10:33:41 +0100
Subject: [keycloak-user] authenticator.principal is null after successful
	authentication
Message-ID: <4173493713-26308@kerio1.zmi.at>

Hi there,

we are currently setting up keycloak (1.8.1.Final) with an application containing an embedded jetty (9.2.10.v20150310). 
Following the guidelines in the documentation, we have managed to make the authentication redirect process work.

However when the request is redirected back to our jetty (with an successful authentication), the variable "principal" of org.keycloak.adapters.jetty.core.JettyRequestAuthenticator in line 274 of org.keycloak.adapters.jetty.core.AbstractKeycloakJettyAuthenticator is null. 

We are not fully understanding the mechanism behind it, thus have difficulties understanding what we are doing wrong here. Following is our jetty embedded code. We assume that the problem must be within those lines.
Any help, insight or tip is highly appreciated!

Thank you,
Gregor? 

??? ??? ...
??? ??? final HandlerList handlers = new HandlerList();

??????? KeycloakJettyAuthenticator keycloakAuthenticator = new KeycloakJettyAuthenticator();
??????? AdapterConfig keycloakAdapterConfig = new AdapterConfig();
??????? keycloakAdapterConfig.setRealm("realm");
??????? keycloakAdapterConfig.setRealmKey("realmKEY");
??????? keycloakAdapterConfig.setAuthServerUrl("http://localhost:8080/auth");
??????? keycloakAdapterConfig.setSslRequired("none");
??????? keycloakAdapterConfig.setResource("client");
??????? keycloakAdapterConfig.setPublicClient(true);
??????? keycloakAdapterConfig.setTokenStore("cookie");

??????? keycloakAuthenticator.setAdapterConfig(keycloakAdapterConfig);

??????? ConstraintSecurityHandler security = new ConstraintSecurityHandler();
??????? server.setHandler(security);

??????? Constraint constraint = new Constraint();
??????? constraint.setName("auth");
??????? constraint.setAuthenticate(true);
??????? constraint.setRoles(new String[] { "user", "admin" });

??????? ConstraintMapping mapping = new ConstraintMapping();
??????? mapping.setPathSpec("/*");
??????? mapping.setConstraint(constraint);

??????? security.setConstraintMappings(Collections.singletonList(mapping));
??????? security.setAuthenticator(keycloakAuthenticator);

??????? handlers.addHandler(security);


??????? ServletContextHandler servletHandler = new ServletContextHandler(security, "/*", ServletContextHandler.NO_SESSIONS);
??????? handlers.addHandler(servletHandler);
??? ??? server.setHandler(handlers);
??????? ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/77589ff3/attachment.html 

From Maurice.Quaedackers at planonsoftware.com  Fri Feb 19 06:05:06 2016
From: Maurice.Quaedackers at planonsoftware.com (Maurice Quaedackers)
Date: Fri, 19 Feb 2016 12:05:06 +0100
Subject: [keycloak-user] Various login methods for one realm
Message-ID: <D2ECB572.27CE0%maurice.quaedackers@planonsoftware.com>

Hello,

We are using keycloak as an Identity Broker solution in front of our web application.

We have two options for an end-user:

 1.  User want to authenticate against a SAML IDP configured in Keycloak as an Identity Provider
 2.  User want to authenticate against keycloak username/password present in keycloak realm

Is it possible to set the Identity Provider to authenticate by default but if the user is not able to reach the configured Single Sign-On Service URL (because IDP is not available outside customer network) a fallback is given to the manual login page?

Or how can you end up at the manual (keycloak) username/password login screen when the Identity Provider has been set to authenticate by default.

I tried to find this in the manuals but I was not able to find this.

Best regards,

Maurice Quaedackers.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/d215c05f/attachment-0001.html 

From mposolda at redhat.com  Fri Feb 19 07:12:01 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 Feb 2016 13:12:01 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <CA+1OW+gBzD4ieN6yrHQi+s3sHsSF1Fr+L+16UaYJyuUeQzaXMQ@mail.gmail.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
	<56C5EE26.8060703@redhat.com>
	<B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>
	<CA+1OW+jkb-JB3pSmOQDQgJh+APigSUevHBVCUeYQrdHFEac4_A@mail.gmail.com>
	<56C634E8.1070501@redhat.com>
	<CA+1OW+jMk6=qC4Cfsq9-Ef2u6o_YE_232_P_PrZ_4MMF8wam4A@mail.gmail.com>
	<56C6C8B7.4040909@redhat.com>
	<CA+1OW+gBzD4ieN6yrHQi+s3sHsSF1Fr+L+16UaYJyuUeQzaXMQ@mail.gmail.com>
Message-ID: <56C70691.6050807@redhat.com>

On 19/02/16 09:42, Marko Strukelj wrote:
> I was thinking something like truststore use be 'on' by default. Then 
> checking URL - if it starts with ldaps:// it means truststore 
> SSLSocketFactory should be set.
>
> But not sure if that's really correct - maybe there are some other 
> LDAP providers that are activated by some other url scheme, not 
> 'ldap:' / 'ldaps:'.
> The switch you suggest could then be there so that truststore use can 
> be turned off if someone wants to delegate it to default java 
> implementation.
If it's on by default, will it work with the default java implementation 
and with "javax.net.ssl.trustStore" property? I am thinking about 
backwards compatibility. If someone used older Keycloak version and he 
set his truststore for LDAP by system property 
"|javax.net.ssl.trustStore|", then after Keycloak upgrade, the things 
won't work for him (unless he edits keycloak-server.json and configured 
truststore SPI). Is it correct assumption?

Then maybe it should be "on" by default, but LDAP providers migrated 
from previous version will still have it off? Or we can just put the 
note do migration guide.


Marek

>
> On Fri, Feb 19, 2016 at 8:48 AM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 18/02/16 22:40, Marko Strukelj wrote:
>>     I saw it set during my manual LDAP connectivity tests, that's why I
>>     added this "ssl".equals(protocol) check.
>>
>>     But maybe it would be more appropriate to solve truststore activation
>>     in some other way?
>     Yeah. I am thinking about something simple like just add on/off
>     flag "Use Truststore SPI" to the LDAP provider configuration. When
>     on, it will use the snippet you added to set
>     "org.keycloak.connections.truststore.SSLSocketFactory" .
>
>     That property "securityProtocol" is just the leftover from
>     Picketlink, which wasn't never used in practice. Even Picketlink
>     didn't use it AFAIR. It's fine to be removed.
>
>     Marek
>
>>     On Thu, Feb 18, 2016 at 10:17 PM, Marek Posolda<mposolda at redhat.com> <mailto:mposolda at redhat.com>  wrote:
>>>     Ah, but we're not set securityProtocol anywhere in the LDAP provider admin
>>>     console ATM, so it can't work now. I will take a look for 1.9 and retest
>>>     with Active Directory. Thanks Marko for pointing this.
>>>
>>>     Marek
>>>
>>>
>>>     On 18/02/16 19:12, Marko Strukelj wrote:
>>>>     LDAP store needs to have configuration property 'securityProtocol' set
>>>>     to 'ssl' for truststore to be used.
>>>>
>>>>     See:
>>>>     https://github.com/keycloak/keycloak/blob/1.9.0.CR1/federation/ldap/src/main/java/org/keycloak/federation/ldap/idm/store/ldap/LDAPOperationManager.java#L488
>>>>
>>>>
>>>>
>>>>     On Thu, Feb 18, 2016 at 5:20 PM, Jason Axley<jaxley at expedia.com> <mailto:jaxley at expedia.com>  wrote:
>>>>>     Will do.
>>>>>
>>>>>     This is Active Directory.
>>>>>
>>>>>     -Jason
>>>>>
>>>>>     From: Marek Posolda<mposolda at redhat.com> <mailto:mposolda at redhat.com>
>>>>>     Date: Thursday, February 18, 2016 at 8:15 AM
>>>>>
>>>>>     To: Jason Axley<jaxley at expedia.com> <mailto:jaxley at expedia.com>,"keycloak-user at lists.jboss.org"
>>>>>     <mailto:keycloak-user at lists.jboss.org>
>>>>>     <keycloak-user at lists.jboss.org>
>>>>>     <mailto:keycloak-user at lists.jboss.org>
>>>>>     Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>>>>>     authentication"
>>>>>
>>>>>     That's possible. Could you please create JIRA for this?
>>>>>
>>>>>     Which LDAP server are you using btv? Not sure if it's related, but maybe
>>>>>     yes...
>>>>>
>>>>>     Thanks,
>>>>>     Marek
>>>>>
>>>>>     On 18/02/16 17:04, Jason Axley wrote:
>>>>>
>>>>>     I got the keystore working in the keycloak-server.json config to enable
>>>>>     SMTP
>>>>>     TLS connections to Amazon SES so I know that is being picked up:
>>>>>
>>>>>     "truststore": {
>>>>>
>>>>>             "file": {
>>>>>
>>>>>                 "file": "${jboss.server.config.dir}/keycloak.jks",
>>>>>
>>>>>                 "password": ?password",
>>>>>
>>>>>         "hostname-verification-policy": "WILDCARD",
>>>>>
>>>>>         "disabled": false
>>>>>
>>>>>             }
>>>>>
>>>>>         }
>>>>>
>>>>>
>>>>>     But, this same configuration is not applied to the LDAP connections.  I
>>>>>     finally got it to work by adding the Java keystore arguments to the
>>>>>     startup:
>>>>>
>>>>>     nohup ../bin/standalone.sh
>>>>>
>>>>>     -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks
>>>>>     -Djavax.net.ssl.trustStorePassword=password
>>>>>
>>>>>
>>>>>     Would seem to be a bug to not apply the same keystore configuration to
>>>>>     the
>>>>>     LDAP connections?
>>>>>
>>>>>     -Jason
>>>>>
>>>>>     From: Marek Posolda<mposolda at redhat.com> <mailto:mposolda at redhat.com>
>>>>>     Date: Wednesday, February 17, 2016 at 11:10 PM
>>>>>     To: Jason Axley<jaxley at expedia.com> <mailto:jaxley at expedia.com>,"keycloak-user at lists.jboss.org"
>>>>>     <mailto:keycloak-user at lists.jboss.org>
>>>>>     <keycloak-user at lists.jboss.org>
>>>>>     <mailto:keycloak-user at lists.jboss.org>
>>>>>     Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>>>>>     authentication"
>>>>>
>>>>>     On 17/02/16 22:46, Jason Axley wrote:
>>>>>
>>>>>     I followed some documentation like
>>>>>     https://developer.jboss.org/wiki/LDAPSecurityRealmExamples  for
>>>>>     configuring
>>>>>     JBOSS to use LDAP over SSL to Active Directory but can?t seem to get
>>>>>     Keycloak to honor the trust settings in the configured keystore.
>>>>>
>>>>>     2016-02-17 21:33:49,670 ERROR
>>>>>     [org.keycloak.services.managers.LDAPConnectionTestManager] (default
>>>>>     task-2)
>>>>>     Error when authenticating to LDAP: simple bind failed:
>>>>>     server.example.com:636 <http://server.example.com:636>: javax.naming.CommunicationException: simple bind
>>>>>     failed:server.example.com:636 <http://server.example.com:636>  [Root exception is
>>>>>     javax.net.ssl.SSLHandshakeException:
>>>>>     sun.security.validator.ValidatorException: PKIX path building failed:
>>>>>     sun.security.provider.certpath.SunCertPathBuilderException: unable to
>>>>>     find
>>>>>     valid certification path to requested target]
>>>>>
>>>>>               at
>>>>>     com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>>>>>
>>>>>
>>>>>     This is the configuration I?m using for the standalone server:
>>>>>
>>>>>                  <security-realm name="LdapSSLRealm">
>>>>>
>>>>>                      <authentication>
>>>>>
>>>>>                       <truststore
>>>>>
>>>>>     path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"
>>>>>     />
>>>>>
>>>>>                      </authentication>
>>>>>
>>>>>                   </security-realm>
>>>>>
>>>>>               </security-realms>
>>>>>
>>>>>               <outbound-connections>
>>>>>
>>>>>                   <ldap
>>>>>
>>>>>     name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"
>>>>>     />
>>>>>
>>>>>               </outbound-connections>
>>>>>
>>>>>
>>>>>     I have all of the certs in the chain imported into the keystore:
>>>>>
>>>>>     keytool -list -keystore ../configuration/keycloak.jks
>>>>>
>>>>>     Enter keystore password:
>>>>>
>>>>>
>>>>>     Keystore type: JKS
>>>>>
>>>>>     Keystore provider: SUN
>>>>>
>>>>>
>>>>>     Your keystore contains 5 entries
>>>>>
>>>>>
>>>>>     cert1, Feb 17, 2016, trustedCertEntry,
>>>>>
>>>>>     Certificate fingerprint (SHA1):
>>>>>     D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>>>>>
>>>>>     rootcert2, Feb 17, 2016, trustedCertEntry,
>>>>>
>>>>>     Certificate fingerprint (SHA1):
>>>>>     86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>>>>>
>>>>>     mykey, Feb 12, 2016, trustedCertEntry,
>>>>>
>>>>>     Certificate fingerprint (SHA1):
>>>>>     20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>>>>>
>>>>>     rootcert, Feb 17, 2016, trustedCertEntry,
>>>>>
>>>>>     Certificate fingerprint (SHA1):
>>>>>     36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>>>>>
>>>>>     intermediateu, Feb 17, 2016, trustedCertEntry,
>>>>>
>>>>>     Certificate fingerprint (SHA1):
>>>>>     E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>>>>>
>>>>>
>>>>>     Is there a way to find out if Keycloak/jboss is picking up this
>>>>>     truststore
>>>>>     config?  Seems that it?s not.  Any other ideas?
>>>>>
>>>>>     Yes, it seems that it's not picking it. AFAIK we don't support retrieve
>>>>>     truststore from the wildfly configuration of security-realm in
>>>>>     standalone.xml . Maybe we should...
>>>>>
>>>>>     At this moment, what should work to configure truststore is either:
>>>>>     - Configure truststore SPI in keycloak-server.json. See
>>>>>
>>>>>     http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
>>>>>     - add system properties javax.net.ssl.trustStore and
>>>>>     javax.net.ssl.trustStorePassword
>>>>>
>>>>>     Marek
>>>>>
>>>>>     -Jason
>>>>>
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     keycloak-user mailing list
>>>>>
>>>>>     keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>     <mailto:keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     keycloak-user mailing list
>>>>>     keycloak-user at lists.jboss.org
>>>>>     <mailto:keycloak-user at lists.jboss.org>
>>>>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/95751f78/attachment.html 

From mstrukel at redhat.com  Fri Feb 19 08:06:08 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 19 Feb 2016 14:06:08 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <56C70691.6050807@redhat.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
	<56C5EE26.8060703@redhat.com>
	<B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>
	<CA+1OW+jkb-JB3pSmOQDQgJh+APigSUevHBVCUeYQrdHFEac4_A@mail.gmail.com>
	<56C634E8.1070501@redhat.com>
	<CA+1OW+jMk6=qC4Cfsq9-Ef2u6o_YE_232_P_PrZ_4MMF8wam4A@mail.gmail.com>
	<56C6C8B7.4040909@redhat.com>
	<CA+1OW+gBzD4ieN6yrHQi+s3sHsSF1Fr+L+16UaYJyuUeQzaXMQ@mail.gmail.com>
	<56C70691.6050807@redhat.com>
Message-ID: <CA+1OW+iabykmoojG=A5JLHBii3-GBoWXh_iajZJA7TVTA=Zirw@mail.gmail.com>

If truststore provider is configured, and enabled, then SSLSocketFactory
will use our custom truststore. If truststore provider is not configured it
will use the java default SSLSocketFactory.

https://github.com/keycloak/keycloak/blob/1.9.0.CR1/services/src/main/java/org/keycloak/truststore/SSLSocketFactory.java#L49

So without configuring truststore provider in keycloak-server.json the
-Djavax.net.ssl.trustStore will be honored.


On Fri, Feb 19, 2016 at 1:12 PM, Marek Posolda <mposolda at redhat.com> wrote:

> On 19/02/16 09:42, Marko Strukelj wrote:
>
> I was thinking something like truststore use be 'on' by default. Then
> checking URL - if it starts with ldaps:// it means truststore
> SSLSocketFactory should be set.
>
> But not sure if that's really correct - maybe there are some other LDAP
> providers that are activated by some other url scheme, not 'ldap:' /
> 'ldaps:'.
> The switch you suggest could then be there so that truststore use can be
> turned off if someone wants to delegate it to default java implementation.
>
> If it's on by default, will it work with the default java implementation
> and with "javax.net.ssl.trustStore" property? I am thinking about backwards
> compatibility. If someone used older Keycloak version and he set his
> truststore for LDAP by system property "javax.net.ssl.trustStore", then
> after Keycloak upgrade, the things won't work for him (unless he edits
> keycloak-server.json and configured truststore SPI). Is it correct
> assumption?
>
> Then maybe it should be "on" by default, but LDAP providers migrated from
> previous version will still have it off? Or we can just put the note do
> migration guide.
>
>
> Marek
>
>
>
> On Fri, Feb 19, 2016 at 8:48 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
>
>> On 18/02/16 22:40, Marko Strukelj wrote:
>>
>> I saw it set during my manual LDAP connectivity tests, that's why I
>> added this "ssl".equals(protocol) check.
>>
>> But maybe it would be more appropriate to solve truststore activation
>> in some other way?
>>
>> Yeah. I am thinking about something simple like just add on/off flag "Use
>> Truststore SPI" to the LDAP provider configuration. When on, it will use
>> the snippet you added to set
>> "org.keycloak.connections.truststore.SSLSocketFactory" .
>>
>> That property "securityProtocol" is just the leftover from Picketlink,
>> which wasn't never used in practice. Even Picketlink didn't use it AFAIR.
>> It's fine to be removed.
>>
>> Marek
>>
>> On Thu, Feb 18, 2016 at 10:17 PM, Marek Posolda <mposolda at redhat.com> <mposolda at redhat.com> wrote:
>>
>> Ah, but we're not set securityProtocol anywhere in the LDAP provider admin
>> console ATM, so it can't work now. I will take a look for 1.9 and retest
>> with Active Directory. Thanks Marko for pointing this.
>>
>> Marek
>>
>>
>> On 18/02/16 19:12, Marko Strukelj wrote:
>>
>> LDAP store needs to have configuration property 'securityProtocol' set
>> to 'ssl' for truststore to be used.
>>
>> See:https://github.com/keycloak/keycloak/blob/1.9.0.CR1/federation/ldap/src/main/java/org/keycloak/federation/ldap/idm/store/ldap/LDAPOperationManager.java#L488
>>
>>
>>
>> On Thu, Feb 18, 2016 at 5:20 PM, Jason Axley <jaxley at expedia.com> <jaxley at expedia.com> wrote:
>>
>> Will do.
>>
>> This is Active Directory.
>>
>> -Jason
>>
>> From: Marek Posolda <mposolda at redhat.com> <mposolda at redhat.com>
>> Date: Thursday, February 18, 2016 at 8:15 AM
>>
>> To: Jason Axley <jaxley at expedia.com> <jaxley at expedia.com>, "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org><keycloak-user at lists.jboss.org> <keycloak-user at lists.jboss.org>
>> Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>> authentication"
>>
>> That's possible. Could you please create JIRA for this?
>>
>> Which LDAP server are you using btv? Not sure if it's related, but maybe
>> yes...
>>
>> Thanks,
>> Marek
>>
>> On 18/02/16 17:04, Jason Axley wrote:
>>
>> I got the keystore working in the keycloak-server.json config to enable
>> SMTP
>> TLS connections to Amazon SES so I know that is being picked up:
>>
>> "truststore": {
>>
>>        "file": {
>>
>>            "file": "${jboss.server.config.dir}/keycloak.jks",
>>
>>            "password": ?password",
>>
>>    "hostname-verification-policy": "WILDCARD",
>>
>>    "disabled": false
>>
>>        }
>>
>>    }
>>
>>
>> But, this same configuration is not applied to the LDAP connections.  I
>> finally got it to work by adding the Java keystore arguments to the
>> startup:
>>
>> nohup ../bin/standalone.sh
>>
>> -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks
>> -Djavax.net.ssl.trustStorePassword=password
>>
>>
>> Would seem to be a bug to not apply the same keystore configuration to
>> the
>> LDAP connections?
>>
>> -Jason
>>
>> From: Marek Posolda <mposolda at redhat.com> <mposolda at redhat.com>
>> Date: Wednesday, February 17, 2016 at 11:10 PM
>> To: Jason Axley <jaxley at expedia.com> <jaxley at expedia.com>, "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org><keycloak-user at lists.jboss.org> <keycloak-user at lists.jboss.org>
>> Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>> authentication"
>>
>> On 17/02/16 22:46, Jason Axley wrote:
>>
>> I followed some documentation likehttps://developer.jboss.org/wiki/LDAPSecurityRealmExamples for
>> configuring
>> JBOSS to use LDAP over SSL to Active Directory but can?t seem to get
>> Keycloak to honor the trust settings in the configured keystore.
>>
>> 2016-02-17 21:33:49,670 ERROR
>> [org.keycloak.services.managers.LDAPConnectionTestManager] (default
>> task-2)
>> Error when authenticating to LDAP: simple bind failed:server.example.com:636: javax.naming.CommunicationException: simple bind
>> failed: server.example.com:636 [Root exception is
>> javax.net.ssl.SSLHandshakeException:
>> sun.security.validator.ValidatorException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to
>> find
>> valid certification path to requested target]
>>
>>          at
>> com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>>
>>
>> This is the configuration I?m using for the standalone server:
>>
>>             <security-realm name="LdapSSLRealm">
>>
>>                 <authentication>
>>
>>                  <truststore
>>
>> path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"
>> />
>>
>>                 </authentication>
>>
>>              </security-realm>
>>
>>          </security-realms>
>>
>>          <outbound-connections>
>>
>>              <ldap
>>
>> name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"
>> />
>>
>>          </outbound-connections>
>>
>>
>> I have all of the certs in the chain imported into the keystore:
>>
>> keytool -list -keystore ../configuration/keycloak.jks
>>
>> Enter keystore password:
>>
>>
>> Keystore type: JKS
>>
>> Keystore provider: SUN
>>
>>
>> Your keystore contains 5 entries
>>
>>
>> cert1, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1):
>> D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>>
>> rootcert2, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1):
>> 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>>
>> mykey, Feb 12, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1):
>> 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>>
>> rootcert, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1):
>> 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>>
>> intermediateu, Feb 17, 2016, trustedCertEntry,
>>
>> Certificate fingerprint (SHA1):
>> E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>>
>>
>> Is there a way to find out if Keycloak/jboss is picking up this
>> truststore
>> config?  Seems that it?s not.  Any other ideas?
>>
>> Yes, it seems that it's not picking it. AFAIK we don't support retrieve
>> truststore from the wildfly configuration of security-realm in
>> standalone.xml . Maybe we should...
>>
>> At this moment, what should work to configure truststore is either:
>> - Configure truststore SPI in keycloak-server.json. See
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
>> - add system properties javax.net.ssl.trustStore and
>> javax.net.ssl.trustStorePassword
>>
>> Marek
>>
>> -Jason
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>>
>> _______________________________________________
>> 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/20160219/20cfdcb4/attachment-0001.html 

From mposolda at redhat.com  Fri Feb 19 08:21:40 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 Feb 2016 14:21:40 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <CA+1OW+iabykmoojG=A5JLHBii3-GBoWXh_iajZJA7TVTA=Zirw@mail.gmail.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
	<56C5EE26.8060703@redhat.com>
	<B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>
	<CA+1OW+jkb-JB3pSmOQDQgJh+APigSUevHBVCUeYQrdHFEac4_A@mail.gmail.com>
	<56C634E8.1070501@redhat.com>
	<CA+1OW+jMk6=qC4Cfsq9-Ef2u6o_YE_232_P_PrZ_4MMF8wam4A@mail.gmail.com>
	<56C6C8B7.4040909@redhat.com>
	<CA+1OW+gBzD4ieN6yrHQi+s3sHsSF1Fr+L+16UaYJyuUeQzaXMQ@mail.gmail.com>
	<56C70691.6050807@redhat.com>
	<CA+1OW+iabykmoojG=A5JLHBii3-GBoWXh_iajZJA7TVTA=Zirw@mail.gmail.com>
Message-ID: <56C716E4.1040600@redhat.com>

Thanks Marko. So we don't need to care about migration then, but put it 
"on" even for migrated from previous version.

Marek

On 19/02/16 14:06, Marko Strukelj wrote:
> If truststore provider is configured, and enabled, then 
> SSLSocketFactory will use our custom truststore. If truststore 
> provider is not configured it will use the java default SSLSocketFactory.
>
> https://github.com/keycloak/keycloak/blob/1.9.0.CR1/services/src/main/java/org/keycloak/truststore/SSLSocketFactory.java#L49
>
> So without configuring truststore provider in keycloak-server.json the 
> -Djavax.net.ssl.trustStore will be honored.
>
>
> On Fri, Feb 19, 2016 at 1:12 PM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 19/02/16 09:42, Marko Strukelj wrote:
>>     I was thinking something like truststore use be 'on' by default.
>>     Then checking URL - if it starts with ldaps:// it means
>>     truststore SSLSocketFactory should be set.
>>
>>     But not sure if that's really correct - maybe there are some
>>     other LDAP providers that are activated by some other url scheme,
>>     not 'ldap:' / 'ldaps:'.
>>     The switch you suggest could then be there so that truststore use
>>     can be turned off if someone wants to delegate it to default java
>>     implementation.
>     If it's on by default, will it work with the default java
>     implementation and with "javax.net.ssl.trustStore" property? I am
>     thinking about backwards compatibility. If someone used older
>     Keycloak version and he set his truststore for LDAP by system
>     property "|javax.net.ssl.trustStore|", then after Keycloak
>     upgrade, the things won't work for him (unless he edits
>     keycloak-server.json and configured truststore SPI). Is it correct
>     assumption?
>
>     Then maybe it should be "on" by default, but LDAP providers
>     migrated from previous version will still have it off? Or we can
>     just put the note do migration guide.
>
>
>     Marek
>
>
>>
>>     On Fri, Feb 19, 2016 at 8:48 AM, Marek Posolda
>>     <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>
>>         On 18/02/16 22:40, Marko Strukelj wrote:
>>>         I saw it set during my manual LDAP connectivity tests, that's why I
>>>         added this "ssl".equals(protocol) check.
>>>
>>>         But maybe it would be more appropriate to solve truststore activation
>>>         in some other way?
>>         Yeah. I am thinking about something simple like just add
>>         on/off flag "Use Truststore SPI" to the LDAP provider
>>         configuration. When on, it will use the snippet you added to
>>         set "org.keycloak.connections.truststore.SSLSocketFactory" .
>>
>>         That property "securityProtocol" is just the leftover from
>>         Picketlink, which wasn't never used in practice. Even
>>         Picketlink didn't use it AFAIR. It's fine to be removed.
>>
>>         Marek
>>
>>>         On Thu, Feb 18, 2016 at 10:17 PM, Marek Posolda<mposolda at redhat.com> <mailto:mposolda at redhat.com>  wrote:
>>>>         Ah, but we're not set securityProtocol anywhere in the LDAP provider admin
>>>>         console ATM, so it can't work now. I will take a look for 1.9 and retest
>>>>         with Active Directory. Thanks Marko for pointing this.
>>>>
>>>>         Marek
>>>>
>>>>
>>>>         On 18/02/16 19:12, Marko Strukelj wrote:
>>>>>         LDAP store needs to have configuration property 'securityProtocol' set
>>>>>         to 'ssl' for truststore to be used.
>>>>>
>>>>>         See:
>>>>>         https://github.com/keycloak/keycloak/blob/1.9.0.CR1/federation/ldap/src/main/java/org/keycloak/federation/ldap/idm/store/ldap/LDAPOperationManager.java#L488
>>>>>
>>>>>
>>>>>
>>>>>         On Thu, Feb 18, 2016 at 5:20 PM, Jason Axley<jaxley at expedia.com> <mailto:jaxley at expedia.com>  wrote:
>>>>>>         Will do.
>>>>>>
>>>>>>         This is Active Directory.
>>>>>>
>>>>>>         -Jason
>>>>>>
>>>>>>         From: Marek Posolda<mposolda at redhat.com> <mailto:mposolda at redhat.com>
>>>>>>         Date: Thursday, February 18, 2016 at 8:15 AM
>>>>>>
>>>>>>         To: Jason Axley<jaxley at expedia.com> <mailto:jaxley at expedia.com>,"keycloak-user at lists.jboss.org"
>>>>>>         <mailto:keycloak-user at lists.jboss.org>
>>>>>>         <keycloak-user at lists.jboss.org>
>>>>>>         <mailto:keycloak-user at lists.jboss.org>
>>>>>>         Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>>>>>>         authentication"
>>>>>>
>>>>>>         That's possible. Could you please create JIRA for this?
>>>>>>
>>>>>>         Which LDAP server are you using btv? Not sure if it's related, but maybe
>>>>>>         yes...
>>>>>>
>>>>>>         Thanks,
>>>>>>         Marek
>>>>>>
>>>>>>         On 18/02/16 17:04, Jason Axley wrote:
>>>>>>
>>>>>>         I got the keystore working in the keycloak-server.json config to enable
>>>>>>         SMTP
>>>>>>         TLS connections to Amazon SES so I know that is being picked up:
>>>>>>
>>>>>>         "truststore": {
>>>>>>
>>>>>>                 "file": {
>>>>>>
>>>>>>                     "file": "${jboss.server.config.dir}/keycloak.jks",
>>>>>>
>>>>>>                     "password": ?password",
>>>>>>
>>>>>>             "hostname-verification-policy": "WILDCARD",
>>>>>>
>>>>>>             "disabled": false
>>>>>>
>>>>>>                 }
>>>>>>
>>>>>>             }
>>>>>>
>>>>>>
>>>>>>         But, this same configuration is not applied to the LDAP connections.  I
>>>>>>         finally got it to work by adding the Java keystore arguments to the
>>>>>>         startup:
>>>>>>
>>>>>>         nohup ../bin/standalone.sh
>>>>>>
>>>>>>         -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks
>>>>>>         -Djavax.net.ssl.trustStorePassword=password
>>>>>>
>>>>>>
>>>>>>         Would seem to be a bug to not apply the same keystore configuration to
>>>>>>         the
>>>>>>         LDAP connections?
>>>>>>
>>>>>>         -Jason
>>>>>>
>>>>>>         From: Marek Posolda<mposolda at redhat.com> <mailto:mposolda at redhat.com>
>>>>>>         Date: Wednesday, February 17, 2016 at 11:10 PM
>>>>>>         To: Jason Axley<jaxley at expedia.com> <mailto:jaxley at expedia.com>,"keycloak-user at lists.jboss.org"
>>>>>>         <mailto:keycloak-user at lists.jboss.org>
>>>>>>         <keycloak-user at lists.jboss.org>
>>>>>>         <mailto:keycloak-user at lists.jboss.org>
>>>>>>         Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>>>>>>         authentication"
>>>>>>
>>>>>>         On 17/02/16 22:46, Jason Axley wrote:
>>>>>>
>>>>>>         I followed some documentation like
>>>>>>         https://developer.jboss.org/wiki/LDAPSecurityRealmExamples  for
>>>>>>         configuring
>>>>>>         JBOSS to use LDAP over SSL to Active Directory but can?t seem to get
>>>>>>         Keycloak to honor the trust settings in the configured keystore.
>>>>>>
>>>>>>         2016-02-17 21:33:49,670 ERROR
>>>>>>         [org.keycloak.services.managers.LDAPConnectionTestManager] (default
>>>>>>         task-2)
>>>>>>         Error when authenticating to LDAP: simple bind failed:
>>>>>>         server.example.com:636 <http://server.example.com:636>: javax.naming.CommunicationException: simple bind
>>>>>>         failed:server.example.com:636 <http://server.example.com:636>  [Root exception is
>>>>>>         javax.net.ssl.SSLHandshakeException:
>>>>>>         sun.security.validator.ValidatorException: PKIX path building failed:
>>>>>>         sun.security.provider.certpath.SunCertPathBuilderException: unable to
>>>>>>         find
>>>>>>         valid certification path to requested target]
>>>>>>
>>>>>>                   at
>>>>>>         com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>>>>>>
>>>>>>
>>>>>>         This is the configuration I?m using for the standalone server:
>>>>>>
>>>>>>                      <security-realm name="LdapSSLRealm">
>>>>>>
>>>>>>                          <authentication>
>>>>>>
>>>>>>                           <truststore
>>>>>>
>>>>>>         path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"
>>>>>>         />
>>>>>>
>>>>>>                          </authentication>
>>>>>>
>>>>>>                       </security-realm>
>>>>>>
>>>>>>                   </security-realms>
>>>>>>
>>>>>>                   <outbound-connections>
>>>>>>
>>>>>>                       <ldap
>>>>>>
>>>>>>         name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"
>>>>>>         />
>>>>>>
>>>>>>                   </outbound-connections>
>>>>>>
>>>>>>
>>>>>>         I have all of the certs in the chain imported into the keystore:
>>>>>>
>>>>>>         keytool -list -keystore ../configuration/keycloak.jks
>>>>>>
>>>>>>         Enter keystore password:
>>>>>>
>>>>>>
>>>>>>         Keystore type: JKS
>>>>>>
>>>>>>         Keystore provider: SUN
>>>>>>
>>>>>>
>>>>>>         Your keystore contains 5 entries
>>>>>>
>>>>>>
>>>>>>         cert1, Feb 17, 2016, trustedCertEntry,
>>>>>>
>>>>>>         Certificate fingerprint (SHA1):
>>>>>>         D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>>>>>>
>>>>>>         rootcert2, Feb 17, 2016, trustedCertEntry,
>>>>>>
>>>>>>         Certificate fingerprint (SHA1):
>>>>>>         86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>>>>>>
>>>>>>         mykey, Feb 12, 2016, trustedCertEntry,
>>>>>>
>>>>>>         Certificate fingerprint (SHA1):
>>>>>>         20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>>>>>>
>>>>>>         rootcert, Feb 17, 2016, trustedCertEntry,
>>>>>>
>>>>>>         Certificate fingerprint (SHA1):
>>>>>>         36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>>>>>>
>>>>>>         intermediateu, Feb 17, 2016, trustedCertEntry,
>>>>>>
>>>>>>         Certificate fingerprint (SHA1):
>>>>>>         E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>>>>>>
>>>>>>
>>>>>>         Is there a way to find out if Keycloak/jboss is picking up this
>>>>>>         truststore
>>>>>>         config?  Seems that it?s not.  Any other ideas?
>>>>>>
>>>>>>         Yes, it seems that it's not picking it. AFAIK we don't support retrieve
>>>>>>         truststore from the wildfly configuration of security-realm in
>>>>>>         standalone.xml . Maybe we should...
>>>>>>
>>>>>>         At this moment, what should work to configure truststore is either:
>>>>>>         - Configure truststore SPI in keycloak-server.json. See
>>>>>>
>>>>>>         http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
>>>>>>         - add system properties javax.net.ssl.trustStore and
>>>>>>         javax.net.ssl.trustStorePassword
>>>>>>
>>>>>>         Marek
>>>>>>
>>>>>>         -Jason
>>>>>>
>>>>>>
>>>>>>
>>>>>>         _______________________________________________
>>>>>>         keycloak-user mailing list
>>>>>>
>>>>>>         keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>         <mailto:keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>         _______________________________________________
>>>>>>         keycloak-user mailing list
>>>>>>         keycloak-user at lists.jboss.org
>>>>>>         <mailto:keycloak-user at lists.jboss.org>
>>>>>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/a3f025c8/attachment.html 

From mstrukel at redhat.com  Fri Feb 19 08:27:57 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 19 Feb 2016 14:27:57 +0100
Subject: [keycloak-user] LDAPS configuration fails "Test authentication"
In-Reply-To: <56C716E4.1040600@redhat.com>
References: <73069D77-A2F8-418C-BBC6-522938C1E4A2@expedia.com>
	<56C56E54.8040901@redhat.com>
	<7237EFC8-93C7-400D-BAB7-545A5850F950@expedia.com>
	<56C5EE26.8060703@redhat.com>
	<B4A03AA9-8784-4C8B-8923-9DFA7E104B65@expedia.com>
	<CA+1OW+jkb-JB3pSmOQDQgJh+APigSUevHBVCUeYQrdHFEac4_A@mail.gmail.com>
	<56C634E8.1070501@redhat.com>
	<CA+1OW+jMk6=qC4Cfsq9-Ef2u6o_YE_232_P_PrZ_4MMF8wam4A@mail.gmail.com>
	<56C6C8B7.4040909@redhat.com>
	<CA+1OW+gBzD4ieN6yrHQi+s3sHsSF1Fr+L+16UaYJyuUeQzaXMQ@mail.gmail.com>
	<56C70691.6050807@redhat.com>
	<CA+1OW+iabykmoojG=A5JLHBii3-GBoWXh_iajZJA7TVTA=Zirw@mail.gmail.com>
	<56C716E4.1040600@redhat.com>
Message-ID: <CA+1OW+g2XYAEfskHrR+6vAOfutNFCURksmXWAd0oT5ryxHX-FA@mail.gmail.com>

I think so, yes.

On Fri, Feb 19, 2016 at 2:21 PM, Marek Posolda <mposolda at redhat.com> wrote:

> Thanks Marko. So we don't need to care about migration then, but put it
> "on" even for migrated from previous version.
>
> Marek
>
>
> On 19/02/16 14:06, Marko Strukelj wrote:
>
> If truststore provider is configured, and enabled, then SSLSocketFactory
> will use our custom truststore. If truststore provider is not configured it
> will use the java default SSLSocketFactory.
>
>
> https://github.com/keycloak/keycloak/blob/1.9.0.CR1/services/src/main/java/org/keycloak/truststore/SSLSocketFactory.java#L49
>
> So without configuring truststore provider in keycloak-server.json the
> -Djavax.net.ssl.trustStore will be honored.
>
>
> On Fri, Feb 19, 2016 at 1:12 PM, Marek Posolda <mposolda at redhat.com>
> wrote:
>
>> On 19/02/16 09:42, Marko Strukelj wrote:
>>
>> I was thinking something like truststore use be 'on' by default. Then
>> checking URL - if it starts with ldaps:// it means truststore
>> SSLSocketFactory should be set.
>>
>> But not sure if that's really correct - maybe there are some other LDAP
>> providers that are activated by some other url scheme, not 'ldap:' /
>> 'ldaps:'.
>> The switch you suggest could then be there so that truststore use can be
>> turned off if someone wants to delegate it to default java implementation.
>>
>> If it's on by default, will it work with the default java implementation
>> and with "javax.net.ssl.trustStore" property? I am thinking about backwards
>> compatibility. If someone used older Keycloak version and he set his
>> truststore for LDAP by system property "javax.net.ssl.trustStore", then
>> after Keycloak upgrade, the things won't work for him (unless he edits
>> keycloak-server.json and configured truststore SPI). Is it correct
>> assumption?
>>
>> Then maybe it should be "on" by default, but LDAP providers migrated from
>> previous version will still have it off? Or we can just put the note do
>> migration guide.
>>
>>
>> Marek
>>
>>
>>
>> On Fri, Feb 19, 2016 at 8:48 AM, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> On 18/02/16 22:40, Marko Strukelj wrote:
>>>
>>> I saw it set during my manual LDAP connectivity tests, that's why I
>>> added this "ssl".equals(protocol) check.
>>>
>>> But maybe it would be more appropriate to solve truststore activation
>>> in some other way?
>>>
>>> Yeah. I am thinking about something simple like just add on/off flag
>>> "Use Truststore SPI" to the LDAP provider configuration. When on, it will
>>> use the snippet you added to set
>>> "org.keycloak.connections.truststore.SSLSocketFactory" .
>>>
>>> That property "securityProtocol" is just the leftover from Picketlink,
>>> which wasn't never used in practice. Even Picketlink didn't use it AFAIR.
>>> It's fine to be removed.
>>>
>>> Marek
>>>
>>> On Thu, Feb 18, 2016 at 10:17 PM, Marek Posolda <mposolda at redhat.com> <mposolda at redhat.com> wrote:
>>>
>>> Ah, but we're not set securityProtocol anywhere in the LDAP provider admin
>>> console ATM, so it can't work now. I will take a look for 1.9 and retest
>>> with Active Directory. Thanks Marko for pointing this.
>>>
>>> Marek
>>>
>>>
>>> On 18/02/16 19:12, Marko Strukelj wrote:
>>>
>>> LDAP store needs to have configuration property 'securityProtocol' set
>>> to 'ssl' for truststore to be used.
>>>
>>> See:https://github.com/keycloak/keycloak/blob/1.9.0.CR1/federation/ldap/src/main/java/org/keycloak/federation/ldap/idm/store/ldap/LDAPOperationManager.java#L488
>>>
>>>
>>>
>>> On Thu, Feb 18, 2016 at 5:20 PM, Jason Axley <jaxley at expedia.com> <jaxley at expedia.com> wrote:
>>>
>>> Will do.
>>>
>>> This is Active Directory.
>>>
>>> -Jason
>>>
>>> From: Marek Posolda <mposolda at redhat.com> <mposolda at redhat.com>
>>> Date: Thursday, February 18, 2016 at 8:15 AM
>>>
>>> To: Jason Axley <jaxley at expedia.com> <jaxley at expedia.com>, "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org><keycloak-user at lists.jboss.org> <keycloak-user at lists.jboss.org>
>>> Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>>> authentication"
>>>
>>> That's possible. Could you please create JIRA for this?
>>>
>>> Which LDAP server are you using btv? Not sure if it's related, but maybe
>>> yes...
>>>
>>> Thanks,
>>> Marek
>>>
>>> On 18/02/16 17:04, Jason Axley wrote:
>>>
>>> I got the keystore working in the keycloak-server.json config to enable
>>> SMTP
>>> TLS connections to Amazon SES so I know that is being picked up:
>>>
>>> "truststore": {
>>>
>>>        "file": {
>>>
>>>            "file": "${jboss.server.config.dir}/keycloak.jks",
>>>
>>>            "password": ?password",
>>>
>>>    "hostname-verification-policy": "WILDCARD",
>>>
>>>    "disabled": false
>>>
>>>        }
>>>
>>>    }
>>>
>>>
>>> But, this same configuration is not applied to the LDAP connections.  I
>>> finally got it to work by adding the Java keystore arguments to the
>>> startup:
>>>
>>> nohup ../bin/standalone.sh
>>>
>>> -Djavax.net.ssl.trustStore=/opt/keycloak/keycloak-1.8.1.Final/standalone/configuration/keycloak.jks
>>> -Djavax.net.ssl.trustStorePassword=password
>>>
>>>
>>> Would seem to be a bug to not apply the same keystore configuration to
>>> the
>>> LDAP connections?
>>>
>>> -Jason
>>>
>>> From: Marek Posolda <mposolda at redhat.com> <mposolda at redhat.com>
>>> Date: Wednesday, February 17, 2016 at 11:10 PM
>>> To: Jason Axley <jaxley at expedia.com> <jaxley at expedia.com>, "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org><keycloak-user at lists.jboss.org> <keycloak-user at lists.jboss.org>
>>> Subject: Re: [keycloak-user] LDAPS configuration fails "Test
>>> authentication"
>>>
>>> On 17/02/16 22:46, Jason Axley wrote:
>>>
>>> I followed some documentation likehttps://developer.jboss.org/wiki/LDAPSecurityRealmExamples for
>>> configuring
>>> JBOSS to use LDAP over SSL to Active Directory but can?t seem to get
>>> Keycloak to honor the trust settings in the configured keystore.
>>>
>>> 2016-02-17 21:33:49,670 ERROR
>>> [org.keycloak.services.managers.LDAPConnectionTestManager] (default
>>> task-2)
>>> Error when authenticating to LDAP: simple bind failed:server.example.com:636: javax.naming.CommunicationException: simple bind
>>> failed: server.example.com:636 [Root exception is
>>> javax.net.ssl.SSLHandshakeException:
>>> sun.security.validator.ValidatorException: PKIX path building failed:
>>> sun.security.provider.certpath.SunCertPathBuilderException: unable to
>>> find
>>> valid certification path to requested target]
>>>
>>>          at
>>> com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
>>>
>>>
>>> This is the configuration I?m using for the standalone server:
>>>
>>>             <security-realm name="LdapSSLRealm">
>>>
>>>                 <authentication>
>>>
>>>                  <truststore
>>>
>>> path="keycloak.jks"relative-to="jboss.server.config.dir"keystore-password=?password"
>>> />
>>>
>>>                 </authentication>
>>>
>>>              </security-realm>
>>>
>>>          </security-realms>
>>>
>>>          <outbound-connections>
>>>
>>>              <ldap
>>>
>>> name=?AD"url="ldaps://server.example.com:636"security-realm="LdapSSLRealm"
>>> />
>>>
>>>          </outbound-connections>
>>>
>>>
>>> I have all of the certs in the chain imported into the keystore:
>>>
>>> keytool -list -keystore ../configuration/keycloak.jks
>>>
>>> Enter keystore password:
>>>
>>>
>>> Keystore type: JKS
>>>
>>> Keystore provider: SUN
>>>
>>>
>>> Your keystore contains 5 entries
>>>
>>>
>>> cert1, Feb 17, 2016, trustedCertEntry,
>>>
>>> Certificate fingerprint (SHA1):
>>> D5:BA:F5:07:21:7D:71:AA:F6:9B:53:41:C1:05:0C:48:A9:3F:57:CE
>>>
>>> rootcert2, Feb 17, 2016, trustedCertEntry,
>>>
>>> Certificate fingerprint (SHA1):
>>> 86:70:AB:0A:96:58:4D:73:C0:D5:13:A8:4D:B3:1D:EC:08:D7:7B:1A
>>>
>>> mykey, Feb 12, 2016, trustedCertEntry,
>>>
>>> Certificate fingerprint (SHA1):
>>> 20:8C:D9:BD:B7:75:12:53:F8:68:04:82:48:5C:D7:70:F5:6C:28:15
>>>
>>> rootcert, Feb 17, 2016, trustedCertEntry,
>>>
>>> Certificate fingerprint (SHA1):
>>> 36:28:1E:74:E0:A9:6E:0F:53:99:75:DA:62:20:24:D4:F6:34:CD:BD
>>>
>>> intermediateu, Feb 17, 2016, trustedCertEntry,
>>>
>>> Certificate fingerprint (SHA1):
>>> E9:66:EE:CF:79:6A:C1:D0:13:18:59:9C:B4:29:08:54:DF:91:27:2D
>>>
>>>
>>> Is there a way to find out if Keycloak/jboss is picking up this
>>> truststore
>>> config?  Seems that it?s not.  Any other ideas?
>>>
>>> Yes, it seems that it's not picking it. AFAIK we don't support retrieve
>>> truststore from the wildfly configuration of security-realm in
>>> standalone.xml . Maybe we should...
>>>
>>> At this moment, what should work to configure truststore is either:
>>> - Configure truststore SPI in keycloak-server.json. See
>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e231
>>> - add system properties javax.net.ssl.trustStore and
>>> javax.net.ssl.trustStorePassword
>>>
>>> Marek
>>>
>>> -Jason
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20160219/83fe3542/attachment-0001.html 

From jrevillard at gnubila.fr  Fri Feb 19 08:41:23 2016
From: jrevillard at gnubila.fr (=?UTF-8?B?SsOpcsO0bWUgUmV2aWxsYXJk?=)
Date: Fri, 19 Feb 2016 14:41:23 +0100
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <56C44938.30507@gnubila.fr>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
	<56C44938.30507@gnubila.fr>
Message-ID: <56C71B83.80201@gnubila.fr>

Any advise for this please ?

Best,
Jerome

Le 17/02/2016 11:19, J?r?me Revillard a ?crit :
> Yes, it seems to be the case for the server, but not for the clients. 
> See the trustore config description here: 
> https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>
> Best,
> Jerome
>
> Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
>> I'm not sure if I got your question in the right way. But from my 
>> understanding Java truststore is the standard fall back.
>>
>> See item 3.2.5 
>> https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
>>
>> On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard 
>> <jrevillard at gnubila.fr <mailto:jrevillard at gnubila.fr>> wrote:
>>
>>     Dear all,
>>
>>     I'm testing now a Keycloak server properly configured with https
>>     configuration.
>>     The server certificate is one which is already known by the
>>     default java
>>     trustore.
>>     Would it be possible to setup the keycloak.json adapter config to use
>>     this default java trustore ?
>>
>>     Best,
>>     Jerome
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/4893d70c/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3908 bytes
Desc: Signature cryptographique S/MIME
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/4893d70c/attachment.bin 

From jeremy at jeremysimon.com  Fri Feb 19 09:10:28 2016
From: jeremy at jeremysimon.com (Jeremy Simon)
Date: Fri, 19 Feb 2016 09:10:28 -0500
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <56C71B83.80201@gnubila.fr>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
	<56C44938.30507@gnubila.fr> <56C71B83.80201@gnubila.fr>
Message-ID: <CAPFuFv9DRx6kbdhS45eSBEHxt1XxKXfa1pCopQtOAnESuC=V_Q@mail.gmail.com>

Hey there,

I had asked about this a while ago too.  Far as I know, the current
implementation uses the jks for the HTTPS communication only.  All
realms generate their own key pair.

Now to get around that, maybe you could export a realm to JSON, put in
what you want for the key information and import it as a new realm or
server configuration.  That might be a little crazy.  The more I
thought about it, since the realm key pairs are for signing and
encrypting the JWTs (or saml), that it's kinda nice you can hit a key
and generate new ones in case of a compromise...or to keep stuff
revolving.

Hope that helps!

jeremy
jeremy at jeremysimon.com
www.JeremySimon.com


On Fri, Feb 19, 2016 at 8:41 AM, J?r?me Revillard <jrevillard at gnubila.fr> wrote:
> Any advise for this please ?
>
> Best,
> Jerome
>
>
> Le 17/02/2016 11:19, J?r?me Revillard a ?crit :
>
> Yes, it seems to be the case for the server, but not for the clients. See
> the trustore config description here:
> https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>
> Best,
> Jerome
>
> Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
>
> I'm not sure if I got your question in the right way. But from my
> understanding Java truststore is the standard fall back.
>
> See item 3.2.5
> https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
>
> On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard <jrevillard at gnubila.fr>
> wrote:
>>
>> Dear all,
>>
>> I'm testing now a Keycloak server properly configured with https
>> configuration.
>> The server certificate is one which is already known by the default java
>> trustore.
>> Would it be possible to setup the keycloak.json adapter config to use
>> this default java trustore ?
>>
>> Best,
>> Jerome
>>
>> _______________________________________________
>> 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 mstrukel at redhat.com  Fri Feb 19 09:12:00 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 19 Feb 2016 15:12:00 +0100
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <56C71B83.80201@gnubila.fr>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
	<56C44938.30507@gnubila.fr> <56C71B83.80201@gnubila.fr>
Message-ID: <CA+1OW+h+YXozUCZN1+hUkZAL=2+e6c8L63FgVwMWrBGrsnY5sw@mail.gmail.com>

What version of Keycloak are you using, and what have you tried so far?

It sounds like you've tried to not set "truststore", and it didn't work.
What's the exception you get?


On Fri, Feb 19, 2016 at 2:41 PM, J?r?me Revillard <jrevillard at gnubila.fr>
wrote:

> Any advise for this please ?
>
> Best,
> Jerome
>
>
> Le 17/02/2016 11:19, J?r?me Revillard a ?crit :
>
> Yes, it seems to be the case for the server, but not for the clients. See
> the trustore config description here:
> https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>
> Best,
> Jerome
>
> Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
>
> I'm not sure if I got your question in the right way. But from my
> understanding Java truststore is the standard fall back.
>
> See item 3.2.5
> https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
>
> On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard <jrevillard at gnubila.fr>
> wrote:
>
>> Dear all,
>>
>> I'm testing now a Keycloak server properly configured with https
>> configuration.
>> The server certificate is one which is already known by the default java
>> trustore.
>> Would it be possible to setup the keycloak.json adapter config to use
>> this default java trustore ?
>>
>> Best,
>> Jerome
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160219/a0975831/attachment.html 

From sthorger at redhat.com  Fri Feb 19 09:14:26 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 Feb 2016 15:14:26 +0100
Subject: [keycloak-user] Various login methods for one realm
In-Reply-To: <D2ECB572.27CE0%maurice.quaedackers@planonsoftware.com>
References: <D2ECB572.27CE0%maurice.quaedackers@planonsoftware.com>
Message-ID: <CAJgngAdXCaZF=q2p0FLqy19iwK7jqLq=pFaysOar+8S6SZBzUw@mail.gmail.com>

If idp is to auth by default we just redirect to it. If it's not available
at the moment there's no option to show regular login.

You can probably achieve what you want with a custom authenticator. You can
also file a jira to request this feature. Not sure when we'd have time to
add it ourselves though.
On 19 Feb 2016 11:06, "Maurice Quaedackers" <
Maurice.Quaedackers at planonsoftware.com> wrote:

> Hello,
>
> We are using keycloak as an Identity Broker solution in front of our web
> application.
>
> We have two options for an end-user:
>
>    1. User want to authenticate against a SAML IDP configured in Keycloak
>    as an Identity Provider
>    2. User want to authenticate against keycloak username/password
>    present in keycloak realm
>
> Is it possible to set the Identity Provider to authenticate by default but
> if the user is not able to reach the configured Single Sign-On Service URL
> (because IDP is not available outside customer network) a fallback is given
> to the manual login page?
>
> Or how can you end up at the manual (keycloak) username/password login
> screen when the Identity Provider has been set to authenticate by default.
>
> I tried to find this in the manuals but I was not able to find this.
>
> Best regards,
>
> Maurice Quaedackers.
>
>
>
> _______________________________________________
> 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/20160219/f7925322/attachment-0001.html 

From sthorger at redhat.com  Fri Feb 19 09:16:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 Feb 2016 15:16:45 +0100
Subject: [keycloak-user] SSL port on docker images
In-Reply-To: <CAFMa6BYuvLJ0r1DVfxyPgCLGa3EvcGsVmV-164Skrgh_YfRkQg@mail.gmail.com>
References: <56C467DD.3080709@gmail.com>
	<CAFMa6BYuvLJ0r1DVfxyPgCLGa3EvcGsVmV-164Skrgh_YfRkQg@mail.gmail.com>
Message-ID: <CAJgngAfYGqRGTDppNOYU_s6bET+8cH8jCkuEsuMfhKsurGc4tg@mail.gmail.com>

Do you not have to extend it to enable SSL in any case? So you export the
extra port then right
On 17 Feb 2016 13:24, "Kevin Thorpe" <kevin at pibenchmark.com> wrote:

> Its easy to make your own image on top to expose that port. However in our
> case we use keycloak inside docker on 8080 and front it externally with our
> main nginx SSL+load balancer
> On 17 Feb 2016 12:31 pm, "Tim Dudgeon" <tdudgeon.ml at gmail.com> wrote:
>
>> Can the SSL port on the docker images be exposed?
>> Currently only port 8080 is exposed. Why not 8443?
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/42af73eb/attachment.html 

From sthorger at redhat.com  Fri Feb 19 09:40:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 Feb 2016 15:40:09 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
Message-ID: <CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>

We don't. Why would we add it though?
On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com> wrote:

> Hi,
>
> is there any plan to support for displaying of "attributes" from Client
> Representation
> (like users configuration) in Admin Console?
>
> Thanks.
>
> Best Regards,
> Juraj
>
> _______________________________________________
> 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/20160219/72a4cc52/attachment.html 

From sthorger at redhat.com  Fri Feb 19 09:44:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 Feb 2016 15:44:27 +0100
Subject: [keycloak-user] Undertow adapter documentation
In-Reply-To: <56C44CD0.2020800@akvo.org>
References: <56C44CD0.2020800@akvo.org>
Message-ID: <CAJgngAdbPi0wb66T4qo7aqQcSSDnryYZM9B+zTAJbfVvQqwfjw@mail.gmail.com>

Are you using Undertow on its own? We use those bits for WildFly support as
it uses Undertow.
On 17 Feb 2016 10:36, "Iv?n Perdomo" <ivan at akvo.org> wrote:

> Hi all,
>
> There is some Undertow related code [1] but is not documented in the
> "Adapters" section.
>
> Is Undertow a supported server? If so, any hints on how to enable the
> adapter?
>
>
> [1]
> https://github.com/keycloak/keycloak/tree/1.8.1.Final/integration/undertow
>
> Thanks,
>
> --
> Iv?n
>
>
> _______________________________________________
> 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/20160219/83c252da/attachment.html 

From mstrukel at redhat.com  Fri Feb 19 09:53:07 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 19 Feb 2016 15:53:07 +0100
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <CAPFuFv9DRx6kbdhS45eSBEHxt1XxKXfa1pCopQtOAnESuC=V_Q@mail.gmail.com>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
	<56C44938.30507@gnubila.fr> <56C71B83.80201@gnubila.fr>
	<CAPFuFv9DRx6kbdhS45eSBEHxt1XxKXfa1pCopQtOAnESuC=V_Q@mail.gmail.com>
Message-ID: <CA+1OW+j3Pf1iX1nAAk8wSMToeV2un-k_B3P0o-qztVNt__99_w@mail.gmail.com>

Please don't hijack a thread. These sound like two separate issues. Here we
are talking about getting client adapter to connect to https protected
Keycloak server - which requires that some truststore is used by HttpClient
library used by adapter.

What you are talking about - realm keys - is something completely
different, and has nothing to do with a truststore.

On Fri, Feb 19, 2016 at 3:10 PM, Jeremy Simon <jeremy at jeremysimon.com>
wrote:

> Hey there,
>
> I had asked about this a while ago too.  Far as I know, the current
> implementation uses the jks for the HTTPS communication only.  All
> realms generate their own key pair.
>
> Now to get around that, maybe you could export a realm to JSON, put in
> what you want for the key information and import it as a new realm or
> server configuration.  That might be a little crazy.  The more I
> thought about it, since the realm key pairs are for signing and
> encrypting the JWTs (or saml), that it's kinda nice you can hit a key
> and generate new ones in case of a compromise...or to keep stuff
> revolving.
>
> Hope that helps!
>
> jeremy
> jeremy at jeremysimon.com
> www.JeremySimon.com
>
>
> On Fri, Feb 19, 2016 at 8:41 AM, J?r?me Revillard <jrevillard at gnubila.fr>
> wrote:
> > Any advise for this please ?
> >
> > Best,
> > Jerome
> >
> >
> > Le 17/02/2016 11:19, J?r?me Revillard a ?crit :
> >
> > Yes, it seems to be the case for the server, but not for the clients. See
> > the trustore config description here:
> >
> https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
> >
> > Best,
> > Jerome
> >
> > Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
> >
> > I'm not sure if I got your question in the right way. But from my
> > understanding Java truststore is the standard fall back.
> >
> > See item 3.2.5
> >
> https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
> >
> > On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard <jrevillard at gnubila.fr>
> > wrote:
> >>
> >> Dear all,
> >>
> >> I'm testing now a Keycloak server properly configured with https
> >> configuration.
> >> The server certificate is one which is already known by the default java
> >> trustore.
> >> Would it be possible to setup the keycloak.json adapter config to use
> >> this default java trustore ?
> >>
> >> Best,
> >> Jerome
> >>
> >> _______________________________________________
> >> keycloak-user mailing list
> >> keycloak-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/00e3d7c6/attachment.html 

From jeremy at jeremysimon.com  Fri Feb 19 10:39:56 2016
From: jeremy at jeremysimon.com (Jeremy Simon)
Date: Fri, 19 Feb 2016 10:39:56 -0500
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <CA+1OW+j3Pf1iX1nAAk8wSMToeV2un-k_B3P0o-qztVNt__99_w@mail.gmail.com>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
	<56C44938.30507@gnubila.fr> <56C71B83.80201@gnubila.fr>
	<CAPFuFv9DRx6kbdhS45eSBEHxt1XxKXfa1pCopQtOAnESuC=V_Q@mail.gmail.com>
	<CA+1OW+j3Pf1iX1nAAk8wSMToeV2un-k_B3P0o-qztVNt__99_w@mail.gmail.com>
Message-ID: <CAPFuFv-5tCY6iuUJxhkL0JT0yH_9hG9i=nwH12+owu2UK-Z87A@mail.gmail.com>

Sorry, I simply misunderstood.  Not try to hijack anything... What good
would that do??
On Feb 19, 2016 9:53 AM, "Marko Strukelj" <mstrukel at redhat.com> wrote:

> Please don't hijack a thread. These sound like two separate issues. Here
> we are talking about getting client adapter to connect to https protected
> Keycloak server - which requires that some truststore is used by HttpClient
> library used by adapter.
>
> What you are talking about - realm keys - is something completely
> different, and has nothing to do with a truststore.
>
> On Fri, Feb 19, 2016 at 3:10 PM, Jeremy Simon <jeremy at jeremysimon.com>
> wrote:
>
>> Hey there,
>>
>> I had asked about this a while ago too.  Far as I know, the current
>> implementation uses the jks for the HTTPS communication only.  All
>> realms generate their own key pair.
>>
>> Now to get around that, maybe you could export a realm to JSON, put in
>> what you want for the key information and import it as a new realm or
>> server configuration.  That might be a little crazy.  The more I
>> thought about it, since the realm key pairs are for signing and
>> encrypting the JWTs (or saml), that it's kinda nice you can hit a key
>> and generate new ones in case of a compromise...or to keep stuff
>> revolving.
>>
>> Hope that helps!
>>
>> jeremy
>> jeremy at jeremysimon.com
>> www.JeremySimon.com
>>
>>
>> On Fri, Feb 19, 2016 at 8:41 AM, J?r?me Revillard <jrevillard at gnubila.fr>
>> wrote:
>> > Any advise for this please ?
>> >
>> > Best,
>> > Jerome
>> >
>> >
>> > Le 17/02/2016 11:19, J?r?me Revillard a ?crit :
>> >
>> > Yes, it seems to be the case for the server, but not for the clients.
>> See
>> > the trustore config description here:
>> >
>> https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>> >
>> > Best,
>> > Jerome
>> >
>> > Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
>> >
>> > I'm not sure if I got your question in the right way. But from my
>> > understanding Java truststore is the standard fall back.
>> >
>> > See item 3.2.5
>> >
>> https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
>> >
>> > On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard <jrevillard at gnubila.fr
>> >
>> > wrote:
>> >>
>> >> Dear all,
>> >>
>> >> I'm testing now a Keycloak server properly configured with https
>> >> configuration.
>> >> The server certificate is one which is already known by the default
>> java
>> >> trustore.
>> >> Would it be possible to setup the keycloak.json adapter config to use
>> >> this default java trustore ?
>> >>
>> >> Best,
>> >> Jerome
>> >>
>> >> _______________________________________________
>> >> keycloak-user mailing list
>> >> keycloak-user at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >
>> >
>> >
>> > _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >
>> >
>> > _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
> _______________________________________________
> 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/20160219/90033571/attachment-0001.html 

From jrevillard at gnubila.fr  Fri Feb 19 10:43:13 2016
From: jrevillard at gnubila.fr (=?UTF-8?B?SsOpcsO0bWUgUmV2aWxsYXJk?=)
Date: Fri, 19 Feb 2016 16:43:13 +0100
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <CA+1OW+h+YXozUCZN1+hUkZAL=2+e6c8L63FgVwMWrBGrsnY5sw@mail.gmail.com>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
	<56C44938.30507@gnubila.fr> <56C71B83.80201@gnubila.fr>
	<CA+1OW+h+YXozUCZN1+hUkZAL=2+e6c8L63FgVwMWrBGrsnY5sw@mail.gmail.com>
Message-ID: <56C73811.1080004@gnubila.fr>

Hi Marko,

I use Keycloak 1.4.0.Final but it's the same with the latest one.

Here is the error that I get from the "KeycloakInstalled" adaptor but 
it's the same for at least the Jetty9.2 one:

//---------------------------------------------------------------------
Open the following URL in a browser. After login copy/paste the code 
back and press <enter>
https://sso.gnubila.fr/auth/realms/Tests/protocol/openid-connect/auth?response_type=code&client_id=pandora-web-service-client&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob

Code: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Exception in thread "main" javax.net.ssl.SSLHandshakeException: 
sun.security.validator.ValidatorException: PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to 
find valid certification path to requested target
     at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
     at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
     at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
     at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
     at 
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)
     at 
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
     at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
     at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
     at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
     at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
     at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
     at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
     at 
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:535)
     at 
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:403)
     at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
     at 
org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144)
     at 
org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131)
     at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
     at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
     at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
     at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
     at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
     at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
     at 
org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:122)
     at 
org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:95)
     at 
org.keycloak.adapters.installed.KeycloakInstalled.processCode(KeycloakInstalled.java:232)
     at 
org.keycloak.adapters.installed.KeycloakInstalled.loginManual(KeycloakInstalled.java:168)
     at 
org.keycloak.adapters.installed.KeycloakInstalled.loginManual(KeycloakInstalled.java:147)
     at cmd_client.main(cmd_client.java:64)
Caused by: sun.security.validator.ValidatorException: PKIX path building 
failed: sun.security.provider.certpath.SunCertPathBuilderException: 
unable to find valid certification path to requested target
     at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387)
     at 
sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
     at sun.security.validator.Validator.validate(Validator.java:260)
     at 
sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
     at 
sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
     at 
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
     at 
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1491)
     ... 24 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: 
unable to find valid certification path to requested target
     at 
sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
     at 
sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
     at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
     at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
     ... 30 more
//---------------------------------------------------------------------

Best,
Jerome

Le 19/02/2016 15:12, Marko Strukelj a ?crit :
> What version of Keycloak are you using, and what have you tried so far?
>
> It sounds like you've tried to not set "truststore", and it didn't 
> work. What's the exception you get?
>
>
> On Fri, Feb 19, 2016 at 2:41 PM, J?r?me Revillard 
> <jrevillard at gnubila.fr <mailto:jrevillard at gnubila.fr>> wrote:
>
>     Any advise for this please ?
>
>     Best,
>     Jerome
>
>
>     Le 17/02/2016 11:19, J?r?me Revillard a ?crit :
>>     Yes, it seems to be the case for the server, but not for the
>>     clients. See the trustore config description here:
>>     https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>>
>>     Best,
>>     Jerome
>>
>>     Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
>>>     I'm not sure if I got your question in the right way. But from
>>>     my understanding Java truststore is the standard fall back.
>>>
>>>     See item 3.2.5
>>>     https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
>>>
>>>     On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard
>>>     <jrevillard at gnubila.fr <mailto:jrevillard at gnubila.fr>> wrote:
>>>
>>>         Dear all,
>>>
>>>         I'm testing now a Keycloak server properly configured with https
>>>         configuration.
>>>         The server certificate is one which is already known by the
>>>         default java
>>>         trustore.
>>>         Would it be possible to setup the keycloak.json adapter
>>>         config to use
>>>         this default java trustore ?
>>>
>>>         Best,
>>>         Jerome
>>>
>>>         _______________________________________________
>>>         keycloak-user mailing list
>>>         keycloak-user at lists.jboss.org
>>>         <mailto:keycloak-user at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/37a3fb34/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3908 bytes
Desc: Signature cryptographique S/MIME
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/37a3fb34/attachment.bin 

From mstrukel at redhat.com  Fri Feb 19 10:55:31 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 19 Feb 2016 16:55:31 +0100
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <CAPFuFv-5tCY6iuUJxhkL0JT0yH_9hG9i=nwH12+owu2UK-Z87A@mail.gmail.com>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
	<56C44938.30507@gnubila.fr> <56C71B83.80201@gnubila.fr>
	<CAPFuFv9DRx6kbdhS45eSBEHxt1XxKXfa1pCopQtOAnESuC=V_Q@mail.gmail.com>
	<CA+1OW+j3Pf1iX1nAAk8wSMToeV2un-k_B3P0o-qztVNt__99_w@mail.gmail.com>
	<CAPFuFv-5tCY6iuUJxhkL0JT0yH_9hG9i=nwH12+owu2UK-Z87A@mail.gmail.com>
Message-ID: <CA+1OW+gGBZDFwyhS7LW5Wm2QMFjiS6wOZcrfAVfoJV3oYvyQiw@mail.gmail.com>

That's just an expression used when someone steers the thread into an
unrelated topic :)

On Fri, Feb 19, 2016 at 4:39 PM, Jeremy Simon <jeremy at jeremysimon.com>
wrote:

> Sorry, I simply misunderstood.  Not try to hijack anything... What good
> would that do??
> On Feb 19, 2016 9:53 AM, "Marko Strukelj" <mstrukel at redhat.com> wrote:
>
>> Please don't hijack a thread. These sound like two separate issues. Here
>> we are talking about getting client adapter to connect to https protected
>> Keycloak server - which requires that some truststore is used by HttpClient
>> library used by adapter.
>>
>> What you are talking about - realm keys - is something completely
>> different, and has nothing to do with a truststore.
>>
>> On Fri, Feb 19, 2016 at 3:10 PM, Jeremy Simon <jeremy at jeremysimon.com>
>> wrote:
>>
>>> Hey there,
>>>
>>> I had asked about this a while ago too.  Far as I know, the current
>>> implementation uses the jks for the HTTPS communication only.  All
>>> realms generate their own key pair.
>>>
>>> Now to get around that, maybe you could export a realm to JSON, put in
>>> what you want for the key information and import it as a new realm or
>>> server configuration.  That might be a little crazy.  The more I
>>> thought about it, since the realm key pairs are for signing and
>>> encrypting the JWTs (or saml), that it's kinda nice you can hit a key
>>> and generate new ones in case of a compromise...or to keep stuff
>>> revolving.
>>>
>>> Hope that helps!
>>>
>>> jeremy
>>> jeremy at jeremysimon.com
>>> www.JeremySimon.com
>>>
>>>
>>> On Fri, Feb 19, 2016 at 8:41 AM, J?r?me Revillard <jrevillard at gnubila.fr>
>>> wrote:
>>> > Any advise for this please ?
>>> >
>>> > Best,
>>> > Jerome
>>> >
>>> >
>>> > Le 17/02/2016 11:19, J?r?me Revillard a ?crit :
>>> >
>>> > Yes, it seems to be the case for the server, but not for the clients.
>>> See
>>> > the trustore config description here:
>>> >
>>> https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>>> >
>>> > Best,
>>> > Jerome
>>> >
>>> > Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
>>> >
>>> > I'm not sure if I got your question in the right way. But from my
>>> > understanding Java truststore is the standard fall back.
>>> >
>>> > See item 3.2.5
>>> >
>>> https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
>>> >
>>> > On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard <
>>> jrevillard at gnubila.fr>
>>> > wrote:
>>> >>
>>> >> Dear all,
>>> >>
>>> >> I'm testing now a Keycloak server properly configured with https
>>> >> configuration.
>>> >> The server certificate is one which is already known by the default
>>> java
>>> >> trustore.
>>> >> Would it be possible to setup the keycloak.json adapter config to use
>>> >> this default java trustore ?
>>> >>
>>> >> Best,
>>> >> Jerome
>>> >>
>>> >> _______________________________________________
>>> >> keycloak-user mailing list
>>> >> keycloak-user at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > keycloak-user mailing list
>>> > keycloak-user at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> >
>>> >
>>> > _______________________________________________
>>> > keycloak-user mailing list
>>> > keycloak-user at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>> _______________________________________________
>> 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/20160219/ac9b75bb/attachment-0001.html 

From andyyar66 at gmail.com  Fri Feb 19 10:56:40 2016
From: andyyar66 at gmail.com (Andy Yar)
Date: Fri, 19 Feb 2016 16:56:40 +0100
Subject: [keycloak-user] Spring Security - URL schema in "redirect_uri"
	generation
Message-ID: <CAMBdEymLn=FpoXh4uTyCKp4wKjCF1SjwoEhsNetX9yb-dH1k8w@mail.gmail.com>

Howdy,
I use 1.8.0-Final integrated with Spring Security (which itself is
integrated into Grails) using OpenID Connect method. The Keycloak and all
integrated apps run behind a nginx SSL reverse proxy. Realm's SSL is set
to: "ssl-required": "external".

My issue is related to initial "redirect_uri" generation.

When I'm logged out and try to access a protected resource via a HTTPS
request, I receive 302 response with Location URL starting with plain HTTP
scheme. Apparently the Location goes to the "redirect_uri" attribute and
therefore it tries to redirect me back here after a successful login.

Of course, it is possible to add both HTTP and HTTPS schemas as allowed
redirect URI patterns. However, application's security gets lowered by that
plain HTTP redirect...

Is there any easy solution for non-SSL Keycloak/apps running behind SSL
reverse proxy? I haven't looked into the source code but it seems as a
plain redirect which wouldn't be schema-aware.

Thanks in advance!
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/d56b8f58/attachment.html 

From bburke at redhat.com  Fri Feb 19 11:01:16 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 Feb 2016 11:01:16 -0500
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <CA+1OW+gGBZDFwyhS7LW5Wm2QMFjiS6wOZcrfAVfoJV3oYvyQiw@mail.gmail.com>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
	<56C44938.30507@gnubila.fr> <56C71B83.80201@gnubila.fr>
	<CAPFuFv9DRx6kbdhS45eSBEHxt1XxKXfa1pCopQtOAnESuC=V_Q@mail.gmail.com>
	<CA+1OW+j3Pf1iX1nAAk8wSMToeV2un-k_B3P0o-qztVNt__99_w@mail.gmail.com>
	<CAPFuFv-5tCY6iuUJxhkL0JT0yH_9hG9i=nwH12+owu2UK-Z87A@mail.gmail.com>
	<CA+1OW+gGBZDFwyhS7LW5Wm2QMFjiS6wOZcrfAVfoJV3oYvyQiw@mail.gmail.com>
Message-ID: <56C73C4C.8000507@redhat.com>

So, how do you like the new keycloak logo?

On 2/19/2016 10:55 AM, Marko Strukelj wrote:
> That's just an expression used when someone steers the thread into an 
> unrelated topic :)
>
> On Fri, Feb 19, 2016 at 4:39 PM, Jeremy Simon <jeremy at jeremysimon.com 
> <mailto:jeremy at jeremysimon.com>> wrote:
>
>     Sorry, I simply misunderstood.  Not try to hijack anything... What
>     good would that do??
>
>     On Feb 19, 2016 9:53 AM, "Marko Strukelj" <mstrukel at redhat.com
>     <mailto:mstrukel at redhat.com>> wrote:
>
>         Please don't hijack a thread. These sound like two separate
>         issues. Here we are talking about getting client adapter to
>         connect to https protected Keycloak server - which requires
>         that some truststore is used by HttpClient library used by
>         adapter.
>
>         What you are talking about - realm keys - is something
>         completely different, and has nothing to do with a truststore.
>
>         On Fri, Feb 19, 2016 at 3:10 PM, Jeremy Simon
>         <jeremy at jeremysimon.com <mailto:jeremy at jeremysimon.com>> wrote:
>
>             Hey there,
>
>             I had asked about this a while ago too.  Far as I know,
>             the current
>             implementation uses the jks for the HTTPS communication
>             only.  All
>             realms generate their own key pair.
>
>             Now to get around that, maybe you could export a realm to
>             JSON, put in
>             what you want for the key information and import it as a
>             new realm or
>             server configuration.  That might be a little crazy.  The
>             more I
>             thought about it, since the realm key pairs are for
>             signing and
>             encrypting the JWTs (or saml), that it's kinda nice you
>             can hit a key
>             and generate new ones in case of a compromise...or to keep
>             stuff
>             revolving.
>
>             Hope that helps!
>
>             jeremy
>             jeremy at jeremysimon.com <mailto:jeremy at jeremysimon.com>
>             www.JeremySimon.com <http://www.JeremySimon.com>
>
>
>             On Fri, Feb 19, 2016 at 8:41 AM, J?r?me Revillard
>             <jrevillard at gnubila.fr <mailto:jrevillard at gnubila.fr>> wrote:
>             > Any advise for this please ?
>             >
>             > Best,
>             > Jerome
>             >
>             >
>             > Le 17/02/2016 11:19, J?r?me Revillard a ?crit :
>             >
>             > Yes, it seems to be the case for the server, but not for
>             the clients. See
>             > the trustore config description here:
>             >
>             https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>             >
>             > Best,
>             > Jerome
>             >
>             > Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
>             >
>             > I'm not sure if I got your question in the right way.
>             But from my
>             > understanding Java truststore is the standard fall back.
>             >
>             > See item 3.2.5
>             >
>             https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
>             >
>             > On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard
>             <jrevillard at gnubila.fr <mailto:jrevillard at gnubila.fr>>
>             > wrote:
>             >>
>             >> Dear all,
>             >>
>             >> I'm testing now a Keycloak server properly configured
>             with https
>             >> configuration.
>             >> The server certificate is one which is already known by
>             the default java
>             >> trustore.
>             >> Would it be possible to setup the keycloak.json adapter
>             config to use
>             >> this default java trustore ?
>             >>
>             >> Best,
>             >> Jerome
>             >>
>             >> _______________________________________________
>             >> keycloak-user mailing list
>             >> keycloak-user at lists.jboss.org
>             <mailto:keycloak-user at lists.jboss.org>
>             >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>             >
>             >
>             >
>             > _______________________________________________
>             > keycloak-user mailing list
>             > keycloak-user at lists.jboss.org
>             <mailto:keycloak-user at lists.jboss.org>
>             > https://lists.jboss.org/mailman/listinfo/keycloak-user
>             >
>             >
>             > _______________________________________________
>             > keycloak-user mailing list
>             > keycloak-user at lists.jboss.org
>             <mailto:keycloak-user at lists.jboss.org>
>             > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>             _______________________________________________
>             keycloak-user mailing list
>             keycloak-user at lists.jboss.org
>             <mailto:keycloak-user at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>         _______________________________________________
>         keycloak-user mailing list
>         keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/42d9c653/attachment.html 

From mstrukel at redhat.com  Fri Feb 19 11:13:09 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 19 Feb 2016 17:13:09 +0100
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <56C73C4C.8000507@redhat.com>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
	<56C44938.30507@gnubila.fr> <56C71B83.80201@gnubila.fr>
	<CAPFuFv9DRx6kbdhS45eSBEHxt1XxKXfa1pCopQtOAnESuC=V_Q@mail.gmail.com>
	<CA+1OW+j3Pf1iX1nAAk8wSMToeV2un-k_B3P0o-qztVNt__99_w@mail.gmail.com>
	<CAPFuFv-5tCY6iuUJxhkL0JT0yH_9hG9i=nwH12+owu2UK-Z87A@mail.gmail.com>
	<CA+1OW+gGBZDFwyhS7LW5Wm2QMFjiS6wOZcrfAVfoJV3oYvyQiw@mail.gmail.com>
	<56C73C4C.8000507@redhat.com>
Message-ID: <CA+1OW+hWREMq-7Nq3jjKUo_eVko-QbSqptdsXbMww5Z6oAn2PQ@mail.gmail.com>

:)

Bill can confirm, but I think -Djavax.net.ssl.trustStore should work on the
adapter side, and using adapter 'truststore' property is optional. If set
it overrides Java runtime trustore config, if not java runtime truststore
is used.

On Fri, Feb 19, 2016 at 5:01 PM, Bill Burke <bburke at redhat.com> wrote:

> So, how do you like the new keycloak logo?
>
>
> On 2/19/2016 10:55 AM, Marko Strukelj wrote:
>
> That's just an expression used when someone steers the thread into an
> unrelated topic :)
>
> On Fri, Feb 19, 2016 at 4:39 PM, Jeremy Simon <jeremy at jeremysimon.com>
> wrote:
>
>> Sorry, I simply misunderstood.  Not try to hijack anything... What good
>> would that do??
>> On Feb 19, 2016 9:53 AM, "Marko Strukelj" <mstrukel at redhat.com> wrote:
>>
>>> Please don't hijack a thread. These sound like two separate issues. Here
>>> we are talking about getting client adapter to connect to https protected
>>> Keycloak server - which requires that some truststore is used by HttpClient
>>> library used by adapter.
>>>
>>> What you are talking about - realm keys - is something completely
>>> different, and has nothing to do with a truststore.
>>>
>>> On Fri, Feb 19, 2016 at 3:10 PM, Jeremy Simon < <jeremy at jeremysimon.com>
>>> jeremy at jeremysimon.com> wrote:
>>>
>>>> Hey there,
>>>>
>>>> I had asked about this a while ago too.  Far as I know, the current
>>>> implementation uses the jks for the HTTPS communication only.  All
>>>> realms generate their own key pair.
>>>>
>>>> Now to get around that, maybe you could export a realm to JSON, put in
>>>> what you want for the key information and import it as a new realm or
>>>> server configuration.  That might be a little crazy.  The more I
>>>> thought about it, since the realm key pairs are for signing and
>>>> encrypting the JWTs (or saml), that it's kinda nice you can hit a key
>>>> and generate new ones in case of a compromise...or to keep stuff
>>>> revolving.
>>>>
>>>> Hope that helps!
>>>>
>>>> jeremy
>>>> jeremy at jeremysimon.com
>>>> www.JeremySimon.com
>>>>
>>>>
>>>> On Fri, Feb 19, 2016 at 8:41 AM, J?r?me Revillard <
>>>> jrevillard at gnubila.fr> wrote:
>>>> > Any advise for this please ?
>>>> >
>>>> > Best,
>>>> > Jerome
>>>> >
>>>> >
>>>> > Le 17/02/2016 11:19, J?r?me Revillard a ?crit :
>>>> >
>>>> > Yes, it seems to be the case for the server, but not for the clients.
>>>> See
>>>> > the trustore config description here:
>>>> >
>>>> https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>>>> >
>>>> > Best,
>>>> > Jerome
>>>> >
>>>> > Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
>>>> >
>>>> > I'm not sure if I got your question in the right way. But from my
>>>> > understanding Java truststore is the standard fall back.
>>>> >
>>>> > See item 3.2.5
>>>> >
>>>> https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
>>>> >
>>>> > On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard <
>>>> <jrevillard at gnubila.fr>jrevillard at gnubila.fr>
>>>> > wrote:
>>>> >>
>>>> >> Dear all,
>>>> >>
>>>> >> I'm testing now a Keycloak server properly configured with https
>>>> >> configuration.
>>>> >> The server certificate is one which is already known by the default
>>>> java
>>>> >> trustore.
>>>> >> Would it be possible to setup the keycloak.json adapter config to use
>>>> >> this default java trustore ?
>>>> >>
>>>> >> Best,
>>>> >> Jerome
>>>> >>
>>>> >> _______________________________________________
>>>> >> keycloak-user mailing list
>>>> >> keycloak-user at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > keycloak-user mailing list
>>>> > keycloak-user at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > keycloak-user mailing list
>>>> > keycloak-user at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160219/4393bde2/attachment-0001.html 

From jrevillard at gnubila.fr  Fri Feb 19 11:24:39 2016
From: jrevillard at gnubila.fr (=?UTF-8?B?SsOpcsO0bWUgUmV2aWxsYXJk?=)
Date: Fri, 19 Feb 2016 17:24:39 +0100
Subject: [keycloak-user] Adapter trustore: use default java trustore
 possible ?
In-Reply-To: <CA+1OW+hWREMq-7Nq3jjKUo_eVko-QbSqptdsXbMww5Z6oAn2PQ@mail.gmail.com>
References: <56C42A44.7070507@gnubila.fr>
	<CAM5SUC7F9Qnsms=hC5hKYJVUAJRyc_NHAHpU1z6ZYR4KmoYaCQ@mail.gmail.com>
	<56C44938.30507@gnubila.fr> <56C71B83.80201@gnubila.fr>
	<CAPFuFv9DRx6kbdhS45eSBEHxt1XxKXfa1pCopQtOAnESuC=V_Q@mail.gmail.com>
	<CA+1OW+j3Pf1iX1nAAk8wSMToeV2un-k_B3P0o-qztVNt__99_w@mail.gmail.com>
	<CAPFuFv-5tCY6iuUJxhkL0JT0yH_9hG9i=nwH12+owu2UK-Z87A@mail.gmail.com>
	<CA+1OW+gGBZDFwyhS7LW5Wm2QMFjiS6wOZcrfAVfoJV3oYvyQiw@mail.gmail.com>
	<56C73C4C.8000507@redhat.com>
	<CA+1OW+hWREMq-7Nq3jjKUo_eVko-QbSqptdsXbMww5Z6oAn2PQ@mail.gmail.com>
Message-ID: <56C741C7.9060102@gnubila.fr>

Ok thanks I will check and let you know if I have problems.

Best,
Jerome

Le 19/02/2016 17:13, Marko Strukelj a ?crit :
> :)
>
> Bill can confirm, but I think -Djavax.net.ssl.trustStore should work 
> on the adapter side, and using adapter 'truststore' property is 
> optional. If set it overrides Java runtime trustore config, if not 
> java runtime truststore is used.
>
> On Fri, Feb 19, 2016 at 5:01 PM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     So, how do you like the new keycloak logo?
>
>
>     On 2/19/2016 10:55 AM, Marko Strukelj wrote:
>>     That's just an expression used when someone steers the thread
>>     into an unrelated topic :)
>>
>>     On Fri, Feb 19, 2016 at 4:39 PM, Jeremy Simon
>>     <jeremy at jeremysimon.com <mailto:jeremy at jeremysimon.com>> wrote:
>>
>>         Sorry, I simply misunderstood. Not try to hijack anything...
>>         What good would that do??
>>
>>         On Feb 19, 2016 9:53 AM, "Marko Strukelj"
>>         <mstrukel at redhat.com <mailto:mstrukel at redhat.com>> wrote:
>>
>>             Please don't hijack a thread. These sound like two
>>             separate issues. Here we are talking about getting client
>>             adapter to connect to https protected Keycloak server -
>>             which requires that some truststore is used by HttpClient
>>             library used by adapter.
>>
>>             What you are talking about - realm keys - is something
>>             completely different, and has nothing to do with a
>>             truststore.
>>
>>             On Fri, Feb 19, 2016 at 3:10 PM, Jeremy Simon
>>             <jeremy at jeremysimon.com <mailto:jeremy at jeremysimon.com>>
>>             wrote:
>>
>>                 Hey there,
>>
>>                 I had asked about this a while ago too.  Far as I
>>                 know, the current
>>                 implementation uses the jks for the HTTPS
>>                 communication only.  All
>>                 realms generate their own key pair.
>>
>>                 Now to get around that, maybe you could export a
>>                 realm to JSON, put in
>>                 what you want for the key information and import it
>>                 as a new realm or
>>                 server configuration.  That might be a little crazy. 
>>                 The more I
>>                 thought about it, since the realm key pairs are for
>>                 signing and
>>                 encrypting the JWTs (or saml), that it's kinda nice
>>                 you can hit a key
>>                 and generate new ones in case of a compromise...or to
>>                 keep stuff
>>                 revolving.
>>
>>                 Hope that helps!
>>
>>                 jeremy
>>                 jeremy at jeremysimon.com <mailto:jeremy at jeremysimon.com>
>>                 www.JeremySimon.com <http://www.JeremySimon.com>
>>
>>
>>                 On Fri, Feb 19, 2016 at 8:41 AM, J?r?me Revillard
>>                 <jrevillard at gnubila.fr
>>                 <mailto:jrevillard at gnubila.fr>> wrote:
>>                 > Any advise for this please ?
>>                 >
>>                 > Best,
>>                 > Jerome
>>                 >
>>                 >
>>                 > Le 17/02/2016 11:19, J?r?me Revillard a ?crit :
>>                 >
>>                 > Yes, it seems to be the case for the server, but
>>                 not for the clients. See
>>                 > the trustore config description here:
>>                 >
>>                 https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config
>>                 >
>>                 > Best,
>>                 > Jerome
>>                 >
>>                 > Le 17/02/2016 11:09, Bruno Oliveira a ?crit :
>>                 >
>>                 > I'm not sure if I got your question in the right
>>                 way. But from my
>>                 > understanding Java truststore is the standard fall
>>                 back.
>>                 >
>>                 > See item 3.2.5
>>                 >
>>                 https://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html
>>                 >
>>                 > On Wed, Feb 17, 2016 at 6:07 AM J?r?me Revillard
>>                 <jrevillard at gnubila.fr <mailto:jrevillard at gnubila.fr>>
>>                 > wrote:
>>                 >>
>>                 >> Dear all,
>>                 >>
>>                 >> I'm testing now a Keycloak server properly
>>                 configured with https
>>                 >> configuration.
>>                 >> The server certificate is one which is already
>>                 known by the default java
>>                 >> trustore.
>>                 >> Would it be possible to setup the keycloak.json
>>                 adapter config to use
>>                 >> this default java trustore ?
>>                 >>
>>                 >> Best,
>>                 >> Jerome
>>                 >>
>>                 >> _______________________________________________
>>                 >> keycloak-user mailing list
>>                 >> keycloak-user at lists.jboss.org
>>                 <mailto:keycloak-user at lists.jboss.org>
>>                 >> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>                 >
>>                 >
>>                 >
>>                 > _______________________________________________
>>                 > keycloak-user mailing list
>>                 > keycloak-user at lists.jboss.org
>>                 <mailto:keycloak-user at lists.jboss.org>
>>                 > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>                 >
>>                 >
>>                 > _______________________________________________
>>                 > keycloak-user mailing list
>>                 > keycloak-user at lists.jboss.org
>>                 <mailto:keycloak-user at lists.jboss.org>
>>                 > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>                 _______________________________________________
>>                 keycloak-user mailing list
>>                 keycloak-user at lists.jboss.org
>>                 <mailto:keycloak-user at lists.jboss.org>
>>                 https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>>             _______________________________________________
>>             keycloak-user mailing list
>>             keycloak-user at lists.jboss.org
>>             <mailto:keycloak-user at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/0aea07c4/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3908 bytes
Desc: Signature cryptographique S/MIME
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/0aea07c4/attachment-0001.bin 

From bruno at abstractj.org  Fri Feb 19 12:17:55 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 19 Feb 2016 17:17:55 +0000
Subject: [keycloak-user] SSL port on docker images
In-Reply-To: <CAJgngAfYGqRGTDppNOYU_s6bET+8cH8jCkuEsuMfhKsurGc4tg@mail.gmail.com>
References: <56C467DD.3080709@gmail.com>
	<CAFMa6BYuvLJ0r1DVfxyPgCLGa3EvcGsVmV-164Skrgh_YfRkQg@mail.gmail.com>
	<CAJgngAfYGqRGTDppNOYU_s6bET+8cH8jCkuEsuMfhKsurGc4tg@mail.gmail.com>
Message-ID: <CAM5SUC47JY7eFoniOH50=sdknMQdT68Tp34+pPaq0AZ0CZA=kg@mail.gmail.com>

Not sure if it helps, but I did this long time ago with WildFly:
https://github.com/jboss-dockerfiles/aerogear/blob/master/wildfly/Dockerfile.
Is not that hard to extend the image, also take a look at the script to
generate a self-signed certificate
https://github.com/jboss-dockerfiles/aerogear/blob/master/wildfly/configuration/certs/certificate.sh
.


On Fri, Feb 19, 2016 at 12:16 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Do you not have to extend it to enable SSL in any case? So you export the
> extra port then right
> On 17 Feb 2016 13:24, "Kevin Thorpe" <kevin at pibenchmark.com> wrote:
>
>> Its easy to make your own image on top to expose that port. However in
>> our case we use keycloak inside docker on 8080 and front it externally with
>> our main nginx SSL+load balancer
>> On 17 Feb 2016 12:31 pm, "Tim Dudgeon" <tdudgeon.ml at gmail.com> wrote:
>>
>>> Can the SSL port on the docker images be exposed?
>>> Currently only port 8080 is exposed. Why not 8443?
>>>
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/cf749f1f/attachment.html 

From prabhalar at yahoo.com  Fri Feb 19 14:04:10 2016
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Fri, 19 Feb 2016 14:04:10 -0500
Subject: [keycloak-user] No kid in token headers
Message-ID: <62C2E2BE-DD49-4BD3-A984-510F1A784452@yahoo.com>

Revisited keycloak 1.9 cr1 after a long time. While the basic and implicit flows work properly, noticed that the token validation is failing due to the lack of kid in token header.  Did anyone come across  the same problem or am I missing something?

Btw we use our own oidc client libraries to interact with KC, which were tested against commercial products

Thanks,
Raghu

Sent from my iPhone

From mstrukel at redhat.com  Fri Feb 19 15:58:27 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 19 Feb 2016 21:58:27 +0100
Subject: [keycloak-user] User Account access from client
In-Reply-To: <BLU179-W88FAC41E378CA61B04A019D7A00@phx.gbl>
References: <BLU179-W12809647996963CE554BC9D7AD0@phx.gbl>
	<CA+1OW+goC2P45TgggzW1oE2Bovo6PRqCfD9d8P7cS3A+=-nwLg@mail.gmail.com>
	<BLU179-W88FAC41E378CA61B04A019D7A00@phx.gbl>
Message-ID: <CA+1OW+gzJOiQ1wuXGibLgBVE8q4xeS0oJN+7kf43=sGJNj-hZA@mail.gmail.com>

Realm has to be a part of user account url. That's built into Keycloak
server, and how its service endpoints are structured.

Within your application you can use HttpServletRequest attributes to get to
KeycloakDeployment, which contains information about the realm your
application was configured with:

KeycloakSecurityContext ctx = (KeycloakSecurityContext)
request.getAttribute(KeycloakSecurityContext.class.getName());
KeycloakDeployment deployment = ((RefreshableKeycloakSecurityContext)
ctx).getDeployment();
String realm = deployment.getRealm();

You can now use this realm to construct user account URL. I'm not sure if
this is part of our public API. There is realm on KeycloakSecurityContext,
but that one is only available if user is currently logged in.


On Fri, Feb 19, 2016 at 9:17 PM, Bill Simakis <smacksnr at hotmail.com> wrote:

> Marko,
>
> Thanks but is there a way without having to hard-code the realm name?
>
> Thanks,
>
> Bill
>
> ----------------------------------------
> > Date: Tue, 16 Feb 2016 22:08:21 +0100
> > Subject: Re: [keycloak-user] User Account access from client
> > From: mstrukel at redhat.com
> > To: smacksnr at hotmail.com
> > CC: keycloak-user at lists.jboss.org
> >
> > You can take a look at how example demo app does this:
> >
> >
> https://github.com/keycloak/keycloak/blob/1.9.0.CR1/examples/demo-template/customer-app/src/main/webapp/customers/view.jsp#L16
> >
> > On Tue, Feb 16, 2016 at 5:44 PM, Bill Simakis <smacksnr at hotmail.com>
> wrote:
> >> I have a web app using the spring security adapter which I have
> successfully integrated for the authentication/Authorization with KeyCloak.
> >> We wanted to make the user's life a little easier by providing a link
> within our app to allow an authenticated user to go to their Account page
> in KeyCloak. As this link is realm specific, is there a way we could get
> the url dynamically?
> >>
> >> Thanks
> >>
> >> Bill
> >> _______________________________________________
> >> 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/20160219/531231d5/attachment.html 

From battery4cid at gmail.com  Fri Feb 19 17:18:44 2016
From: battery4cid at gmail.com (Bruce Shaw)
Date: Fri, 19 Feb 2016 17:18:44 -0500
Subject: [keycloak-user] Confidential RESTful client
Message-ID: <CAFYKa1m677d+5V_GWjicJLPxFy71OmLhJ4YOsmR+VtaiF-nvdw@mail.gmail.com>

 I have a AngularJs single page web-app that makes RESTful API calls to get
secured data from our server (Play Framework).  I originally set it up to
be a public client using the keycloak.js adapter but I?m wondering if
there?s a more secure way.

Instead of having the redirect response (with the authorization code) come
back to the keycloak.js followed by the request to get the access token,
wouldn?t it be more secure to have the javascript post the returned
authorization code to our server or just set the redirect url to an
endpoint on our server to make the backchannel request (with client secret
and id) for the access token?  Then we can redirect the user to the
appropriate location with the access token in the response?

I guess I?m trying to make my RESTful api a confidential client, any input
or direction would help.

thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/2e1b6c92/attachment.html 

From ibaskine at microstrategy.com  Fri Feb 19 18:01:32 2016
From: ibaskine at microstrategy.com (Baskin, Ilia)
Date: Fri, 19 Feb 2016 23:01:32 +0000
Subject: [keycloak-user] Is it CSRF vulnerability?
Message-ID: <CY1PR07MB2200A3AC960FE1F7314D6F1AC4A00@CY1PR07MB2200.namprd07.prod.outlook.com>

Hi,

I am experimenting with Keycloak to evaluate its suitability for our application. Here is one of my experiments, that got me warried:

I created a simple page (see attached), deployed it on Tomcat and registered it in Keycloak as confidential client. As you can see the page contains a button clicking on which executes simple XHR request. Notice that XHR request doesn't contain Authorization header. On submission of my page URL I am redirected to Keycloak for authentication. After authentication I can submit XHR requests at will.

Now I copied my page and deployed the copy on the same Tomcat as a different totally unsecured application. If I open this page in another browser tab and click on XHR button it will go through without any problem. It looks to me as a typical CSRF case. Am I missing something here?

Thanks.
Ilia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/9f65cb7f/attachment-0002.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/9f65cb7f/attachment-0003.html 

From srossillo at smartling.com  Fri Feb 19 18:15:18 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Fri, 19 Feb 2016 18:15:18 -0500
Subject: [keycloak-user] Is it CSRF vulnerability?
In-Reply-To: <CY1PR07MB2200A3AC960FE1F7314D6F1AC4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
References: <CY1PR07MB2200A3AC960FE1F7314D6F1AC4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
Message-ID: <4D38F80E-FBFE-4757-9800-4F25F77AD5F7@smartling.com>

Once you?ve authenticated with Keycloak, your application has an session id provided by Tomcat. This is why your requests are succeeding. If you examine your XHR requests, I?d assume the session id cookie is being passed to the server.


Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Feb 19, 2016, at 6:01 PM, Baskin, Ilia <ibaskine at microstrategy.com> wrote:
> 
> Hi,
>  
> I am experimenting with Keycloak to evaluate its suitability for our application. Here is one of my experiments, that got me warried:
>  
> I created a simple page (see attached), deployed it on Tomcat and registered it in Keycloak as confidential client. As you can see the page contains a button clicking on which executes simple XHR request. Notice that XHR request doesn?t contain Authorization header. On submission of my page URL I am redirected to Keycloak for authentication. After authentication I can submit XHR requests at will.
>  
> Now I copied my page and deployed the copy on the same Tomcat as a different totally unsecured application. If I open this page in another browser tab and click on XHR button it will go through without any problem. It looks to me as a typical CSRF case. Am I missing something here?
>  
> Thanks.
> Ilia
> <index.html>_______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/d7484582/attachment.html 

From ibaskine at microstrategy.com  Fri Feb 19 18:19:21 2016
From: ibaskine at microstrategy.com (Baskin, Ilia)
Date: Fri, 19 Feb 2016 23:19:21 +0000
Subject: [keycloak-user] Is it CSRF vulnerability?
In-Reply-To: <4D38F80E-FBFE-4757-9800-4F25F77AD5F7@smartling.com>
References: <CY1PR07MB2200A3AC960FE1F7314D6F1AC4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
	<4D38F80E-FBFE-4757-9800-4F25F77AD5F7@smartling.com>
Message-ID: <CY1PR07MB2200DDEDFBE30B03413960A6C4A00@CY1PR07MB2200.namprd07.prod.outlook.com>

Scott,

I know that, but this is exactly how CSRF works. There are several simple ways to defend against CSRF and I am surprised that Keycloak, a security application, doesn?t utilize any.

Thanks.
Ilia

From: Scott Rossillo [mailto:srossillo at smartling.com]
Sent: Friday, February 19, 2016 6:15 PM
To: Baskin, Ilia
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Is it CSRF vulnerability?

Once you?ve authenticated with Keycloak, your application has an session id provided by Tomcat. This is why your requests are succeeding. If you examine your XHR requests, I?d assume the session id cookie is being passed to the server.


Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com<mailto:srossillo at smartling.com>

On Feb 19, 2016, at 6:01 PM, Baskin, Ilia <ibaskine at microstrategy.com<mailto:ibaskine at microstrategy.com>> wrote:

Hi,

I am experimenting with Keycloak to evaluate its suitability for our application. Here is one of my experiments, that got me warried:

I created a simple page (see attached), deployed it on Tomcat and registered it in Keycloak as confidential client. As you can see the page contains a button clicking on which executes simple XHR request. Notice that XHR request doesn?t contain Authorization header. On submission of my page URL I am redirected to Keycloak for authentication. After authentication I can submit XHR requests at will.

Now I copied my page and deployed the copy on the same Tomcat as a different totally unsecured application. If I open this page in another browser tab and click on XHR button it will go through without any problem. It looks to me as a typical CSRF case. Am I missing something here?

Thanks.
Ilia
<index.html>_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/c6d4c775/attachment-0001.html 

From srossillo at smartling.com  Fri Feb 19 18:26:41 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Fri, 19 Feb 2016 18:26:41 -0500
Subject: [keycloak-user] Spring Security - URL schema in "redirect_uri"
	generation
In-Reply-To: <CAMBdEymLn=FpoXh4uTyCKp4wKjCF1SjwoEhsNetX9yb-dH1k8w@mail.gmail.com>
References: <CAMBdEymLn=FpoXh4uTyCKp4wKjCF1SjwoEhsNetX9yb-dH1k8w@mail.gmail.com>
Message-ID: <47494416-B6D0-4629-9C10-079F478069B0@smartling.com>

It seems Wildfly isn?t aware of the fact that Nginx is handling secure connections.

Take a look at these posts:

http://lists.jboss.org/pipermail/keycloak-user/2016-January/004413.html <http://lists.jboss.org/pipermail/keycloak-user/2016-January/004413.html>
http://lists.jboss.org/pipermail/keycloak-user/2015-September/003104.html <http://lists.jboss.org/pipermail/keycloak-user/2015-September/003104.html>


Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Feb 19, 2016, at 10:56 AM, Andy Yar <andyyar66 at gmail.com> wrote:
> 
> Howdy,
> I use 1.8.0-Final integrated with Spring Security (which itself is integrated into Grails) using OpenID Connect method. The Keycloak and all integrated apps run behind a nginx SSL reverse proxy. Realm's SSL is set to: "ssl-required": "external".
> 
> My issue is related to initial "redirect_uri" generation. 
> 
> When I'm logged out and try to access a protected resource via a HTTPS request, I receive 302 response with Location URL starting with plain HTTP scheme. Apparently the Location goes to the "redirect_uri" attribute and therefore it tries to redirect me back here after a successful login.
> 
> Of course, it is possible to add both HTTP and HTTPS schemas as allowed redirect URI patterns. However, application's security gets lowered by that plain HTTP redirect...
> 
> Is there any easy solution for non-SSL Keycloak/apps running behind SSL reverse proxy? I haven't looked into the source code but it seems as a plain redirect which wouldn't be schema-aware.
> 
> Thanks in advance!
> Andy
> _______________________________________________
> 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/20160219/3153db8c/attachment.html 

From bburke at redhat.com  Fri Feb 19 22:44:35 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 Feb 2016 22:44:35 -0500
Subject: [keycloak-user] Is it CSRF vulnerability?
In-Reply-To: <CY1PR07MB2200DDEDFBE30B03413960A6C4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
References: <CY1PR07MB2200A3AC960FE1F7314D6F1AC4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
	<4D38F80E-FBFE-4757-9800-4F25F77AD5F7@smartling.com>
	<CY1PR07MB2200DDEDFBE30B03413960A6C4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
Message-ID: <56C7E123.7070409@redhat.com>

Look into CORS and how cross origin requests work.  If your script comes 
from the same origin as the target of the XHR, it will work fine.  No 
problem.  If the script is a different origin, the server will receive 
the request, but the script will not be able to see a response.  
Sometimes depending on browser and XHR request, an OPTIONS request is 
sent first.

Keycloak adapters have some support for CORS.  See docs.

On 2/19/2016 6:19 PM, Baskin, Ilia wrote:
>
> Scott,
>
> I know that, but this is exactly how CSRF works. There are several 
> simple ways to defend against CSRF and I am surprised that Keycloak, a 
> security application, doesn?t utilize any.
>
> Thanks.
>
> Ilia
>
> *From:*Scott Rossillo [mailto:srossillo at smartling.com]
> *Sent:* Friday, February 19, 2016 6:15 PM
> *To:* Baskin, Ilia
> *Cc:* keycloak-user at lists.jboss.org
> *Subject:* Re: [keycloak-user] Is it CSRF vulnerability?
>
> Once you?ve authenticated with Keycloak, your application has an 
> session id provided by Tomcat. This is why your requests are 
> succeeding. If you examine your XHR requests, I?d assume the session 
> id cookie is being passed to the server.
>
> Scott Rossillo
>
> Smartling | Senior Software Engineer
>
> srossillo at smartling.com <mailto:srossillo at smartling.com>
>
>     On Feb 19, 2016, at 6:01 PM, Baskin, Ilia
>     <ibaskine at microstrategy.com <mailto:ibaskine at microstrategy.com>>
>     wrote:
>
>     Hi,
>
>     I am experimenting with Keycloak to evaluate its suitability for
>     our application. Here is one of my experiments, that got me warried:
>
>     I created a simple page (see attached), deployed it on Tomcat and
>     registered it in Keycloak as confidential client. As you can see
>     the page contains a button clicking on which executes simple XHR
>     request. Notice that XHR request doesn?t contain Authorization
>     header. On submission of my page URL I am redirected to Keycloak
>     for authentication. After authentication I can submit XHR requests
>     at will.
>
>     Now I copied my page and deployed the copy on the same Tomcat as a
>     different totally unsecured application. If I open this page in
>     another browser tab and click on XHR button it will go through
>     without any problem. It looks to me as a typical CSRF case. Am I
>     missing something here?
>
>     Thanks.
>
>     Ilia
>
>     <index.html>_______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160219/d45b53c3/attachment.html 

From ha.hamed at gmail.com  Sat Feb 20 05:52:32 2016
From: ha.hamed at gmail.com (ha.hamed at gmail.com)
Date: Sat, 20 Feb 2016 18:52:32 +0800
Subject: [keycloak-user] Get username from keycloak session in NodeJS
Message-ID: <CAFyNp-zrHZQpgv3hjAqS2=209RKfgd20RvcNz2zZiBoD=8fL=Q@mail.gmail.com>

Hi,

Is there something similar to:

    request.getUserPrincipal().getName()       // Java

In Node to get username when we are using connect-keycloak with express
middle-ware?

Posted in stackoverflow.com
<http://stackoverflow.com/questions/35522154/get-username-from-keycloak-session-in-nodejs>

-- 
Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160220/2224595a/attachment-0001.html 

From srossillo at smartling.com  Sat Feb 20 10:29:25 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Sat, 20 Feb 2016 15:29:25 +0000
Subject: [keycloak-user] Is it CSRF vulnerability?
In-Reply-To: <CY1PR07MB2200DDEDFBE30B03413960A6C4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
References: <CY1PR07MB2200A3AC960FE1F7314D6F1AC4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
	<4D38F80E-FBFE-4757-9800-4F25F77AD5F7@smartling.com>
	<CY1PR07MB2200DDEDFBE30B03413960A6C4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
Message-ID: <CALAqdu_-ukc6pNtaxVoot2To2mc1tXrLdZhgjOeEiv8_OcG7aw@mail.gmail.com>

Are you using the Tomcat adapter? If so you have to configure Tomcats' CSRF
filter.

Once you've authenticated with an SSO server like Keycloak, you still have
to use platform specific CSRF

https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CSRF_Prevention_Filter

On Fri, Feb 19, 2016 at 6:19 PM Baskin, Ilia <ibaskine at microstrategy.com>
wrote:

> Scott,
>
>
>
> I know that, but this is exactly how CSRF works. There are several simple
> ways to defend against CSRF and I am surprised that Keycloak, a security
> application, doesn?t utilize any.
>
>
>
> Thanks.
>
> Ilia
>
>
>
> *From:* Scott Rossillo [mailto:srossillo at smartling.com]
> *Sent:* Friday, February 19, 2016 6:15 PM
> *To:* Baskin, Ilia
> *Cc:* keycloak-user at lists.jboss.org
> *Subject:* Re: [keycloak-user] Is it CSRF vulnerability?
>
>
>
> Once you?ve authenticated with Keycloak, your application has an session
> id provided by Tomcat. This is why your requests are succeeding. If you
> examine your XHR requests, I?d assume the session id cookie is being passed
> to the server.
>
>
>
>
>
> Scott Rossillo
>
> Smartling | Senior Software Engineer
>
> srossillo at smartling.com
>
>
>
> On Feb 19, 2016, at 6:01 PM, Baskin, Ilia <ibaskine at microstrategy.com>
> wrote:
>
>
>
> Hi,
>
>
>
> I am experimenting with Keycloak to evaluate its suitability for our
> application. Here is one of my experiments, that got me warried:
>
>
>
> I created a simple page (see attached), deployed it on Tomcat and
> registered it in Keycloak as confidential client. As you can see the page
> contains a button clicking on which executes simple XHR request. Notice
> that XHR request doesn?t contain Authorization header. On submission of my
> page URL I am redirected to Keycloak for authentication. After
> authentication I can submit XHR requests at will.
>
>
>
> Now I copied my page and deployed the copy on the same Tomcat as a
> different totally unsecured application. If I open this page in another
> browser tab and click on XHR button it will go through without any problem.
> It looks to me as a typical CSRF case. Am I missing something here?
>
>
>
> Thanks.
>
> Ilia
>
> <index.html>_______________________________________________
> 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/20160220/5f0ccb6c/attachment.html 

From tyvain at gmail.com  Sun Feb 21 21:55:38 2016
From: tyvain at gmail.com (=?UTF-8?Q?Sylvain_Auger=2DL=C3=A9ger?=)
Date: Mon, 22 Feb 2016 13:55:38 +1100
Subject: [keycloak-user] Multiple 'user' data-source ?
Message-ID: <CADjy338r4Pxd6vkfUAMvti8f6ND4YNcDT1+9Zq47y69oX6L0FA@mail.gmail.com>

Hi,

My company is aiming at building its own OpenId Connect provider, for our
internal apps.
Thus we are looking for an open source framework. KeyCloak seems very good.

Unfortunatly, we have a problem, and I did not find if KeyCloak can solve
it:

Our 'users' are store in an AD directory or in a database (postgree).
To sum up: if the user is not in the AD, then we should look in the databse
.

Is this doable with Keylcloak??

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/95897fe3/attachment.html 

From juraj.janosik77 at gmail.com  Mon Feb 22 02:17:39 2016
From: juraj.janosik77 at gmail.com (Juraj Janosik)
Date: Mon, 22 Feb 2016 08:17:39 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
Message-ID: <CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>

The user configuration has the possibility to Create/Read/Update/Delete of
"custom" attributes in the Admin Console.
(/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
The client does not. I think, the logic and the focus is the same for both.

Best regards,
Juraj


2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> We don't. Why would we add it though?
> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com> wrote:
>
>> Hi,
>>
>> is there any plan to support for displaying of "attributes" from Client
>> Representation
>> (like users configuration) in Admin Console?
>>
>> Thanks.
>>
>> Best Regards,
>> Juraj
>>
>> _______________________________________________
>> 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/20160222/b4dcbffe/attachment.html 

From mposolda at redhat.com  Mon Feb 22 03:07:43 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 22 Feb 2016 09:07:43 +0100
Subject: [keycloak-user] Multiple 'user' data-source ?
In-Reply-To: <CADjy338r4Pxd6vkfUAMvti8f6ND4YNcDT1+9Zq47y69oX6L0FA@mail.gmail.com>
References: <CADjy338r4Pxd6vkfUAMvti8f6ND4YNcDT1+9Zq47y69oX6L0FA@mail.gmail.com>
Message-ID: <56CAC1CF.2070501@redhat.com>

On 22/02/16 03:55, Sylvain Auger-L?ger wrote:
> Hi,
>
> My company is aiming at building its own OpenId Connect provider, for 
> our internal apps.
> Thus we are looking for an open source framework. KeyCloak seems very 
> good.
>
> Unfortunatly, we have a problem, and I did not find if KeyCloak can 
> solve it:
>
> Our 'users' are store in an AD directory or in a database (postgree).
> To sum up: if the user is not in the AD, then we should look in the 
> databse .
So you have 2 sets of existing users, first set in AD and second set in 
Postgres?

Yes, it is doable. You will need to write federationProvider for CRUD 
users from/to your postgres database (See docs and examples for details 
on how to create federationProvider). Then you can configure 2 
federation providers in your realm, the first with bigger priority will 
be LDAP/AD provider, the second will be your provider for postgres. We 
already have support for LDAP/AD (Again see docs).

Marek
>
> Is this doable with Keylcloak??
>
> Thanks.
>
>
> _______________________________________________
> 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/20160222/f00da966/attachment.html 

From thomas.darimont at googlemail.com  Mon Feb 22 03:12:22 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 22 Feb 2016 09:12:22 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
Message-ID: <CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>

Hello Juraj,

I wondered about that too a while ago - may I ask what client attributes
you are planning to store?

Cheers,
Thomas

2016-02-22 8:17 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:

> The user configuration has the possibility to Create/Read/Update/Delete of
> "custom" attributes in the Admin Console.
> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
> The client does not. I think, the logic and the focus is the same for both.
>
> Best regards,
> Juraj
>
>
> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> We don't. Why would we add it though?
>> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> is there any plan to support for displaying of "attributes" from Client
>>> Representation
>>> (like users configuration) in Admin Console?
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>> Juraj
>>>
>>> _______________________________________________
>>> 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/20160222/3dc882e3/attachment-0001.html 

From juraj.janosik77 at gmail.com  Mon Feb 22 04:02:51 2016
From: juraj.janosik77 at gmail.com (Juraj Janosik)
Date: Mon, 22 Feb 2016 10:02:51 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
Message-ID: <CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>

Hi Thomas,

for example security questions.... :-)

Best Regards,
Juraj



2016-02-22 9:12 GMT+01:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> Hello Juraj,
>
> I wondered about that too a while ago - may I ask what client attributes
> you are planning to store?
>
> Cheers,
> Thomas
>
> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:
>
>> The user configuration has the possibility to Create/Read/Update/Delete
>> of "custom" attributes in the Admin Console.
>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>> The client does not. I think, the logic and the focus is the same for
>> both.
>>
>> Best regards,
>> Juraj
>>
>>
>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>
>>> We don't. Why would we add it though?
>>> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> is there any plan to support for displaying of "attributes" from Client
>>>> Representation
>>>> (like users configuration) in Admin Console?
>>>>
>>>> Thanks.
>>>>
>>>> Best Regards,
>>>> Juraj
>>>>
>>>> _______________________________________________
>>>> 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/20160222/5ec450b9/attachment.html 

From sthorger at redhat.com  Mon Feb 22 04:03:46 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 Feb 2016 10:03:46 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
Message-ID: <CAJgngAeDR+Ok+p2hD5TqzdVXSQmKa8ckuOJ-mzidSWMmVfDpAg@mail.gmail.com>

On 22 February 2016 at 08:17, Juraj Janosik <juraj.janosik77 at gmail.com>
wrote:

> The user configuration has the possibility to Create/Read/Update/Delete of
> "custom" attributes in the Admin Console.
> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
> The client does not. I think, the logic and the focus is the same for both.
>

Not really - users support custom attributes, while client attributes are
only for internal use


>
> Best regards,
> Juraj
>
>
> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> We don't. Why would we add it though?
>> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> is there any plan to support for displaying of "attributes" from Client
>>> Representation
>>> (like users configuration) in Admin Console?
>>>
>>> Thanks.
>>>
>>> Best Regards,
>>> Juraj
>>>
>>> _______________________________________________
>>> 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/20160222/5f8e6f1d/attachment.html 

From sthorger at redhat.com  Mon Feb 22 04:05:42 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 Feb 2016 10:05:42 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
Message-ID: <CAJgngAc06wM04iui5k8BGBiA4N6bDmXAXbmG7CV6-ZXHr7C70A@mail.gmail.com>

Why do you have security questions attached to a client? They should be
attached to a user surely

On 22 February 2016 at 10:02, Juraj Janosik <juraj.janosik77 at gmail.com>
wrote:

> Hi Thomas,
>
> for example security questions.... :-)
>
> Best Regards,
> Juraj
>
>
>
> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <thomas.darimont at googlemail.com>
> :
>
>> Hello Juraj,
>>
>> I wondered about that too a while ago - may I ask what client attributes
>> you are planning to store?
>>
>> Cheers,
>> Thomas
>>
>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:
>>
>>> The user configuration has the possibility to Create/Read/Update/Delete
>>> of "custom" attributes in the Admin Console.
>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>> The client does not. I think, the logic and the focus is the same for
>>> both.
>>>
>>> Best regards,
>>> Juraj
>>>
>>>
>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>
>>>> We don't. Why would we add it though?
>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> is there any plan to support for displaying of "attributes" from
>>>>> Client Representation
>>>>> (like users configuration) in Admin Console?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>> Juraj
>>>>>
>>>>> _______________________________________________
>>>>> 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/20160222/f1a5d551/attachment.html 

From thomas.darimont at googlemail.com  Mon Feb 22 04:06:43 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 22 Feb 2016 10:06:43 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
Message-ID: <CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>

Interesting - do you need client specific security questions?

The keycloak examples contain a custom provider for user specific security
questions - perhaps this would suit your needs better.
https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator

Cheers,
Thomas

2016-02-22 10:02 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:

> Hi Thomas,
>
> for example security questions.... :-)
>
> Best Regards,
> Juraj
>
>
>
> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <thomas.darimont at googlemail.com>
> :
>
>> Hello Juraj,
>>
>> I wondered about that too a while ago - may I ask what client attributes
>> you are planning to store?
>>
>> Cheers,
>> Thomas
>>
>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:
>>
>>> The user configuration has the possibility to Create/Read/Update/Delete
>>> of "custom" attributes in the Admin Console.
>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>> The client does not. I think, the logic and the focus is the same for
>>> both.
>>>
>>> Best regards,
>>> Juraj
>>>
>>>
>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>
>>>> We don't. Why would we add it though?
>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> is there any plan to support for displaying of "attributes" from
>>>>> Client Representation
>>>>> (like users configuration) in Admin Console?
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Best Regards,
>>>>> Juraj
>>>>>
>>>>> _______________________________________________
>>>>> 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/20160222/c511121e/attachment-0001.html 

From bystrik.horvath at gmail.com  Mon Feb 22 04:18:18 2016
From: bystrik.horvath at gmail.com (Bystrik Horvath)
Date: Mon, 22 Feb 2016 10:18:18 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
Message-ID: <CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>

Hi,

I think the case here is to provision the text of security question to the
client attributes when it is not known in advance.

Best regards,
Bystrik

On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Interesting - do you need client specific security questions?
>
> The keycloak examples contain a custom provider for user specific security
> questions - perhaps this would suit your needs better.
>
> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>
> Cheers,
> Thomas
>
> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:
>
>> Hi Thomas,
>>
>> for example security questions.... :-)
>>
>> Best Regards,
>> Juraj
>>
>>
>>
>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <thomas.darimont at googlemail.com
>> >:
>>
>>> Hello Juraj,
>>>
>>> I wondered about that too a while ago - may I ask what client attributes
>>> you are planning to store?
>>>
>>> Cheers,
>>> Thomas
>>>
>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:
>>>
>>>> The user configuration has the possibility to Create/Read/Update/Delete
>>>> of "custom" attributes in the Admin Console.
>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>> The client does not. I think, the logic and the focus is the same for
>>>> both.
>>>>
>>>> Best regards,
>>>> Juraj
>>>>
>>>>
>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>
>>>>> We don't. Why would we add it though?
>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> is there any plan to support for displaying of "attributes" from
>>>>>> Client Representation
>>>>>> (like users configuration) in Admin Console?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Best Regards,
>>>>>> Juraj
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20160222/36753044/attachment.html 

From juraj.janosik77 at gmail.com  Mon Feb 22 04:20:46 2016
From: juraj.janosik77 at gmail.com (Juraj Janosik)
Date: Mon, 22 Feb 2016 10:20:46 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
Message-ID: <CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>

@ Stian:
generally said, I did not find any description, that the client attributes
are for internal use only.
Parameter "attributes" is propagated in ClientRepresentation in the REST
Admin API,
therefore should be used for CRUD admin operations.
We plan to attach Security Answers to the user (Security questions are
common for particular client).

Best Regards,
Juraj

2016-02-22 10:18 GMT+01:00 Bystrik Horvath <bystrik.horvath at gmail.com>:

> Hi,
>
> I think the case here is to provision the text of security question to the
> client attributes when it is not known in advance.
>
> Best regards,
> Bystrik
>
> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Interesting - do you need client specific security questions?
>>
>> The keycloak examples contain a custom provider for user specific
>> security questions - perhaps this would suit your needs better.
>>
>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>
>> Cheers,
>> Thomas
>>
>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:
>>
>>> Hi Thomas,
>>>
>>> for example security questions.... :-)
>>>
>>> Best Regards,
>>> Juraj
>>>
>>>
>>>
>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>> thomas.darimont at googlemail.com>:
>>>
>>>> Hello Juraj,
>>>>
>>>> I wondered about that too a while ago - may I ask what client
>>>> attributes you are planning to store?
>>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:
>>>>
>>>>> The user configuration has the possibility to
>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>> The client does not. I think, the logic and the focus is the same for
>>>>> both.
>>>>>
>>>>> Best regards,
>>>>> Juraj
>>>>>
>>>>>
>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>>
>>>>>> We don't. Why would we add it though?
>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> is there any plan to support for displaying of "attributes" from
>>>>>>> Client Representation
>>>>>>> (like users configuration) in Admin Console?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Juraj
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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/20160222/a1e2ca20/attachment.html 

From segatto at esteco.com  Mon Feb 22 04:31:00 2016
From: segatto at esteco.com (Alessandro Segatto)
Date: Mon, 22 Feb 2016 10:31:00 +0100
Subject: [keycloak-user] H2 with tcp configuration
Message-ID: <CALTKsRqy1u5DNDBxyMg7fDcnjUXu6Zd7A0sDw1vAX+mNVJv+Dg@mail.gmail.com>

Hi, when i configure keycloak to use a datasource usingi h2 over tcp (
jdbc:h2:tcp://localhost/~/h2/keycloak ) everything works fine, but when i
shutdown the application server and restart it the db is broken and promts
a primary key violation exception ...
Any ideas of why this is happening ?

Thanks ,
Alessandro S

-- 

Ing. Alessandro Segatto
Software Engineer
Research and Development

*ESTECO S.p.A.* - AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY
Phone: +39 040 3755548 - Fax: +39 040 3755549 | www.esteco.com

Pursuant to Legislative Decree No. 196/2003, you are hereby informed that
this message contains confidential information intended only for the use of
the addressee. If you are not the addressee, and have received this message
by mistake, please delete it and immediately notify us. You may not copy or
disseminate this message to anyone. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/36335399/attachment-0001.html 

From sthorger at redhat.com  Mon Feb 22 06:26:31 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 Feb 2016 12:26:31 +0100
Subject: [keycloak-user] H2 with tcp configuration
In-Reply-To: <CALTKsRqy1u5DNDBxyMg7fDcnjUXu6Zd7A0sDw1vAX+mNVJv+Dg@mail.gmail.com>
References: <CALTKsRqy1u5DNDBxyMg7fDcnjUXu6Zd7A0sDw1vAX+mNVJv+Dg@mail.gmail.com>
Message-ID: <CAJgngAeyUrFo5zjL+F+5Z2qHw9MJKDOJ14mhqVz5d4TiB4NKeQ@mail.gmail.com>

No, idea. We don't recommend using H2 though.

On 22 February 2016 at 10:31, Alessandro Segatto <segatto at esteco.com> wrote:

> Hi, when i configure keycloak to use a datasource usingi h2 over tcp (
> jdbc:h2:tcp://localhost/~/h2/keycloak ) everything works fine, but when i
> shutdown the application server and restart it the db is broken and promts
> a primary key violation exception ...
> Any ideas of why this is happening ?
>
> Thanks ,
> Alessandro S
>
> --
>
> Ing. Alessandro Segatto
> Software Engineer
> Research and Development
>
> *ESTECO S.p.A.* - AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY
> Phone: +39 040 3755548 - Fax: +39 040 3755549 | www.esteco.com
>
> Pursuant to Legislative Decree No. 196/2003, you are hereby informed that
> this message contains confidential information intended only for the use of
> the addressee. If you are not the addressee, and have received this message
> by mistake, please delete it and immediately notify us. You may not copy or
> disseminate this message to anyone. Thank you.
>
> _______________________________________________
> 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/20160222/0440ecbb/attachment.html 

From sthorger at redhat.com  Mon Feb 22 06:28:03 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 Feb 2016 12:28:03 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
	<CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
Message-ID: <CAJgngAdLyk=O8DY5go+m+B6+tJzbj0wnF362FG+=HOGQPYH81A@mail.gmail.com>

I don't understand how you can have security questions that are particular
to a client. A user logs-in to a realm, not a client.

On 22 February 2016 at 10:20, Juraj Janosik <juraj.janosik77 at gmail.com>
wrote:

> @ Stian:
> generally said, I did not find any description, that the client attributes
> are for internal use only.
> Parameter "attributes" is propagated in ClientRepresentation in the REST
> Admin API,
> therefore should be used for CRUD admin operations.
> We plan to attach Security Answers to the user (Security questions are
> common for particular client).
>
> Best Regards,
> Juraj
>
> 2016-02-22 10:18 GMT+01:00 Bystrik Horvath <bystrik.horvath at gmail.com>:
>
>> Hi,
>>
>> I think the case here is to provision the text of security question to
>> the client attributes when it is not known in advance.
>>
>> Best regards,
>> Bystrik
>>
>> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Interesting - do you need client specific security questions?
>>>
>>> The keycloak examples contain a custom provider for user specific
>>> security questions - perhaps this would suit your needs better.
>>>
>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>>
>>> Cheers,
>>> Thomas
>>>
>>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:
>>>
>>>> Hi Thomas,
>>>>
>>>> for example security questions.... :-)
>>>>
>>>> Best Regards,
>>>> Juraj
>>>>
>>>>
>>>>
>>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>>> thomas.darimont at googlemail.com>:
>>>>
>>>>> Hello Juraj,
>>>>>
>>>>> I wondered about that too a while ago - may I ask what client
>>>>> attributes you are planning to store?
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>>
>>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:
>>>>>
>>>>>> The user configuration has the possibility to
>>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>>> The client does not. I think, the logic and the focus is the same for
>>>>>> both.
>>>>>>
>>>>>> Best regards,
>>>>>> Juraj
>>>>>>
>>>>>>
>>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>>>
>>>>>>> We don't. Why would we add it though?
>>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> is there any plan to support for displaying of "attributes" from
>>>>>>>> Client Representation
>>>>>>>> (like users configuration) in Admin Console?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Juraj
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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/20160222/7385a44a/attachment.html 

From sthorger at redhat.com  Mon Feb 22 06:29:14 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 Feb 2016 12:29:14 +0100
Subject: [keycloak-user] Multiple 'user' data-source ?
In-Reply-To: <CADjy338r4Pxd6vkfUAMvti8f6ND4YNcDT1+9Zq47y69oX6L0FA@mail.gmail.com>
References: <CADjy338r4Pxd6vkfUAMvti8f6ND4YNcDT1+9Zq47y69oX6L0FA@mail.gmail.com>
Message-ID: <CAJgngAc2gWHY01t-M=u7uUnMQD5E1tYtz4kZev09-JJWY9Rs1g@mail.gmail.com>

On 22 February 2016 at 03:55, Sylvain Auger-L?ger <tyvain at gmail.com> wrote:

> Hi,
>
> My company is aiming at building its own OpenId Connect provider, for our
> internal apps.
> Thus we are looking for an open source framework. KeyCloak seems very good.
>

FIY Keycloak is an out of the box authentication server, with support for
OpenID Connect. There's some support for customizing it if required, but
it's not a framework to build your own OpenID Connect provider.


>
> Unfortunatly, we have a problem, and I did not find if KeyCloak can solve
> it:
>
> Our 'users' are store in an AD directory or in a database (postgree).
> To sum up: if the user is not in the AD, then we should look in the
> databse .
>
> Is this doable with Keylcloak??
>
> Thanks.
>
> _______________________________________________
> 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/20160222/893941cd/attachment.html 

From segatto at esteco.com  Mon Feb 22 06:29:35 2016
From: segatto at esteco.com (Alessandro Segatto)
Date: Mon, 22 Feb 2016 12:29:35 +0100
Subject: [keycloak-user] H2 with tcp configuration
In-Reply-To: <CAJgngAeyUrFo5zjL+F+5Z2qHw9MJKDOJ14mhqVz5d4TiB4NKeQ@mail.gmail.com>
References: <CALTKsRqy1u5DNDBxyMg7fDcnjUXu6Zd7A0sDw1vAX+mNVJv+Dg@mail.gmail.com>
	<CAJgngAeyUrFo5zjL+F+5Z2qHw9MJKDOJ14mhqVz5d4TiB4NKeQ@mail.gmail.com>
Message-ID: <CALTKsRoZrX-BvcxufsRGbVU8EE=SS4Er3LdB43DUpReQN0PCgA@mail.gmail.com>

Thanks, we will look forward to change DBMS.

On Mon, Feb 22, 2016 at 12:26 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> No, idea. We don't recommend using H2 though.
>
> On 22 February 2016 at 10:31, Alessandro Segatto <segatto at esteco.com>
> wrote:
>
>> Hi, when i configure keycloak to use a datasource usingi h2 over tcp (
>> jdbc:h2:tcp://localhost/~/h2/keycloak ) everything works fine, but when i
>> shutdown the application server and restart it the db is broken and promts
>> a primary key violation exception ...
>> Any ideas of why this is happening ?
>>
>> Thanks ,
>> Alessandro S
>>
>> --
>>
>> Ing. Alessandro Segatto
>> Software Engineer
>> Research and Development
>>
>> *ESTECO S.p.A.* - AREA Science Park, Padriciano 99 - 34149 Trieste -
>> ITALY
>> Phone: +39 040 3755548 - Fax: +39 040 3755549 | www.esteco.com
>>
>> Pursuant to Legislative Decree No. 196/2003, you are hereby informed that
>> this message contains confidential information intended only for the use of
>> the addressee. If you are not the addressee, and have received this message
>> by mistake, please delete it and immediately notify us. You may not copy or
>> disseminate this message to anyone. Thank you.
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>


-- 

Ing. Alessandro Segatto
Software Engineer
Research and Development

*ESTECO S.p.A.* - AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY
Phone: +39 040 3755548 - Fax: +39 040 3755549 | www.esteco.com

Pursuant to Legislative Decree No. 196/2003, you are hereby informed that
this message contains confidential information intended only for the use of
the addressee. If you are not the addressee, and have received this message
by mistake, please delete it and immediately notify us. You may not copy or
disseminate this message to anyone. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/386687f7/attachment-0001.html 

From akaya at expedia.com  Mon Feb 22 06:33:27 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Mon, 22 Feb 2016 11:33:27 +0000
Subject: [keycloak-user] Proxying SAML Login
Message-ID: <D2F12F27.2B4D%akaya@expedia.com>

Hi,

I have looked around but couldn't find what I was looking for.
What I want to do is when user wants to login with IDP I still want the user to login via Keycloak UI and I want Keycloak to proxy the IDP. What makes sense to me is to have something like a new client which will use OpenID and then this client would proxy it to the IDP itself. Is this possible? If so then how can I do it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/296ff469/attachment.html 

From segatto at esteco.com  Mon Feb 22 06:37:22 2016
From: segatto at esteco.com (Alessandro Segatto)
Date: Mon, 22 Feb 2016 12:37:22 +0100
Subject: [keycloak-user] Recaptcha in registration flow not working
Message-ID: <CALTKsRo2VvV2n5QuhsY7USWncPrZ=3X-DyxxErjyFz29UJn93A@mail.gmail.com>

When i enable recaptcha in registration flow , it doesn't work and the
following error appears in the chrome console :

>
> Refused to frame '
> https://www.google.com/recaptcha/api2/anchor?k=6LeM7RgTAAAAAMeBWtUVQ8rN5-5X?lZXBtbi5jb206ODQ0Mw..&hl=en&v=r20160216085053&size=compact&cb=9ebbd7aokijx'
> because it violates the following Content Security Policy directive:
> "frame-src 'self'".


I'm using version 1.7.0.Final.
Am i doing something wrong or I found a bug ? Thanks in advance

Alessandro S
-- 

Ing. Alessandro Segatto
Software Engineer
Research and Development

*ESTECO S.p.A.* - AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY
Phone: +39 040 3755548 - Fax: +39 040 3755549 | www.esteco.com

Pursuant to Legislative Decree No. 196/2003, you are hereby informed that
this message contains confidential information intended only for the use of
the addressee. If you are not the addressee, and have received this message
by mistake, please delete it and immediately notify us. You may not copy or
disseminate this message to anyone. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/f9acd9d8/attachment.html 

From bystrik.horvath at gmail.com  Mon Feb 22 07:24:51 2016
From: bystrik.horvath at gmail.com (Bystrik Horvath)
Date: Mon, 22 Feb 2016 13:24:51 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CAJgngAdmjMyMUSw6LG_5y_WaB+PPEsZb1WqQ3N_uMJcq3Kh-tw@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
	<CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
	<CAJgngAdLyk=O8DY5go+m+B6+tJzbj0wnF362FG+=HOGQPYH81A@mail.gmail.com>
	<CADjGaacaf+3tAPocJdsPno=X221UgRRd_X+yMkoH=91HLp8F8w@mail.gmail.com>
	<CAJgngAdmjMyMUSw6LG_5y_WaB+PPEsZb1WqQ3N_uMJcq3Kh-tw@mail.gmail.com>
Message-ID: <CADjGaafD9p=jzOVnBEMwpvJKS7VzMYTpQD1Ujgr+Vnj5A=xpUA@mail.gmail.com>

Hi,

I went through the example (
https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator).
The security questions are written in secret-question.ftl
and secret-question-config.ftl files. From my point of view, the security
questions are know in advance and they can be "hardcoded" in ftl files. My
case is that security questions are defined during the runtime (preferably
via  admin REST API). The admin REST API does not provide the functionality
to store attributes on realm level. I agree that security questions belongs
to realm, but how to provision them - *.ftl files are not an option for me.

Best regards,
Bystrik

On Mon, Feb 22, 2016 at 12:55 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> If you look at our security questions example it stores the configuration
> on the authenticator itself.
>
> On 22 February 2016 at 12:46, Bystrik Horvath <bystrik.horvath at gmail.com>
> wrote:
>
>> Hi,
>>
>> what would be a recommended way to provision a security question on realm
>> base if the question is not known in advance? May be it is an misuse of
>> client representation for provisioning that.
>>
>> Best regards,
>> Bystrik
>>
>> On Mon, Feb 22, 2016 at 12:28 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> I don't understand how you can have security questions that are
>>> particular to a client. A user logs-in to a realm, not a client.
>>>
>>> On 22 February 2016 at 10:20, Juraj Janosik <juraj.janosik77 at gmail.com>
>>> wrote:
>>>
>>>> @ Stian:
>>>> generally said, I did not find any description, that the client
>>>> attributes are for internal use only.
>>>> Parameter "attributes" is propagated in ClientRepresentation in the
>>>> REST Admin API,
>>>> therefore should be used for CRUD admin operations.
>>>> We plan to attach Security Answers to the user (Security questions are
>>>> common for particular client).
>>>>
>>>> Best Regards,
>>>> Juraj
>>>>
>>>> 2016-02-22 10:18 GMT+01:00 Bystrik Horvath <bystrik.horvath at gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think the case here is to provision the text of security question to
>>>>> the client attributes when it is not known in advance.
>>>>>
>>>>> Best regards,
>>>>> Bystrik
>>>>>
>>>>> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>
>>>>>> Interesting - do you need client specific security questions?
>>>>>>
>>>>>> The keycloak examples contain a custom provider for user specific
>>>>>> security questions - perhaps this would suit your needs better.
>>>>>>
>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>>>>>
>>>>>> Cheers,
>>>>>> Thomas
>>>>>>
>>>>>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>:
>>>>>>
>>>>>>> Hi Thomas,
>>>>>>>
>>>>>>> for example security questions.... :-)
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Juraj
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>>>>>> thomas.darimont at googlemail.com>:
>>>>>>>
>>>>>>>> Hello Juraj,
>>>>>>>>
>>>>>>>> I wondered about that too a while ago - may I ask what client
>>>>>>>> attributes you are planning to store?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>
>>>>>>>> :
>>>>>>>>
>>>>>>>>> The user configuration has the possibility to
>>>>>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>>>>>>
>>>>>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>>>>>> The client does not. I think, the logic and the focus is the same
>>>>>>>>> for both.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Juraj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>>>>>>
>>>>>>>>>> We don't. Why would we add it though?
>>>>>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> is there any plan to support for displaying of "attributes" from
>>>>>>>>>>> Client Representation
>>>>>>>>>>> (like users configuration) in Admin Console?
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Juraj
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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/20160222/317ce2fb/attachment.html 

From sthorger at redhat.com  Mon Feb 22 07:39:53 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 Feb 2016 13:39:53 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CADjGaafD9p=jzOVnBEMwpvJKS7VzMYTpQD1Ujgr+Vnj5A=xpUA@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
	<CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
	<CAJgngAdLyk=O8DY5go+m+B6+tJzbj0wnF362FG+=HOGQPYH81A@mail.gmail.com>
	<CADjGaacaf+3tAPocJdsPno=X221UgRRd_X+yMkoH=91HLp8F8w@mail.gmail.com>
	<CAJgngAdmjMyMUSw6LG_5y_WaB+PPEsZb1WqQ3N_uMJcq3Kh-tw@mail.gmail.com>
	<CADjGaafD9p=jzOVnBEMwpvJKS7VzMYTpQD1Ujgr+Vnj5A=xpUA@mail.gmail.com>
Message-ID: <CAJgngAdD6_iA_cFob0dKU+vJm84BfY8K-woUjaHJr=20gAXjSA@mail.gmail.com>

I thought the example did allow configuring the security question on the
authenticator, but you can create your own that does it. Then the security
questions are configured on the authenticator itself.

On 22 February 2016 at 13:24, Bystrik Horvath <bystrik.horvath at gmail.com>
wrote:

> Hi,
>
> I went through the example (
> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator).
> The security questions are written in secret-question.ftl
> and secret-question-config.ftl files. From my point of view, the security
> questions are know in advance and they can be "hardcoded" in ftl files. My
> case is that security questions are defined during the runtime (preferably
> via  admin REST API). The admin REST API does not provide the functionality
> to store attributes on realm level. I agree that security questions belongs
> to realm, but how to provision them - *.ftl files are not an option for me.
>
> Best regards,
> Bystrik
>
> On Mon, Feb 22, 2016 at 12:55 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> If you look at our security questions example it stores the configuration
>> on the authenticator itself.
>>
>> On 22 February 2016 at 12:46, Bystrik Horvath <bystrik.horvath at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> what would be a recommended way to provision a security question on
>>> realm base if the question is not known in advance? May be it is an misuse
>>> of client representation for provisioning that.
>>>
>>> Best regards,
>>> Bystrik
>>>
>>> On Mon, Feb 22, 2016 at 12:28 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> I don't understand how you can have security questions that are
>>>> particular to a client. A user logs-in to a realm, not a client.
>>>>
>>>> On 22 February 2016 at 10:20, Juraj Janosik <juraj.janosik77 at gmail.com>
>>>> wrote:
>>>>
>>>>> @ Stian:
>>>>> generally said, I did not find any description, that the client
>>>>> attributes are for internal use only.
>>>>> Parameter "attributes" is propagated in ClientRepresentation in the
>>>>> REST Admin API,
>>>>> therefore should be used for CRUD admin operations.
>>>>> We plan to attach Security Answers to the user (Security questions are
>>>>> common for particular client).
>>>>>
>>>>> Best Regards,
>>>>> Juraj
>>>>>
>>>>> 2016-02-22 10:18 GMT+01:00 Bystrik Horvath <bystrik.horvath at gmail.com>
>>>>> :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I think the case here is to provision the text of security question
>>>>>> to the client attributes when it is not known in advance.
>>>>>>
>>>>>> Best regards,
>>>>>> Bystrik
>>>>>>
>>>>>> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>
>>>>>>> Interesting - do you need client specific security questions?
>>>>>>>
>>>>>>> The keycloak examples contain a custom provider for user specific
>>>>>>> security questions - perhaps this would suit your needs better.
>>>>>>>
>>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Thomas
>>>>>>>
>>>>>>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com>
>>>>>>> :
>>>>>>>
>>>>>>>> Hi Thomas,
>>>>>>>>
>>>>>>>> for example security questions.... :-)
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Juraj
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>>>>>>> thomas.darimont at googlemail.com>:
>>>>>>>>
>>>>>>>>> Hello Juraj,
>>>>>>>>>
>>>>>>>>> I wondered about that too a while ago - may I ask what client
>>>>>>>>> attributes you are planning to store?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com
>>>>>>>>> >:
>>>>>>>>>
>>>>>>>>>> The user configuration has the possibility to
>>>>>>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>>>>>>>
>>>>>>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>>>>>>> The client does not. I think, the logic and the focus is the same
>>>>>>>>>> for both.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Juraj
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>
>>>>>>>>>> :
>>>>>>>>>>
>>>>>>>>>>> We don't. Why would we add it though?
>>>>>>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <juraj.janosik77 at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> is there any plan to support for displaying of "attributes"
>>>>>>>>>>>> from Client Representation
>>>>>>>>>>>> (like users configuration) in Admin Console?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Juraj
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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/20160222/b39490e9/attachment-0001.html 

From bystrik.horvath at gmail.com  Mon Feb 22 07:46:51 2016
From: bystrik.horvath at gmail.com (Bystrik Horvath)
Date: Mon, 22 Feb 2016 13:46:51 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CAJgngAdD6_iA_cFob0dKU+vJm84BfY8K-woUjaHJr=20gAXjSA@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
	<CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
	<CAJgngAdLyk=O8DY5go+m+B6+tJzbj0wnF362FG+=HOGQPYH81A@mail.gmail.com>
	<CADjGaacaf+3tAPocJdsPno=X221UgRRd_X+yMkoH=91HLp8F8w@mail.gmail.com>
	<CAJgngAdmjMyMUSw6LG_5y_WaB+PPEsZb1WqQ3N_uMJcq3Kh-tw@mail.gmail.com>
	<CADjGaafD9p=jzOVnBEMwpvJKS7VzMYTpQD1Ujgr+Vnj5A=xpUA@mail.gmail.com>
	<CAJgngAdD6_iA_cFob0dKU+vJm84BfY8K-woUjaHJr=20gAXjSA@mail.gmail.com>
Message-ID: <CADjGaacM4HouMKBsBJoS0oxWBgvoTAn00VQPdyhkANdYc2Vzgw@mail.gmail.com>

I think I got it. If I'm not mistaken, the configuration of authenticator
is then stored via admin REST API using AuthenticatorConfigRepresentation.

Thank you&Best regards,
Bystrik

On Mon, Feb 22, 2016 at 1:39 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> I thought the example did allow configuring the security question on the
> authenticator, but you can create your own that does it. Then the security
> questions are configured on the authenticator itself.
>
> On 22 February 2016 at 13:24, Bystrik Horvath <bystrik.horvath at gmail.com>
> wrote:
>
>> Hi,
>>
>> I went through the example (
>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator).
>> The security questions are written in secret-question.ftl
>> and secret-question-config.ftl files. From my point of view, the security
>> questions are know in advance and they can be "hardcoded" in ftl files. My
>> case is that security questions are defined during the runtime (preferably
>> via  admin REST API). The admin REST API does not provide the functionality
>> to store attributes on realm level. I agree that security questions belongs
>> to realm, but how to provision them - *.ftl files are not an option for me.
>>
>> Best regards,
>> Bystrik
>>
>> On Mon, Feb 22, 2016 at 12:55 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> If you look at our security questions example it stores the
>>> configuration on the authenticator itself.
>>>
>>> On 22 February 2016 at 12:46, Bystrik Horvath <bystrik.horvath at gmail.com
>>> > wrote:
>>>
>>>> Hi,
>>>>
>>>> what would be a recommended way to provision a security question on
>>>> realm base if the question is not known in advance? May be it is an misuse
>>>> of client representation for provisioning that.
>>>>
>>>> Best regards,
>>>> Bystrik
>>>>
>>>> On Mon, Feb 22, 2016 at 12:28 PM, Stian Thorgersen <sthorger at redhat.com
>>>> > wrote:
>>>>
>>>>> I don't understand how you can have security questions that are
>>>>> particular to a client. A user logs-in to a realm, not a client.
>>>>>
>>>>> On 22 February 2016 at 10:20, Juraj Janosik <juraj.janosik77 at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> @ Stian:
>>>>>> generally said, I did not find any description, that the client
>>>>>> attributes are for internal use only.
>>>>>> Parameter "attributes" is propagated in ClientRepresentation in the
>>>>>> REST Admin API,
>>>>>> therefore should be used for CRUD admin operations.
>>>>>> We plan to attach Security Answers to the user (Security questions
>>>>>> are common for particular client).
>>>>>>
>>>>>> Best Regards,
>>>>>> Juraj
>>>>>>
>>>>>> 2016-02-22 10:18 GMT+01:00 Bystrik Horvath <bystrik.horvath at gmail.com
>>>>>> >:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I think the case here is to provision the text of security question
>>>>>>> to the client attributes when it is not known in advance.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Bystrik
>>>>>>>
>>>>>>> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
>>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>>
>>>>>>>> Interesting - do you need client specific security questions?
>>>>>>>>
>>>>>>>> The keycloak examples contain a custom provider for user specific
>>>>>>>> security questions - perhaps this would suit your needs better.
>>>>>>>>
>>>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com
>>>>>>>> >:
>>>>>>>>
>>>>>>>>> Hi Thomas,
>>>>>>>>>
>>>>>>>>> for example security questions.... :-)
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Juraj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>>>>>>>> thomas.darimont at googlemail.com>:
>>>>>>>>>
>>>>>>>>>> Hello Juraj,
>>>>>>>>>>
>>>>>>>>>> I wondered about that too a while ago - may I ask what client
>>>>>>>>>> attributes you are planning to store?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Thomas
>>>>>>>>>>
>>>>>>>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <
>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> The user configuration has the possibility to
>>>>>>>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>>>>>>>>
>>>>>>>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>>>>>>>> The client does not. I think, the logic and the focus is the
>>>>>>>>>>> same for both.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Juraj
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com
>>>>>>>>>>> >:
>>>>>>>>>>>
>>>>>>>>>>>> We don't. Why would we add it though?
>>>>>>>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <
>>>>>>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> is there any plan to support for displaying of "attributes"
>>>>>>>>>>>>> from Client Representation
>>>>>>>>>>>>> (like users configuration) in Admin Console?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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/20160222/1b4c72fa/attachment.html 

From thomas.darimont at googlemail.com  Mon Feb 22 07:48:00 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 22 Feb 2016 13:48:00 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CAJgngAdD6_iA_cFob0dKU+vJm84BfY8K-woUjaHJr=20gAXjSA@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
	<CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
	<CAJgngAdLyk=O8DY5go+m+B6+tJzbj0wnF362FG+=HOGQPYH81A@mail.gmail.com>
	<CADjGaacaf+3tAPocJdsPno=X221UgRRd_X+yMkoH=91HLp8F8w@mail.gmail.com>
	<CAJgngAdmjMyMUSw6LG_5y_WaB+PPEsZb1WqQ3N_uMJcq3Kh-tw@mail.gmail.com>
	<CADjGaafD9p=jzOVnBEMwpvJKS7VzMYTpQD1Ujgr+Vnj5A=xpUA@mail.gmail.com>
	<CAJgngAdD6_iA_cFob0dKU+vJm84BfY8K-woUjaHJr=20gAXjSA@mail.gmail.com>
Message-ID: <CAK-7U1hqdiqQjeTfCp_nUeehQdrDsPb1Qptqf+oWOPE9Ghc07g@mail.gmail.com>

You could define the set of secret questions on the authenticator - you
could either hardcode them or make them configurable by implementing
ConfiguredProvider see [0].
Then you could store a reference to the selected secret question and the
answer as a custom user-attribute.

Cheers,

Thomas

[0] -
https://github.com/keycloak/keycloak/blob/60f9f73c4ca2ddf4ad49ff53a03a63dca8148ea9/server-spi/src/main/java/org/keycloak/provider/ConfiguredProvider.java#L26

Stian Thorgersen <sthorger at redhat.com> schrieb am Mo., 22. Feb. 2016, 13:40:

> I thought the example did allow configuring the security question on the
> authenticator, but you can create your own that does it. Then the security
> questions are configured on the authenticator itself.
>
> On 22 February 2016 at 13:24, Bystrik Horvath <bystrik.horvath at gmail.com>
> wrote:
>
>> Hi,
>>
>> I went through the example (
>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator).
>> The security questions are written in secret-question.ftl
>> and secret-question-config.ftl files. From my point of view, the security
>> questions are know in advance and they can be "hardcoded" in ftl files. My
>> case is that security questions are defined during the runtime (preferably
>> via  admin REST API). The admin REST API does not provide the functionality
>> to store attributes on realm level. I agree that security questions belongs
>> to realm, but how to provision them - *.ftl files are not an option for me.
>>
>> Best regards,
>> Bystrik
>>
>> On Mon, Feb 22, 2016 at 12:55 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> If you look at our security questions example it stores the
>>> configuration on the authenticator itself.
>>>
>>> On 22 February 2016 at 12:46, Bystrik Horvath <bystrik.horvath at gmail.com
>>> > wrote:
>>>
>>>> Hi,
>>>>
>>>> what would be a recommended way to provision a security question on
>>>> realm base if the question is not known in advance? May be it is an misuse
>>>> of client representation for provisioning that.
>>>>
>>>> Best regards,
>>>> Bystrik
>>>>
>>>> On Mon, Feb 22, 2016 at 12:28 PM, Stian Thorgersen <sthorger at redhat.com
>>>> > wrote:
>>>>
>>>>> I don't understand how you can have security questions that are
>>>>> particular to a client. A user logs-in to a realm, not a client.
>>>>>
>>>>> On 22 February 2016 at 10:20, Juraj Janosik <juraj.janosik77 at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> @ Stian:
>>>>>> generally said, I did not find any description, that the client
>>>>>> attributes are for internal use only.
>>>>>> Parameter "attributes" is propagated in ClientRepresentation in the
>>>>>> REST Admin API,
>>>>>> therefore should be used for CRUD admin operations.
>>>>>> We plan to attach Security Answers to the user (Security questions
>>>>>> are common for particular client).
>>>>>>
>>>>>> Best Regards,
>>>>>> Juraj
>>>>>>
>>>>>> 2016-02-22 10:18 GMT+01:00 Bystrik Horvath <bystrik.horvath at gmail.com
>>>>>> >:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I think the case here is to provision the text of security question
>>>>>>> to the client attributes when it is not known in advance.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Bystrik
>>>>>>>
>>>>>>> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
>>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>>
>>>>>>>> Interesting - do you need client specific security questions?
>>>>>>>>
>>>>>>>> The keycloak examples contain a custom provider for user specific
>>>>>>>> security questions - perhaps this would suit your needs better.
>>>>>>>>
>>>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <juraj.janosik77 at gmail.com
>>>>>>>> >:
>>>>>>>>
>>>>>>>>> Hi Thomas,
>>>>>>>>>
>>>>>>>>> for example security questions.... :-)
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Juraj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>>>>>>>> thomas.darimont at googlemail.com>:
>>>>>>>>>
>>>>>>>>>> Hello Juraj,
>>>>>>>>>>
>>>>>>>>>> I wondered about that too a while ago - may I ask what client
>>>>>>>>>> attributes you are planning to store?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Thomas
>>>>>>>>>>
>>>>>>>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <
>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> The user configuration has the possibility to
>>>>>>>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>>>>>>>>
>>>>>>>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>>>>>>>> The client does not. I think, the logic and the focus is the
>>>>>>>>>>> same for both.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Juraj
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <sthorger at redhat.com
>>>>>>>>>>> >:
>>>>>>>>>>>
>>>>>>>>>>>> We don't. Why would we add it though?
>>>>>>>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <
>>>>>>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> is there any plan to support for displaying of "attributes"
>>>>>>>>>>>>> from Client Representation
>>>>>>>>>>>>> (like users configuration) in Admin Console?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/a78c9da9/attachment-0001.html 

From bystrik.horvath at gmail.com  Mon Feb 22 07:58:44 2016
From: bystrik.horvath at gmail.com (Bystrik Horvath)
Date: Mon, 22 Feb 2016 13:58:44 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CAK-7U1hqdiqQjeTfCp_nUeehQdrDsPb1Qptqf+oWOPE9Ghc07g@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
	<CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
	<CAJgngAdLyk=O8DY5go+m+B6+tJzbj0wnF362FG+=HOGQPYH81A@mail.gmail.com>
	<CADjGaacaf+3tAPocJdsPno=X221UgRRd_X+yMkoH=91HLp8F8w@mail.gmail.com>
	<CAJgngAdmjMyMUSw6LG_5y_WaB+PPEsZb1WqQ3N_uMJcq3Kh-tw@mail.gmail.com>
	<CADjGaafD9p=jzOVnBEMwpvJKS7VzMYTpQD1Ujgr+Vnj5A=xpUA@mail.gmail.com>
	<CAJgngAdD6_iA_cFob0dKU+vJm84BfY8K-woUjaHJr=20gAXjSA@mail.gmail.com>
	<CAK-7U1hqdiqQjeTfCp_nUeehQdrDsPb1Qptqf+oWOPE9Ghc07g@mail.gmail.com>
Message-ID: <CADjGaadXezH5kURnkP87c8g6opKnkb0Zzek3P-W2TwnV42-mng@mail.gmail.com>

Thank you guys for the answers, I think you & Stian directed me to the
right way, so it should solve my requirements.

Best regards,
Bystrik



On Mon, Feb 22, 2016 at 1:48 PM, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> You could define the set of secret questions on the authenticator - you
> could either hardcode them or make them configurable by implementing
> ConfiguredProvider see [0].
> Then you could store a reference to the selected secret question and the
> answer as a custom user-attribute.
>
> Cheers,
>
> Thomas
>
> [0] -
> https://github.com/keycloak/keycloak/blob/60f9f73c4ca2ddf4ad49ff53a03a63dca8148ea9/server-spi/src/main/java/org/keycloak/provider/ConfiguredProvider.java#L26
>
> Stian Thorgersen <sthorger at redhat.com> schrieb am Mo., 22. Feb. 2016,
> 13:40:
>
>> I thought the example did allow configuring the security question on the
>> authenticator, but you can create your own that does it. Then the security
>> questions are configured on the authenticator itself.
>>
>> On 22 February 2016 at 13:24, Bystrik Horvath <bystrik.horvath at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I went through the example (
>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator).
>>> The security questions are written in secret-question.ftl
>>> and secret-question-config.ftl files. From my point of view, the security
>>> questions are know in advance and they can be "hardcoded" in ftl files. My
>>> case is that security questions are defined during the runtime (preferably
>>> via  admin REST API). The admin REST API does not provide the functionality
>>> to store attributes on realm level. I agree that security questions belongs
>>> to realm, but how to provision them - *.ftl files are not an option for me.
>>>
>>> Best regards,
>>> Bystrik
>>>
>>> On Mon, Feb 22, 2016 at 12:55 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> If you look at our security questions example it stores the
>>>> configuration on the authenticator itself.
>>>>
>>>> On 22 February 2016 at 12:46, Bystrik Horvath <
>>>> bystrik.horvath at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> what would be a recommended way to provision a security question on
>>>>> realm base if the question is not known in advance? May be it is an misuse
>>>>> of client representation for provisioning that.
>>>>>
>>>>> Best regards,
>>>>> Bystrik
>>>>>
>>>>> On Mon, Feb 22, 2016 at 12:28 PM, Stian Thorgersen <
>>>>> sthorger at redhat.com> wrote:
>>>>>
>>>>>> I don't understand how you can have security questions that are
>>>>>> particular to a client. A user logs-in to a realm, not a client.
>>>>>>
>>>>>> On 22 February 2016 at 10:20, Juraj Janosik <
>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>
>>>>>>> @ Stian:
>>>>>>> generally said, I did not find any description, that the client
>>>>>>> attributes are for internal use only.
>>>>>>> Parameter "attributes" is propagated in ClientRepresentation in the
>>>>>>> REST Admin API,
>>>>>>> therefore should be used for CRUD admin operations.
>>>>>>> We plan to attach Security Answers to the user (Security questions
>>>>>>> are common for particular client).
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Juraj
>>>>>>>
>>>>>>> 2016-02-22 10:18 GMT+01:00 Bystrik Horvath <
>>>>>>> bystrik.horvath at gmail.com>:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I think the case here is to provision the text of security question
>>>>>>>> to the client attributes when it is not known in advance.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Bystrik
>>>>>>>>
>>>>>>>> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
>>>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>>>
>>>>>>>>> Interesting - do you need client specific security questions?
>>>>>>>>>
>>>>>>>>> The keycloak examples contain a custom provider for user specific
>>>>>>>>> security questions - perhaps this would suit your needs better.
>>>>>>>>>
>>>>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <
>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>
>>>>>>>>>> Hi Thomas,
>>>>>>>>>>
>>>>>>>>>> for example security questions.... :-)
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Juraj
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>>>>>>>>> thomas.darimont at googlemail.com>:
>>>>>>>>>>
>>>>>>>>>>> Hello Juraj,
>>>>>>>>>>>
>>>>>>>>>>> I wondered about that too a while ago - may I ask what client
>>>>>>>>>>> attributes you are planning to store?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Thomas
>>>>>>>>>>>
>>>>>>>>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <
>>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> The user configuration has the possibility to
>>>>>>>>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>>>>>>>>>
>>>>>>>>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>>>>>>>>> The client does not. I think, the logic and the focus is the
>>>>>>>>>>>> same for both.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Juraj
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <
>>>>>>>>>>>> sthorger at redhat.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> We don't. Why would we add it though?
>>>>>>>>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <
>>>>>>>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> is there any plan to support for displaying of "attributes"
>>>>>>>>>>>>>> from Client Representation
>>>>>>>>>>>>>> (like users configuration) in Admin Console?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing list
>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/d3c94d50/attachment.html 

From leo.nunes at gjccorp.com.br  Mon Feb 22 08:44:46 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Mon, 22 Feb 2016 13:44:46 +0000
Subject: [keycloak-user] KeycloakSecurityContext returns NULL using
	Tomcat Adapter
In-Reply-To: <CAJgngAfFTpg+ciX0Gh-jL1RkwxYaY2qGYjYVhNUGhX6DFDp4HA@mail.gmail.com>
Message-ID: <D2F0952C.269BD%leo.nunes@ojc.com.br>

Hi everyone,

This problem might stop me from using Keycloak, it's been a week since i'm trying to find a way to make it work but I couldn't find any.
If it's a container issue, is there another way to make it work?

What can I do to access information from the current logged in user at a page that is not secured at the security-contraints at web.xml?
The code below returns null at pages that is not secured, even when the user is logged in.
If the application is deployed to Wildfly it works, but it doesn't work at Jboss EAP and Apache Tomcat.

(KeycloakPrincipal) req.getUserPrincipal()
Or
(KeycloakSecurityContext) req.getAttribute(KeycloakSecurityContext.class.getName())


All of our applications is deployed to Jboss EAP and Apache Tomcat.


--
Leonardo


From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: quinta-feira, 18 de fevereiro de 2016 11:12
To: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: KeycloakSecurityContext returns NULL using Tomcat Adapter

This is down to the fact that there are differences between different containers. In reality you can only guarantee that KeycloakSecurityContext as long as the request requires authentication. Add a security-constraint for movies and you're fine.

On 18 February 2016 at 12:50, LEONARDO NUNES <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>> wrote:
Stian,

I have an application deployed on Tomcat 7 using the Tomcat Adapter.
When i'm logged in and I go to a non-secured URL, KeycloakSecurityContext returns null.
I deployed the same application to the Keycloak Standalone Server, there I don't have this problem.

At Tomcat the code below returns null when called from /movies/, and works when called from /article/
At Keycloak Standalone Server /movies/ and /article/ works fine.
(KeycloakSecurityContext) request.getAttribute(KeycloakSecurityContext.class.getName());

Why is this happening?

In my web.xml I have only one security-constraint securing /article/*

WEB.XML:
<security-constraint>
    <web-resource-collection>
        <web-resource-name>Articles</web-resource-name>
        <url-pattern>/article/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>user</role-name>
    </auth-constraint>
</security-constraint>


--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/6ee60048/attachment-0001.html 

From mail at christianbauer.name  Mon Feb 22 09:02:10 2016
From: mail at christianbauer.name (Christian Bauer)
Date: Mon, 22 Feb 2016 15:02:10 +0100
Subject: [keycloak-user] Create client in master realm with API
Message-ID: <89CBDCC1-CED7-4C99-87FD-D308EE819D68@christianbauer.name>

Hi

I'm trying to implement a multi-tenant system that should use Keycloak, from its Docker image. I'd like to use the Keycloak admin API from another container. My first goal is to create a new client in the master realm for my tenant administration app, then create realms for each tenant, etc. 

To do this I'm using the admin-cli client in the master realm with public direct grant authentication, and I can get an authentication token with superuser roles for the admin user.

Next I tried to POST /auth/realms/master/clients/default with a client representation and the admin-cli bearer token. This is forbidden, because though I have superuser roles, I don't have the Constants.REALM_MANAGEMENT_CLIENT_ID resource roles required in ClientRegistrationAuth:177.

I'm not sure I'm doing this right. The console web UI probably has the same roles if I'm logged in as admin and it's able to create users.

I guess I could step further through the code to find the difference. Other options I've considered:

- Don't create a new client in the master realm and continue using the admin-cli client for superuser tasks. 

- Adjust the Docker image bootstrap so it exports the initial database, then manipulate the exported files with some JSON transformer, then import again.

- Hacking the themes/Angular frontend of the security-admin-console and use this to implement my tenant/user administration app. 

Thoughts?



From bburke at redhat.com  Mon Feb 22 09:04:18 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Feb 2016 09:04:18 -0500
Subject: [keycloak-user] Proxying SAML Login
In-Reply-To: <D2F12F27.2B4D%akaya@expedia.com>
References: <D2F12F27.2B4D%akaya@expedia.com>
Message-ID: <56CB1562.2090106@redhat.com>

Check the identity providers tab.  You can set u "IDP Federation". 
Social login is under there too.

On 2/22/2016 6:33 AM, Sarp Kaya wrote:
> Hi,
>
> I have looked around but couldn?t find what I was looking for.
> What I want to do is when user wants to login with IDP I still want 
> the user to login via Keycloak UI and I want Keycloak to proxy the 
> IDP. What makes sense to me is to have something like a new client 
> which will use OpenID and then this client would proxy it to the IDP 
> itself. Is this possible? If so then how can I do it?
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/c78c92fa/attachment.html 

From bburke at redhat.com  Mon Feb 22 09:05:12 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Feb 2016 09:05:12 -0500
Subject: [keycloak-user] Recaptcha in registration flow not working
In-Reply-To: <CALTKsRo2VvV2n5QuhsY7USWncPrZ=3X-DyxxErjyFz29UJn93A@mail.gmail.com>
References: <CALTKsRo2VvV2n5QuhsY7USWncPrZ=3X-DyxxErjyFz29UJn93A@mail.gmail.com>
Message-ID: <56CB1598.1000707@redhat.com>

Read the documentation:

http://keycloak.github.io/docs/userguide/keycloak-server/html/recaptcha.html

On 2/22/2016 6:37 AM, Alessandro Segatto wrote:
> When i enable recaptcha in registration flow , it doesn't work and the 
> following error appears in the chrome console :
>
>
>     Refused to frame
>     'https://www.google.com/recaptcha/api2/anchor?k=6LeM7RgTAAAAAMeBWtUVQ8rN5-5X?lZXBtbi5jb206ODQ0Mw..&hl=en&v=r20160216085053&size=compact&cb=9ebbd7aokijx'
>     because it violates the following Content Security Policy
>     directive: "frame-src 'self'".
>
>
> I'm using version 1.7.0.Final.
> Am i doing something wrong or I found a bug ? Thanks in advance
>
> Alessandro S
> -- 
>
> Ing. Alessandro Segatto
> Software Engineer
> Research and Development*
> *
> *ESTECO S.p.A.* - AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY
> Phone: +39 040 3755548 - Fax: +39 040 3755549 | www.esteco.com 
> <http://www.esteco.com/>
>
> Pursuant to Legislative Decree No. 196/2003, you are hereby informed 
> that this message contains confidential information intended only for 
> the use of the addressee. If you are not the addressee, and have 
> received this message by mistake, please delete it and immediately 
> notify us. You may not copy or disseminate this message to anyone. 
> Thank you.
>
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/4cb245d7/attachment.html 

From segatto at esteco.com  Mon Feb 22 09:11:33 2016
From: segatto at esteco.com (Alessandro Segatto)
Date: Mon, 22 Feb 2016 15:11:33 +0100
Subject: [keycloak-user] Recaptcha in registration flow not working
In-Reply-To: <56CB1598.1000707@redhat.com>
References: <CALTKsRo2VvV2n5QuhsY7USWncPrZ=3X-DyxxErjyFz29UJn93A@mail.gmail.com>
	<56CB1598.1000707@redhat.com>
Message-ID: <CALTKsRrW9SVS8b1ha8D8-bVom93-p82ushWs95kOEAMde9rghQ@mail.gmail.com>

Thanks

On Mon, Feb 22, 2016 at 3:05 PM, Bill Burke <bburke at redhat.com> wrote:

> Read the documentation:
>
>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/recaptcha.html
>
>
> On 2/22/2016 6:37 AM, Alessandro Segatto wrote:
>
> When i enable recaptcha in registration flow , it doesn't work and the
> following error appears in the chrome console :
>
>>
>> Refused to frame '
>> <https://www.google.com/recaptcha/api2/anchor?k=6LeM7RgTAAAAAMeBWtUVQ8rN5-5X>
>> https://www.google.com/recaptcha/api2/anchor?k=6LeM7RgTAAAAAMeBWtUVQ8rN5-5X?lZXBtbi5jb206ODQ0Mw..&hl=en&v=r20160216085053&size=compact&cb=9ebbd7aokijx'
>> because it violates the following Content Security Policy directive:
>> "frame-src 'self'".
>
>
> I'm using version 1.7.0.Final.
> Am i doing something wrong or I found a bug ? Thanks in advance
>
> Alessandro S
> --
>
> Ing. Alessandro Segatto
> Software Engineer
> Research and Development
>
> *ESTECO S.p.A.* - AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY
> Phone: +39 040 3755548 - Fax: +39 040 3755549 |  <http://www.esteco.com/>
> www.esteco.com
>
> Pursuant to Legislative Decree No. 196/2003, you are hereby informed that
> this message contains confidential information intended only for the use of
> the addressee. If you are not the addressee, and have received this message
> by mistake, please delete it and immediately notify us. You may not copy or
> disseminate this message to anyone. Thank you.
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>



-- 

Ing. Alessandro Segatto
Software Engineer
Research and Development

*ESTECO S.p.A.* - AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY
Phone: +39 040 3755548 - Fax: +39 040 3755549 | www.esteco.com

Pursuant to Legislative Decree No. 196/2003, you are hereby informed that
this message contains confidential information intended only for the use of
the addressee. If you are not the addressee, and have received this message
by mistake, please delete it and immediately notify us. You may not copy or
disseminate this message to anyone. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/1e6eebd7/attachment-0001.html 

From leo.nunes at gjccorp.com.br  Mon Feb 22 09:16:15 2016
From: leo.nunes at gjccorp.com.br (LEONARDO NUNES)
Date: Mon, 22 Feb 2016 14:16:15 +0000
Subject: [keycloak-user] KeycloakSecurityContext returns NULL using
	Tomcat Adapter
In-Reply-To: <D2F0952C.269BD%leo.nunes@ojc.com.br>
Message-ID: <D2F09A75.269E3%leo.nunes@ojc.com.br>

Hi I just saw your response asking me to open a Jira.

I have just opened now.
https://issues.jboss.org/browse/KEYCLOAK-2518

This is very important for us to continue the project to put Keycloak into production at our company.

Thank you.


--

Att,
Leonardo Nunes
Analista de Sistemas
leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>
Skype: leonardo.puc
+55 (62) 3250-1462

Grupo Jaime C?mara
www.gjccorp.com.br<applewebdata://B0E38BB5-8499-4F51-929B-00F21C9F6683/www.gjccorp.com.br>

From: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>
Date: segunda-feira, 22 de fevereiro de 2016 10:44
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: KeycloakSecurityContext returns NULL using Tomcat Adapter

Hi everyone,

This problem might stop me from using Keycloak, it's been a week since i'm trying to find a way to make it work but I couldn't find any.
If it's a container issue, is there another way to make it work?

What can I do to access information from the current logged in user at a page that is not secured at the security-contraints at web.xml?
The code below returns null at pages that is not secured, even when the user is logged in.
If the application is deployed to Wildfly it works, but it doesn't work at Jboss EAP and Apache Tomcat.

(KeycloakPrincipal) req.getUserPrincipal()
Or
(KeycloakSecurityContext) req.getAttribute(KeycloakSecurityContext.class.getName())


All of our applications is deployed to Jboss EAP and Apache Tomcat.


--
Leonardo


From: Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>>
Reply-To: "stian at redhat.com<mailto:stian at redhat.com>" <stian at redhat.com<mailto:stian at redhat.com>>
Date: quinta-feira, 18 de fevereiro de 2016 11:12
To: Leonardo Nunes <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: KeycloakSecurityContext returns NULL using Tomcat Adapter

This is down to the fact that there are differences between different containers. In reality you can only guarantee that KeycloakSecurityContext as long as the request requires authentication. Add a security-constraint for movies and you're fine.

On 18 February 2016 at 12:50, LEONARDO NUNES <leo.nunes at gjccorp.com.br<mailto:leo.nunes at gjccorp.com.br>> wrote:
Stian,

I have an application deployed on Tomcat 7 using the Tomcat Adapter.
When i'm logged in and I go to a non-secured URL, KeycloakSecurityContext returns null.
I deployed the same application to the Keycloak Standalone Server, there I don't have this problem.

At Tomcat the code below returns null when called from /movies/, and works when called from /article/
At Keycloak Standalone Server /movies/ and /article/ works fine.
(KeycloakSecurityContext) request.getAttribute(KeycloakSecurityContext.class.getName());

Why is this happening?

In my web.xml I have only one security-constraint securing /article/*

WEB.XML:
<security-constraint>
    <web-resource-collection>
        <web-resource-name>Articles</web-resource-name>
        <url-pattern>/article/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>user</role-name>
    </auth-constraint>
</security-constraint>


--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/a9acbdd0/attachment.html 

From bburke at redhat.com  Mon Feb 22 10:09:51 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Feb 2016 10:09:51 -0500
Subject: [keycloak-user] Create client in master realm with API
In-Reply-To: <89CBDCC1-CED7-4C99-87FD-D308EE819D68@christianbauer.name>
References: <89CBDCC1-CED7-4C99-87FD-D308EE819D68@christianbauer.name>
Message-ID: <56CB24BF.4030501@redhat.com>

What do you mean when you say you have "super user" roles?

* Your user is in the master realm?
* Which exact roles are assigned to this user?

BTW, is this THE Christian Bauer of Hibernate fame?  If so, how's life?

On 2/22/2016 9:02 AM, Christian Bauer wrote:
> Hi
>
> I'm trying to implement a multi-tenant system that should use Keycloak, from its Docker image. I'd like to use the Keycloak admin API from another container. My first goal is to create a new client in the master realm for my tenant administration app, then create realms for each tenant, etc.
>
> To do this I'm using the admin-cli client in the master realm with public direct grant authentication, and I can get an authentication token with superuser roles for the admin user.
>
> Next I tried to POST /auth/realms/master/clients/default with a client representation and the admin-cli bearer token. This is forbidden, because though I have superuser roles, I don't have the Constants.REALM_MANAGEMENT_CLIENT_ID resource roles required in ClientRegistrationAuth:177.
>
> I'm not sure I'm doing this right. The console web UI probably has the same roles if I'm logged in as admin and it's able to create users.
>
> I guess I could step further through the code to find the difference. Other options I've considered:
>
> - Don't create a new client in the master realm and continue using the admin-cli client for superuser tasks.
>
> - Adjust the Docker image bootstrap so it exports the initial database, then manipulate the exported files with some JSON transformer, then import again.
>
> - Hacking the themes/Angular frontend of the security-admin-console and use this to implement my tenant/user administration app.
>
> Thoughts?
>
>
> _______________________________________________
> 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 aikeaguinea at xsmail.com  Mon Feb 22 10:10:31 2016
From: aikeaguinea at xsmail.com (Aikeaguinea)
Date: Mon, 22 Feb 2016 10:10:31 -0500
Subject: [keycloak-user] Securely setting admin passwords
Message-ID: <1456153831.1343667.528300426.5376354D@webmail.messagingengine.com>

With regard to Docker, things get more complicated. I believe it's
not just the bash history but the Docker history itself that stores
the commands.

Also, per one of the messages earlier on this chain, it is not advised
to put secrets into Docker environment variables. These are accessible
in many different ways.

*From:?*<keycloak-user-bounces at lists.jboss.org> on behalf of Stan
Silvert <ssilvert at redhat.com> *Date:?*Thursday, February 18, 2016 at
12:26 PM *To:?*"stian at redhat.com" <stian at redhat.com> *Cc:?*Stian
Thorgersen <sthorger at redhat.com>, keycloak-user <keycloak-
user at lists.jboss.org> *Subject:?*Re: [keycloak-user] Securely setting
admin passwords

On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
> It's security vs usability as usual. Allowing passing the password
> directly is convenient for developers, for Docker image, for
> provisioning tools, etc.. So we're not going to remove that it's
> required, but I do appreciate that if not used correctly it's a
> potential security risk. The worst case scenario here is really that
> someone gets an admins favorite password, as someone that has access
> to getting the bash history of that particular user will also be able
> to run the add-user script themselves. So if the admin wants to print
> his favorite password in clear text in the bash history we should not
> stop him.
>
> It's not our responsibility to clear the bash history, so we should
> not do that either.
If there is a way to stop that one command from being saved in the bash
history then we should do it.

At the very least, we should print a warning message to let the
administrator know he has done something that is potentially insecure.

>
> On 18 February 2016 at 16:53, Bruno Oliveira
> <bruno at abstractj.org>?wrote:
>> It's about balance. I'm not arguing here against it, I just don't see
>> how it could strengthen security. Nothing will stop people to get
>> their own gun and automate it with stdin :)
>>
>> On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert
>> <ssilvert at redhat.com> wrote:
>>> On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>>>> I can be wrong, but this is not only our responsibility. For
>>>> example, on Linux you are prompted for the password with passwd,
>>>> but at the same time you could circumvent this using: echo 12345678
>>>> | sudo passwd admin --stdin.
>>>>
>>>> In this scenario security auditors won't blame the OS for this, but
>>>> pretty much sysadmins and bad security practices. Anyways, whatever
>>>> people think is the best, I'm fine.
>>> I agree with you there.? In that case you are doing something extra
>>> to shoot yourself in the foot.? We can't guard against that.
>>>
>>> We just shouldn't put the gun in your hand.
>>>
>>>>
>>>> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com>
>>>> wrote:
>>>>> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>>>>> I think the Jira created by Stian pretty much fixes the problem.
>>>>>> Nope?
>>>>> Stian's JIRA says that if it is not specified on the command line
>>>>> then do the prompt.? But if we still allow setting it from the
>>>>> command line then the password can still be saved to the log in
>>>>> plain text.? Security auditors will always frown on that.
>>>>>
>>>>> So I'm saying we should either disallow setting on the command
>>>>> line or somehow disable saving to the log.? We shouldn't rely on
>>>>> an administrator to do the right thing.
>>>>>
>>>>>
>>>>>>
>>>>>> Something like:
>>>>>>
>>>>>> ./add-user-keycloak.sh -u user Password: ******
>>>>>>
>>>>>> Or
>>>>>>
>>>>>> ./add-user-keycloak-sh Username: joe Password: ******
>>>>>>
>>>>>> If this can't fix the issue, is also possible to disable
>>>>>> bash_history temporarily. But I wouldn't take this route, because
>>>>>> this is pretty much system administration responsibility.
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert
>>>>>> <ssilvert at redhat.com> wrote:
>>>>>>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 17 February 2016 at 17:09, Aikeaguinea
>>>>>>>> <aikeaguinea at xsmail.com>?wrote:
>>>>>>>>> It seems the add-user.sh? script for changing the admin
>>>>>>>>> password only accepts the password as a -p command-line
>>>>>>>>> parameter. This would expose the password in the command
>>>>>>>>> history, so I'd prefer not to use the command in its current
>>>>>>>>> form.
>>>>>>>>
>>>>>>>> That's a mistake we'll fix that. If not specified it should
>>>>>>>> prompt for it. Added
>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-2501
>>>>>>> After attending several security talks the last couple of days,
>>>>>>> I've become rather sensitized to this kind of issue.? I feel
>>>>>>> quite strongly that we should never allow the password to be
>>>>>>> written to history in plain text.?? I'm also afraid it could
>>>>>>> cause us to flunk government certifications.
>>>>>>>
>>>>>>> On Windows, this really isn't a problem because command history
>>>>>>> is not saved.? After a CMD session ends, the history is lost
>>>>>>> (unless you install some third-party tool).
>>>>>>>
>>>>>>> Perhaps there is a way to temporarily disable logging of command
>>>>>>> history in the add-user-keycloak.sh?
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is there another way to do this?
>>>>>>>>>
>>>>>>>>> The situation is even more complicated with Docker, since
>>>>>>>>> running the script to change the Wildfly admin password
>>>>>>>>> requires restarting the server, which shuts down the
>>>>>>>>> container. If you have an autoscaling group, the container
>>>>>>>>> that gets brought up is not the container where you changed
>>>>>>>>> the password, but instead the original container. This seems
>>>>>>>>> to mean that the only way to have Keycloak run in Dockers in
>>>>>>>>> an autoscaling group is to bake the admin passwords into the
>>>>>>>>> Docker image beforehand. This isn't ideal; less so if the only
>>>>>>>>> way to add those passwords during build time is to run the
>>>>>>>>> shell script that exposes the password on the command line.
>>>>>>>>
>>>>>>>> You need to set the password once for your database. This can
>>>>>>>> be done prior to accessing the admin console the first time.
>>>>>>>> Take a look at
>>>>>>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>>>>>>> you can use docker exec to do this.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://www.fastmail.com[1]?- Access your email from home and
>>>>>>>>> the web
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing list keycloak-user at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list keycloak-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>
>>
>> _______________________________________________
>> keycloak-user mailing list keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user




Links:

  1. http://www.fastmail.com/

-- 
http://www.fastmail.com - Choose from over 50 domains or use your own

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/e8cc9131/attachment-0001.html 

From bburke at redhat.com  Mon Feb 22 10:21:08 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Feb 2016 10:21:08 -0500
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <1456153831.1343667.528300426.5376354D@webmail.messagingengine.com>
References: <1456153831.1343667.528300426.5376354D@webmail.messagingengine.com>
Message-ID: <56CB2764.8030002@redhat.com>

I'm too lazy to read this entire thread, sorry if somebody already 
suggested this, but can't you

1) Create a minimal realm in your local environment and export the realm 
to json.
2) Import this json in your Docker script?



On 2/22/2016 10:10 AM, Aikeaguinea wrote:
> With regard to Docker, things get more complicated. I believe it's not 
> just the bash history but the Docker history itself that stores the 
> commands.
> Also, per one of the messages earlier on this chain, it is not advised 
> to put secrets into Docker environment variables. These are accessible 
> in many different ways.
> *From: *<keycloak-user-bounces at lists.jboss.org 
> <mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Stan 
> Silvert <ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
> *Date: *Thursday, February 18, 2016 at 12:26 PM
> *To: *"stian at redhat.com <mailto:stian at redhat.com>" <stian at redhat.com 
> <mailto:stian at redhat.com>>
> *Cc: *Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>>, keycloak-user 
> <keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>>
> *Subject: *Re: [keycloak-user] Securely setting admin passwords
> On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
>> It's security vs usability as usual. Allowing passing the password 
>> directly is convenient for developers, for Docker image, for 
>> provisioning tools, etc.. So we're not going to remove that it's 
>> required, but I do appreciate that if not used correctly it's a 
>> potential security risk. The worst case scenario here is really that 
>> someone gets an admins favorite password, as someone that has access 
>> to getting the bash history of that particular user will also be able 
>> to run the add-user script themselves. So if the admin wants to print 
>> his favorite password in clear text in the bash history we should not 
>> stop him.
>> It's not our responsibility to clear the bash history, so we should 
>> not do that either.
> If there is a way to stop that one command from being saved in the 
> bash history then we should do it.
> At the very least, we should print a warning message to let the 
> administrator know he has done something that is potentially insecure.
>> On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org 
>> <mailto:bruno at abstractj.org>> wrote:
>>
>>     It's about balance. I'm not arguing here against it, I just don't
>>     see how it could strengthen security. Nothing will stop people to
>>     get their own gun and automate it with stdin :)
>>     On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert
>>     <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>
>>         On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>>>         I can be wrong, but this is not only our responsibility. For
>>>         example, on Linux you are prompted for the password with
>>>         passwd, but at the same time you could circumvent this
>>>         using: echo 12345678 | sudo passwd admin --stdin.
>>>         In this scenario security auditors won't blame the OS for
>>>         this, but pretty much sysadmins and bad security practices.
>>>         Anyways, whatever people think is the best, I'm fine.
>>         I agree with you there.  In that case you are doing something
>>         extra to shoot yourself in the foot.  We can't guard against
>>         that.
>>         We just shouldn't put the gun in your hand.
>>>         On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert
>>>         <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>             On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>>>             I think the Jira created by Stian pretty much fixes the
>>>>             problem. Nope?
>>>             Stian's JIRA says that if it is not specified on the
>>>             command line then do the prompt.  But if we still allow
>>>             setting it from the command line then the password can
>>>             still be saved to the log in plain text.  Security
>>>             auditors will always frown on that.
>>>             So I'm saying we should either disallow setting on the
>>>             command line or somehow disable saving to the log.  We
>>>             shouldn't rely on an administrator to do the right thing.
>>>>             Something like:
>>>>             ./add-user-keycloak.sh -u user
>>>>             Password: ******
>>>>             Or
>>>>             ./add-user-keycloak-sh
>>>>             Username: joe
>>>>             Password: ******
>>>>             If this can't fix the issue, is also possible to
>>>>             disable bash_history temporarily. But I wouldn't take
>>>>             this route, because this is pretty much system
>>>>             administration responsibility.
>>>>             On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert
>>>>             <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>>>
>>>>                 On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>>>                 On 17 February 2016 at 17:09, Aikeaguinea
>>>>>                 <aikeaguinea at xsmail.com
>>>>>                 <mailto:aikeaguinea at xsmail.com>> wrote:
>>>>>
>>>>>                     It seems the add-user.sh script for changing
>>>>>                     the admin password only
>>>>>                     accepts the password as a -p command-line
>>>>>                     parameter. This would expose
>>>>>                     the password in the command history, so I'd
>>>>>                     prefer not to use the
>>>>>                     command in its current form.
>>>>>
>>>>>                 That's a mistake we'll fix that. If not specified
>>>>>                 it should prompt for it. Added
>>>>>                 https://issues.jboss.org/browse/KEYCLOAK-2501
>>>>                 After attending several security talks the last
>>>>                 couple of days, I've become rather sensitized to
>>>>                 this kind of issue.  I feel quite strongly that we
>>>>                 should never allow the password to be written to
>>>>                 history in plain text. I'm also afraid it could
>>>>                 cause us to flunk government certifications.
>>>>                 On Windows, this really isn't a problem because
>>>>                 command history is not saved.  After a CMD session
>>>>                 ends, the history is lost (unless you install some
>>>>                 third-party tool).
>>>>                 Perhaps there is a way to temporarily disable
>>>>                 logging of command history in the add-user-keycloak.sh?
>>>>>
>>>>>                     Is there another way to do this?
>>>>>                     The situation is even more complicated with
>>>>>                     Docker, since running the
>>>>>                     script to change the Wildfly admin password
>>>>>                     requires restarting the
>>>>>                     server, which shuts down the container. If you
>>>>>                     have an autoscaling
>>>>>                     group, the container that gets brought up is
>>>>>                     not the container where you
>>>>>                     changed the password, but instead the original
>>>>>                     container. This seems to
>>>>>                     mean that the only way to have Keycloak run in
>>>>>                     Dockers in an autoscaling
>>>>>                     group is to bake the admin passwords into the
>>>>>                     Docker image beforehand.
>>>>>                     This isn't ideal; less so if the only way to
>>>>>                     add those passwords during
>>>>>                     build time is to run the shell script that
>>>>>                     exposes the password on the
>>>>>                     command line.
>>>>>
>>>>>                 You need to set the password once for your
>>>>>                 database. This can be done prior to accessing the
>>>>>                 admin console the first time. Take a look at
>>>>>                 https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>>>>                 you can use docker exec to do this.
>>>>>
>>>>>
>>>>>                     --
>>>>>                     http://www.fastmail.com
>>>>>                     <http://www.fastmail.com/> - Access your email
>>>>>                     from home and the web
>>>>>
>>>>>                     _______________________________________________
>>>>>                     keycloak-user mailing list
>>>>>                     keycloak-user at lists.jboss.org
>>>>>                     <mailto:keycloak-user at lists.jboss.org>
>>>>>                     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>                 _______________________________________________
>>>>>                 keycloak-user mailing list
>>>>>                 keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>                 <mailto:keycloak-user at lists.jboss.org>
>>>>                 _______________________________________________
>>>>                 keycloak-user mailing list
>>>>                 keycloak-user at lists.jboss.org
>>>>                 <mailto:keycloak-user at lists.jboss.org>
>>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
> -- 
> http://www.fastmail.com - Choose from over 50 domains or use your own
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/d2a2c976/attachment-0001.html 

From mail at christianbauer.name  Mon Feb 22 10:21:44 2016
From: mail at christianbauer.name (Christian Bauer)
Date: Mon, 22 Feb 2016 16:21:44 +0100
Subject: [keycloak-user] Create client in master realm with API
In-Reply-To: <mailman.14001.1456153836.3326.keycloak-user@lists.jboss.org>
References: <mailman.14001.1456153836.3326.keycloak-user@lists.jboss.org>
Message-ID: <DCA704F1-D432-4C50-BFE3-A7572BFF8B90@christianbauer.name>

Hi Bill, long time no see. Seems like we are both stuck with this Java thing. :)

I'm authenticating with the admin user/password which I've set as env variables when starting Docker container. Nothing else was changed on the default install. This is the access token:

{
    "jti": "285d19a2-8ae3-4e0e-b05f-454d04c7812c",
    "exp": 1.456140094E9,
    "nbf": 0,
    "iat": 1.456140034E9,
    "iss": "http://192.168.99.100:8082/auth/realms/master",
    "aud": "admin-cli",
    "sub": "1219f695-bf7a-4496-a021-52586de58ed5",
    "typ": "Bearer",
    "azp": "admin-cli",
    "session_state": "22d4dc19-e755-4ce0-9508-66ffad608215",
    "client_session": "97f937f9-9fce-4441-9684-46d5daa262ce",
    "allowed-origins": [
        
    ],
    "realm_access": {
        "roles": [
            "create-realm",
            "admin"
        ]
    },
    "resource_access": {
        "master-realm": {
            "roles": [
                "view-identity-providers",
                "manage-events",
                "view-realm",
                "manage-realm",
                "manage-identity-providers",
                "impersonation",
                "view-events",
                "create-client",
                "manage-users",
                "view-users",
                "view-clients",
                "manage-clients"
            ]
        }
    },
    "name": "",
    "preferred_username": "admin"
}

That looks like it should give me superuser access. But POSTing with that token on "/auth/realms/master/clients/default" is Forbidden, because ClientRegistrationAuth.java checks for "realm-management" resource claims and not "master-realm":

Map<String, List<String>> realmManagement = resourceAccess.get(Constants.REALM_MANAGEMENT_CLIENT_ID);
if (realmManagement == null) {
    return false;
}

As I said, I might be doing something wrong but I don't know where else to look. I haven't figured out yet how the user/roles/client etc. mappings work.

> On 22.02.2016, at 16:10, keycloak-user-request at lists.jboss.org wrote:
> 
> What do you mean when you say you have "super user" roles?
> 
> * Your user is in the master realm?
> * Which exact roles are assigned to this user?
> 
> BTW, is this THE Christian Bauer of Hibernate fame?  If so, how's life?
> 
> On 2/22/2016 9:02 AM, Christian Bauer wrote:
>> Hi
>> 
>> I'm trying to implement a multi-tenant system that should use Keycloak, from its Docker image. I'd like to use the Keycloak admin API from another container. My first goal is to create a new client in the master realm for my tenant administration app, then create realms for each tenant, etc.
>> 
>> To do this I'm using the admin-cli client in the master realm with public direct grant authentication, and I can get an authentication token with superuser roles for the admin user.
>> 
>> Next I tried to POST /auth/realms/master/clients/default with a client representation and the admin-cli bearer token. This is forbidden, because though I have superuser roles, I don't have the Constants.REALM_MANAGEMENT_CLIENT_ID resource roles required in ClientRegistrationAuth:177.
>> 
>> I'm not sure I'm doing this right. The console web UI probably has the same roles if I'm logged in as admin and it's able to create users.
>> 
>> I guess I could step further through the code to find the difference. Other options I've considered:
>> 
>> - Don't create a new client in the master realm and continue using the admin-cli client for superuser tasks.
>> 
>> - Adjust the Docker image bootstrap so it exports the initial database, then manipulate the exported files with some JSON transformer, then import again.
>> 
>> - Hacking the themes/Angular frontend of the security-admin-console and use this to implement my tenant/user administration app.
>> 
>> Thoughts?
>> 
>> 
>> _______________________________________________
>> 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 ibaskine at microstrategy.com  Mon Feb 22 10:20:46 2016
From: ibaskine at microstrategy.com (Baskin, Ilia)
Date: Mon, 22 Feb 2016 15:20:46 +0000
Subject: [keycloak-user] Is it CSRF vulnerability?
In-Reply-To: <CALAqdu_-ukc6pNtaxVoot2To2mc1tXrLdZhgjOeEiv8_OcG7aw@mail.gmail.com>
References: <CY1PR07MB2200A3AC960FE1F7314D6F1AC4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
	<4D38F80E-FBFE-4757-9800-4F25F77AD5F7@smartling.com>
	<CY1PR07MB2200DDEDFBE30B03413960A6C4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
	<CALAqdu_-ukc6pNtaxVoot2To2mc1tXrLdZhgjOeEiv8_OcG7aw@mail.gmail.com>
Message-ID: <CY1PR07MB22001156C074D18D75A47D2BC4A30@CY1PR07MB2200.namprd07.prod.outlook.com>

Thanks Scott,

As far as I understand now the Chapter 22. Security Vulnerabilities of Keycloak documentation talks about the security of authentication workflow. I believe it will be nice if you added clear explanation of what security the adapters provide and don?t provide after authentication.

Thanks
Ilia

From: Scott Rossillo [mailto:srossillo at smartling.com]
Sent: Saturday, February 20, 2016 10:29 AM
To: Baskin, Ilia
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] Is it CSRF vulnerability?

Are you using the Tomcat adapter? If so you have to configure Tomcats' CSRF filter.

Once you've authenticated with an SSO server like Keycloak, you still have to use platform specific CSRF

https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CSRF_Prevention_Filter

On Fri, Feb 19, 2016 at 6:19 PM Baskin, Ilia <ibaskine at microstrategy.com<mailto:ibaskine at microstrategy.com>> wrote:
Scott,

I know that, but this is exactly how CSRF works. There are several simple ways to defend against CSRF and I am surprised that Keycloak, a security application, doesn?t utilize any.

Thanks.
Ilia

From: Scott Rossillo [mailto:srossillo at smartling.com<mailto:srossillo at smartling.com>]
Sent: Friday, February 19, 2016 6:15 PM
To: Baskin, Ilia
Cc: keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Is it CSRF vulnerability?

Once you?ve authenticated with Keycloak, your application has an session id provided by Tomcat. This is why your requests are succeeding. If you examine your XHR requests, I?d assume the session id cookie is being passed to the server.


Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com<mailto:srossillo at smartling.com>

On Feb 19, 2016, at 6:01 PM, Baskin, Ilia <ibaskine at microstrategy.com<mailto:ibaskine at microstrategy.com>> wrote:

Hi,

I am experimenting with Keycloak to evaluate its suitability for our application. Here is one of my experiments, that got me warried:

I created a simple page (see attached), deployed it on Tomcat and registered it in Keycloak as confidential client. As you can see the page contains a button clicking on which executes simple XHR request. Notice that XHR request doesn?t contain Authorization header. On submission of my page URL I am redirected to Keycloak for authentication. After authentication I can submit XHR requests at will.

Now I copied my page and deployed the copy on the same Tomcat as a different totally unsecured application. If I open this page in another browser tab and click on XHR button it will go through without any problem. It looks to me as a typical CSRF case. Am I missing something here?

Thanks.
Ilia
<index.html>_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/7ec495ab/attachment-0001.html 

From aikeaguinea at xsmail.com  Mon Feb 22 10:32:09 2016
From: aikeaguinea at xsmail.com (Aikeaguinea)
Date: Mon, 22 Feb 2016 10:32:09 -0500
Subject: [keycloak-user] Securely setting admin passwords
Message-ID: <1456155129.1348870.528320818.68611749@webmail.messagingengine.com>

We're essentially doing this. Since we need to secure the Wildfly admin
password as well, we are basically running the add-user.sh scripts to
generate the keycloak-user.json and mgmt-users.properties before running
the Docker script, and then adding them to the image. This has the
disadvantage of baking the passwords into the image, but at least
they're encrypted and the image is stored in a secure repository, which
is probably as good as we're going to get.



From: <keycloak-user-bounces at lists.jboss.org> on behalf of Bill Burke
<bburke at redhat.com>
Date: Monday, February 22, 2016 at 10:21 AM
To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Securely setting admin passwords

I'm too lazy to read this entire thread, sorry if somebody already
suggested this, but can't you

1) Create a minimal realm in your local environment and export the realm
to json.
2) Import this json in your Docker script?



On 2/22/2016 10:10 AM, Aikeaguinea wrote:
With regard to Docker, things get more complicated. I believe it's not
just the bash history but the Docker history itself that stores the
commands. 
 
Also, per one of the messages earlier on this chain, it is not advised
to put secrets into Docker environment variables. These are accessible
in many different ways.
 
From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stan Silvert
<ssilvert at redhat.com>
Date: Thursday, February 18, 2016 at 12:26 PM
To: "stian at redhat.com" <stian at redhat.com>
Cc: Stian Thorgersen <sthorger at redhat.com>, keycloak-user
<keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Securely setting admin passwords
 
On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
It's security vs usability as usual. Allowing passing the password
directly is convenient for developers, for Docker image, for
provisioning tools, etc.. So we're not going to remove that it's
required, but I do appreciate that if not used correctly it's a
potential security risk. The worst case scenario here is really that
someone gets an admins favorite password, as someone that has access to
getting the bash history of that particular user will also be able to
run the add-user script themselves. So if the admin wants to print his
favorite password in clear text in the bash history we should not stop
him. 
 
It's not our responsibility to clear the bash history, so we should not
do that either. 
If there is a way to stop that one command from being saved in the bash
history then we should do it.  
 
At the very least, we should print a warning message to let the
administrator know he has done something that is potentially insecure.
 
 
On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org>
wrote:
It's about balance. I'm not arguing here against it, I just don't see
how it could strengthen security. Nothing will stop people to get their
own gun and automate it with stdin :)
 
On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com>
wrote:
On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
I can be wrong, but this is not only our responsibility. For example, on
Linux you are prompted for the password with passwd, but at the same
time you could circumvent this using: echo 12345678 | sudo passwd admin
--stdin.
 
In this scenario security auditors won't blame the OS for this, but
pretty much sysadmins and bad security practices. Anyways, whatever
people think is the best, I'm fine.
I agree with you there.  In that case you are doing something extra to
shoot yourself in the foot.  We can't guard against that.
 
We just shouldn't put the gun in your hand.
 
 
On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com>
wrote:
On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
I think the Jira created by Stian pretty much fixes the problem. Nope?
Stian's JIRA says that if it is not specified on the command line then
do the prompt.  But if we still allow setting it from the command line
then the password can still be saved to the log in plain text.  Security
auditors will always frown on that.
 
So I'm saying we should either disallow setting on the command line or
somehow disable saving to the log.  We shouldn't rely on an
administrator to do the right thing.
 
 
 
Something like:
 
./add-user-keycloak.sh -u user
Password: ******
 
Or 
 
./add-user-keycloak-sh
Username: joe
Password: ******
 
If this can't fix the issue, is also possible to disable bash_history
temporarily. But I wouldn't take this route, because this is pretty much
system administration responsibility.
 
 
On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com>
wrote:
On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
 
 
On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com>
wrote:
It seems the add-user.sh  script for changing the admin password only
accepts the password as a -p command-line parameter. This would expose
the password in the command history, so I'd prefer not to use the
command in its current form.
 
That's a mistake we'll fix that. If not specified it should prompt for
it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
After attending several security talks the last couple of days, I've
become rather sensitized to this kind of issue.  I feel quite strongly
that we should never allow the password to be written to history in
plain text.   I'm also afraid it could cause us to flunk government
certifications.
 
On Windows, this really isn't a problem because command history is not
saved.  After a CMD session ends, the history is lost (unless you
install some third-party tool).
 
Perhaps there is a way to temporarily disable logging of command history
in the add-user-keycloak.sh?
 
 
 
 
Is there another way to do this?
 
The situation is even more complicated with Docker, since running the
script to change the Wildfly admin password requires restarting the
server, which shuts down the container. If you have an autoscaling
group, the container that gets brought up is not the container where you
changed the password, but instead the original container. This seems to
mean that the only way to have Keycloak run in Dockers in an autoscaling
group is to bake the admin passwords into the Docker image beforehand.
This isn't ideal; less so if the only way to add those passwords during
build time is to run the shell script that exposes the password on the
command line.
 
You need to set the password once for your database. This can be done
prior to accessing the admin console the first time. Take a look at
https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
you can use docker exec to do this.
 

--
http://www.fastmail.com - Access your email from home and the web

_______________________________________________
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.orghttps://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

 
-- 
http://www.fastmail.com - Choose from over 50 domains or use your own


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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
                          love email again


From bburke at redhat.com  Mon Feb 22 10:55:06 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Feb 2016 10:55:06 -0500
Subject: [keycloak-user] Is it CSRF vulnerability?
In-Reply-To: <CY1PR07MB22001156C074D18D75A47D2BC4A30@CY1PR07MB2200.namprd07.prod.outlook.com>
References: <CY1PR07MB2200A3AC960FE1F7314D6F1AC4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
	<4D38F80E-FBFE-4757-9800-4F25F77AD5F7@smartling.com>
	<CY1PR07MB2200DDEDFBE30B03413960A6C4A00@CY1PR07MB2200.namprd07.prod.outlook.com>
	<CALAqdu_-ukc6pNtaxVoot2To2mc1tXrLdZhgjOeEiv8_OcG7aw@mail.gmail.com>
	<CY1PR07MB22001156C074D18D75A47D2BC4A30@CY1PR07MB2200.namprd07.prod.outlook.com>
Message-ID: <56CB2F5A.3030404@redhat.com>

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#General_Recommendation:_Synchronizer_Token_Pattern

CSRF prevention using a session token is really an application specific 
thing that Keycloak cannot handle automatically.   Even the referenced 
Tomcat filter requires that you manually encode every URL you publish.  
Also, if you read the linked owasp doc, it doesn't recommend that you 
include CSRF tokens in URLs.  #1 it screws up browser caches, and #2 the 
token is still stored in browser history.

IMO, CORS, specifically the Origin header, is the best and least 
intrusive approach to prevent CSRF.  Keycloak has support for that.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token



On 2/22/2016 10:20 AM, Baskin, Ilia wrote:
>
> Thanks Scott,
>
> As far as I understand now the Chapter 22. Security Vulnerabilities of 
> Keycloak documentation talks about the security of authentication 
> workflow. I believe it will be nice if you added clear explanation of 
> what security the adapters provide and don?t provide after authentication.
>
> Thanks
>
> Ilia
>
> *From:*Scott Rossillo [mailto:srossillo at smartling.com]
> *Sent:* Saturday, February 20, 2016 10:29 AM
> *To:* Baskin, Ilia
> *Cc:* keycloak-user at lists.jboss.org
> *Subject:* Re: [keycloak-user] Is it CSRF vulnerability?
>
> Are you using the Tomcat adapter? If so you have to configure Tomcats' 
> CSRF filter.
>
> Once you've authenticated with an SSO server like Keycloak, you still 
> have to use platform specific CSRF
>
> https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CSRF_Prevention_Filter
>
> On Fri, Feb 19, 2016 at 6:19 PM Baskin, Ilia 
> <ibaskine at microstrategy.com <mailto:ibaskine at microstrategy.com>> wrote:
>
>     Scott,
>
>     I know that, but this is exactly how CSRF works. There are several
>     simple ways to defend against CSRF and I am surprised that
>     Keycloak, a security application, doesn?t utilize any.
>
>     Thanks.
>
>     Ilia
>
>     *From:*Scott Rossillo [mailto:srossillo at smartling.com
>     <mailto:srossillo at smartling.com>]
>     *Sent:* Friday, February 19, 2016 6:15 PM
>     *To:* Baskin, Ilia
>     *Cc:* keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>
>     *Subject:* Re: [keycloak-user] Is it CSRF vulnerability?
>
>     Once you?ve authenticated with Keycloak, your application has an
>     session id provided by Tomcat. This is why your requests are
>     succeeding. If you examine your XHR requests, I?d assume the
>     session id cookie is being passed to the server.
>
>     Scott Rossillo
>
>     Smartling | Senior Software Engineer
>
>     srossillo at smartling.com <mailto:srossillo at smartling.com>
>
>         On Feb 19, 2016, at 6:01 PM, Baskin, Ilia
>         <ibaskine at microstrategy.com
>         <mailto:ibaskine at microstrategy.com>> wrote:
>
>         Hi,
>
>         I am experimenting with Keycloak to evaluate its suitability
>         for our application. Here is one of my experiments, that got
>         me warried:
>
>         I created a simple page (see attached), deployed it on Tomcat
>         and registered it in Keycloak as confidential client. As you
>         can see the page contains a button clicking on which executes
>         simple XHR request. Notice that XHR request doesn?t contain
>         Authorization header. On submission of my page URL I am
>         redirected to Keycloak for authentication. After
>         authentication I can submit XHR requests at will.
>
>         Now I copied my page and deployed the copy on the same Tomcat
>         as a different totally unsecured application. If I open this
>         page in another browser tab and click on XHR button it will go
>         through without any problem. It looks to me as a typical CSRF
>         case. Am I missing something here?
>
>         Thanks.
>
>         Ilia
>
>         <index.html>_______________________________________________
>         keycloak-user mailing list
>         keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/eed9f4c8/attachment-0001.html 

From Edgar at info.nl  Mon Feb 22 11:08:13 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Mon, 22 Feb 2016 16:08:13 +0000
Subject: [keycloak-user] Renaming a user in Keycloak does not change the
 user's DN when using LDAP federation provider
Message-ID: <7AC7A3E8-E81A-4969-8959-59D48DF91FAC@info.nl>

Hi,

Just checking if I have got this right. Our scenario is that we have set up an LDAP user federation from Keycloak to Active Directory. We map the username in Keycloak to the userPrincipalName attribute in MSAD.

As is common the full DN in MSAD starts with the username. E.g. CN=edgar at info.nl,OU=Users,OU=Customers,DC=hf,DC=info,DC=nl

Now when I change the username from Keycloak I see that the userPrincipalName attribute is updated, however the DN remains the same. If I look in the Keycloak source code it seems indeed that a user DN is only set once on creation of the user (LDAPUtils#addUserToLDAP).

We would like renaming of the user in Keycloak to result in a renaming of the DN in MSAD/LDAP as well. Shall I create a JIRA feature request for this?

cheers

Edgar

From bburke at redhat.com  Mon Feb 22 11:26:21 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Feb 2016 11:26:21 -0500
Subject: [keycloak-user] Create client in master realm with API
In-Reply-To: <DCA704F1-D432-4C50-BFE3-A7572BFF8B90@christianbauer.name>
References: <mailman.14001.1456153836.3326.keycloak-user@lists.jboss.org>
	<DCA704F1-D432-4C50-BFE3-A7572BFF8B90@christianbauer.name>
Message-ID: <56CB36AD.1000406@redhat.com>



On 2/22/2016 10:21 AM, Christian Bauer wrote:
> Hi Bill, long time no see. Seems like we are both stuck with this Java thing. :)

Love you man!  Lucky you... You have to interact with me again...

>
>
> That looks like it should give me superuser access. But POSTing with that token on "/auth/realms/master/clients/default" is Forbidden, because ClientRegistrationAuth.java checks for "realm-management" resource claims and not "master-realm":

That's the issue then.  Other REST endpoints check both master and 
realm-management credentials.  I can't get a fix for you until 1.9.1.  
1.9.0 is supposed to go out tomorrow and is in testing phase.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From bburke at redhat.com  Mon Feb 22 11:47:52 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Feb 2016 11:47:52 -0500
Subject: [keycloak-user] Create client in master realm with API
In-Reply-To: <89CBDCC1-CED7-4C99-87FD-D308EE819D68@christianbauer.name>
References: <89CBDCC1-CED7-4C99-87FD-D308EE819D68@christianbauer.name>
Message-ID: <56CB3BB8.9010001@redhat.com>

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

On 2/22/2016 9:02 AM, Christian Bauer wrote:
> Hi
>
> I'm trying to implement a multi-tenant system that should use Keycloak, from its Docker image. I'd like to use the Keycloak admin API from another container. My first goal is to create a new client in the master realm for my tenant administration app, then create realms for each tenant, etc.
>
> To do this I'm using the admin-cli client in the master realm with public direct grant authentication, and I can get an authentication token with superuser roles for the admin user.
>
> Next I tried to POST /auth/realms/master/clients/default with a client representation and the admin-cli bearer token. This is forbidden, because though I have superuser roles, I don't have the Constants.REALM_MANAGEMENT_CLIENT_ID resource roles required in ClientRegistrationAuth:177.
>
> I'm not sure I'm doing this right. The console web UI probably has the same roles if I'm logged in as admin and it's able to create users.
>
> I guess I could step further through the code to find the difference. Other options I've considered:
>
> - Don't create a new client in the master realm and continue using the admin-cli client for superuser tasks.
>
> - Adjust the Docker image bootstrap so it exports the initial database, then manipulate the exported files with some JSON transformer, then import again.
>
> - Hacking the themes/Angular frontend of the security-admin-console and use this to implement my tenant/user administration app.
>
> Thoughts?

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From thomas.darimont at googlemail.com  Mon Feb 22 16:26:06 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 22 Feb 2016 22:26:06 +0100
Subject: [keycloak-user] Use other Keycloak Realm as Identity Provider
Message-ID: <CAK-7U1gfLD0QDxxJkX=SFfAF5T==7_BJdn9Fs+LvC9OCsFo0Mg@mail.gmail.com>

I remember some discussions about this on the ML but I couldn't find a
concluding answer.

I have a scenario where I need users from a realm "B" to be able to use an
application
that lives in realm "A".

In the concrete use case I have a "B-user" registered in realm "B" that
needs to access
an application X from realm "A".
"B-user" is already authenticated in keycloak and accesses the application
X in realm "A".
Since the user is not authenticated with realm "A" the user gets redirected
to realm "A"s login.

Now I want to make it possible to login the "B-user"either transparently or
by clicking on a link
"login with B" such that he can use application X.

Note that I want to avoid showing B's login.

Is this possible at all?

I thought that this might be possible by defining a Keycloak Identity
provider for realm B.

In order to test this I did the following:

I created two realms A and B - each with it's own realm user A-user and
B-user respectively
then I defined a new identity provider of type Keycloak OpenID Connect
(keycloak-oidc) with the following settings:

                            Alias: Realm B
                       Enabled: On
Authenticate by default: On
           First Login Flow: first broker login
            Post Login flow: --empty--
       Authorization URL:
http://localhost:8081/auth/realms/b/protocol/openid-connect/auth
                  Token URL:
http://localhost:8081/auth/realms/b/protocol/openid-connect/token
                 Logout URL:
http://localhost:8081/auth/realms/b/protocol/openid-connect/logout
             User Info URL:
http://localhost:8081/auth/realms/b/protocol/openid-connect/userinfo
                      Client ID: account (account application in realm A)
               Client Secret: fa0c8747-8ea5-43f0-acbd-fea47ad6bab8 (account
application in realm A)

In "Mappers" I defined a "user-role-mapper" as a "Hardcoded Role" with
"account.view-profile".

As an example app I use the account client that exists in both realms.

Now I login to realm-b and access the account app:
http://localhost:8081/auth/realms/b/account

If I now browse to:
http://localhost:8081/auth/realms/a/account

I get a redirect to:
http://localhost:8081/auth/realms/b/protocol/openid-connect/auth?scope=openid&state=xvB9nevhQp6IhPJzN7-XfRwUI1250UINM-VvegnpNB0.44090b97-e6a2-448d-b453-60d967265cb4&response_type=code&client_id=account&redirect_uri=http%3A%2F%2Flocalhost%3A8081%2Fauth%2Frealms%2Fa%2Fbroker%2FB%2Fendpoint

which results in a page indicating:

    We're sorry ...

    Invalid parameter: redirect_uri

    ? Back to Application

Back to application points to "http://localhost:8081/auth/realms/b/account"
Did I do anything wrong here? Why is the redirect_uri invalid?

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/ebe7aee7/attachment.html 

From bburke at redhat.com  Mon Feb 22 16:39:16 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Feb 2016 16:39:16 -0500
Subject: [keycloak-user] Use other Keycloak Realm as Identity Provider
In-Reply-To: <CAK-7U1gfLD0QDxxJkX=SFfAF5T==7_BJdn9Fs+LvC9OCsFo0Mg@mail.gmail.com>
References: <CAK-7U1gfLD0QDxxJkX=SFfAF5T==7_BJdn9Fs+LvC9OCsFo0Mg@mail.gmail.com>
Message-ID: <56CB8004.1060001@redhat.com>

You have to create a client in your "top" realm for the "child" idp.  
You must define a redirect uri in that client.  I think that is probably 
your problem.

On 2/22/2016 4:26 PM, Thomas Darimont wrote:
> I remember some discussions about this on the ML but I couldn't find a 
> concluding answer.
>
> I have a scenario where I need users from a realm "B" to be able to 
> use an application
> that lives in realm "A".
>
> In the concrete use case I have a "B-user" registered in realm "B" 
> that needs to access
> an application X from realm "A".
> "B-user" is already authenticated in keycloak and accesses the 
> application X in realm "A".
> Since the user is not authenticated with realm "A" the user gets 
> redirected to realm "A"s login.
>
> Now I want to make it possible to login the "B-user"either 
> transparently or by clicking on a link
> "login with B" such that he can use application X.
>
> Note that I want to avoid showing B's login.
>
> Is this possible at all?
>
> I thought that this might be possible by defining a Keycloak Identity 
> provider for realm B.
>
> In order to test this I did the following:
>
> I created two realms A and B - each with it's own realm user A-user 
> and B-user respectively
> then I defined a new identity provider of type Keycloak OpenID Connect 
> (keycloak-oidc) with the following settings:
>
>                             Alias: Realm B
>                        Enabled: On
> Authenticate by default: On
>            First Login Flow: first broker login
>             Post Login flow: --empty--
>        Authorization URL: 
> http://localhost:8081/auth/realms/b/protocol/openid-connect/auth
>                   Token URL: 
> http://localhost:8081/auth/realms/b/protocol/openid-connect/token
>                  Logout URL: 
> http://localhost:8081/auth/realms/b/protocol/openid-connect/logout
>              User Info URL: 
> http://localhost:8081/auth/realms/b/protocol/openid-connect/userinfo
>                       Client ID: account (account application in realm A)
>                Client Secret: fa0c8747-8ea5-43f0-acbd-fea47ad6bab8 
> (account application in realm A)
>
> In "Mappers" I defined a "user-role-mapper" as a "Hardcoded Role" with 
> "account.view-profile".
>
> As an example app I use the account client that exists in both realms.
>
> Now I login to realm-b and access the account app:
> http://localhost:8081/auth/realms/b/account
>
> If I now browse to:
> http://localhost:8081/auth/realms/a/account
>
> I get a redirect to:
> http://localhost:8081/auth/realms/b/protocol/openid-connect/auth?scope=openid&state=xvB9nevhQp6IhPJzN7-XfRwUI1250UINM-VvegnpNB0.44090b97-e6a2-448d-b453-60d967265cb4&response_type=code&client_id=account&redirect_uri=http%3A%2F%2Flocalhost%3A8081%2Fauth%2Frealms%2Fa%2Fbroker%2FB%2Fendpoint
>
> which results in a page indicating:
>
>     We're sorry ...
>
>     Invalid parameter: redirect_uri
>
>     ? Back to Application
>
> Back to application points to 
> "http://localhost:8081/auth/realms/b/account"
> Did I do anything wrong here? Why is the redirect_uri invalid?
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/d832a56e/attachment-0001.html 

From jaxley at expedia.com  Mon Feb 22 18:23:01 2016
From: jaxley at expedia.com (Jason Axley)
Date: Mon, 22 Feb 2016 23:23:01 +0000
Subject: [keycloak-user] SAML attribute mapping debugging
Message-ID: <38425614-9EE3-4EDE-90B4-CDF5AAB5ED78@expedia.com>

Bump.

I saw someone had a previous question in October about IdP mappings but the thread died without clear resolution.  I didn?t see any general information on enabling DEBUG mode in keycloak to help with troubleshooting.

When I log into the ?account? client application via SAML, I?m presented with a screen to enter in my login, email, first name and last name so I can see that none of the values in the SAML assertion are being picked up by the mappers.

-Jason

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Jason Axley <jaxley at expedia.com<mailto:jaxley at expedia.com>>
Date: Thursday, February 18, 2016 at 1:49 PM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: [keycloak-user] SAML attribute mapping debugging

I?ve set up incoming SAML authentication using Microsoft ADFS as the IdP.  However, the attribute mappings I?ve configured are not picking up the data.  A couple things are not clear:

  1.  How can one debug the mappings to find out why they did not find the data?
  2.  Where is the ?user model? documented to know which fields are available to map to?  I pulled out some things from existing LDAP mappings but would be nice to know what else is there to map (e.g. AD or other LDAP Groups)

For example, I?ve set up an email mapper that is configured:

Mapper Type:  Attribute Importer
Attribute Name:  http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Friendly Name:  emailaddress
User Attribute Name:  email

Doesn?t work?

-Jason

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160222/13a77610/attachment.html 

From akaya at expedia.com  Tue Feb 23 00:52:43 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Tue, 23 Feb 2016 05:52:43 +0000
Subject: [keycloak-user] Proxying SAML Login
Message-ID: <D2F23030.2BB4%akaya@expedia.com>

Hi,

Identity Providers tab only have the SAML provider that I was talking
about (which redirects you to SAML provider). If I go to User Federation
there is no SAML there either, so mapping IDP to a User Federation does
not seem possible. I could not find anywhere to set ?IDP Federation?,
could you explain a little further?

Kind Regards,
Sarp Kaya


>Date: Mon, 22 Feb 2016 09:04:18 -0500
>From: Bill Burke <bburke at redhat.com>
>Subject: Re: [keycloak-user] Proxying SAML Login
>To: keycloak-user at lists.jboss.org
>Message-ID: <56CB1562.2090106 at redhat.com>
>Content-Type: text/plain; charset="windows-1252"
>
>Check the identity providers tab.  You can set u "IDP Federation".
>Social login is under there too.
>
>On 2/22/2016 6:33 AM, Sarp Kaya wrote:
>> Hi,
>>
>> I have looked around but couldn?t find what I was looking for.
>> What I want to do is when user wants to login with IDP I still want
>> the user to login via Keycloak UI and I want Keycloak to proxy the
>> IDP. What makes sense to me is to have something like a new client
>> which will use OpenID and then this client would proxy it to the IDP
>> itself. Is this possible? If so then how can I do it?
>>
>>
>> _______________________________________________
>> 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 sthorger at redhat.com  Tue Feb 23 01:06:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 07:06:16 +0100
Subject: [keycloak-user] No kid in token headers
In-Reply-To: <62C2E2BE-DD49-4BD3-A984-510F1A784452@yahoo.com>
References: <62C2E2BE-DD49-4BD3-A984-510F1A784452@yahoo.com>
Message-ID: <CAJgngAcdsp+itNnwkhZWWm5pP8R5X9Wt_rhW49U9naHgX2g_sw@mail.gmail.com>

We're not adding 'kid' currently. It's also optional so not required to
add. However, feel free to create a JIRA requesting it.

On 19 February 2016 at 20:04, Raghu Prabhala <prabhalar at yahoo.com> wrote:

> Revisited keycloak 1.9 cr1 after a long time. While the basic and implicit
> flows work properly, noticed that the token validation is failing due to
> the lack of kid in token header.  Did anyone come across  the same problem
> or am I missing something?
>
> Btw we use our own oidc client libraries to interact with KC, which were
> tested against commercial products
>
> Thanks,
> Raghu
>
> Sent from my iPhone
> _______________________________________________
> 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/20160223/b48aed67/attachment.html 

From sthorger at redhat.com  Tue Feb 23 01:11:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 07:11:09 +0100
Subject: [keycloak-user] Confidential RESTful client
In-Reply-To: <CAFYKa1m677d+5V_GWjicJLPxFy71OmLhJ4YOsmR+VtaiF-nvdw@mail.gmail.com>
References: <CAFYKa1m677d+5V_GWjicJLPxFy71OmLhJ4YOsmR+VtaiF-nvdw@mail.gmail.com>
Message-ID: <CAJgngAfdBxbMcWkpPW2-6teUJZqo9pk=TsBpJitd2zRKVwHVFA@mail.gmail.com>

As long as you use HTTPS and make sure you set redirect uris correctly it's
secure. The authorization code has a short lifespan so there's very low
chance that someone could retrieve it from the browser history. Further the
redirect uris prevent other applications from sniffing it.

I don't see how what you are proposing would be any more secure. You still
have to transfer the token to the HTML5 application. So you've used moved
the problem from the interaction between Keycloak to a custom
implementation on your end.

On 19 February 2016 at 23:18, Bruce Shaw <battery4cid at gmail.com> wrote:

> I have a AngularJs single page web-app that makes RESTful API calls to get
> secured data from our server (Play Framework).  I originally set it up to
> be a public client using the keycloak.js adapter but I?m wondering if
> there?s a more secure way.
>
> Instead of having the redirect response (with the authorization code) come
> back to the keycloak.js followed by the request to get the access token,
> wouldn?t it be more secure to have the javascript post the returned
> authorization code to our server or just set the redirect url to an
> endpoint on our server to make the backchannel request (with client secret
> and id) for the access token?  Then we can redirect the user to the
> appropriate location with the access token in the response?
>
> I guess I?m trying to make my RESTful api a confidential client, any input
> or direction would help.
>
> thanks.
>
>
>
> _______________________________________________
> 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/20160223/40ce3114/attachment.html 

From sthorger at redhat.com  Tue Feb 23 01:19:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 07:19:07 +0100
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <1456155129.1348870.528320818.68611749@webmail.messagingengine.com>
References: <1456155129.1348870.528320818.68611749@webmail.messagingengine.com>
Message-ID: <CAJgngAdCrg31bq8UPGkoC+TavKqfbLoeY1bXXPC_B3D_Uqb-nw@mail.gmail.com>

If you have suggestions to changes/additions we can do to make it more
secure feel free to let us now

On 22 February 2016 at 16:32, Aikeaguinea <aikeaguinea at xsmail.com> wrote:

> We're essentially doing this. Since we need to secure the Wildfly admin
> password as well, we are basically running the add-user.sh scripts to
> generate the keycloak-user.json and mgmt-users.properties before running
> the Docker script, and then adding them to the image. This has the
> disadvantage of baking the passwords into the image, but at least
> they're encrypted and the image is stored in a secure repository, which
> is probably as good as we're going to get.
>
>
>
> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Bill Burke
> <bburke at redhat.com>
> Date: Monday, February 22, 2016 at 10:21 AM
> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Securely setting admin passwords
>
> I'm too lazy to read this entire thread, sorry if somebody already
> suggested this, but can't you
>
> 1) Create a minimal realm in your local environment and export the realm
> to json.
> 2) Import this json in your Docker script?
>
>
>
> On 2/22/2016 10:10 AM, Aikeaguinea wrote:
> With regard to Docker, things get more complicated. I believe it's not
> just the bash history but the Docker history itself that stores the
> commands.
>
> Also, per one of the messages earlier on this chain, it is not advised
> to put secrets into Docker environment variables. These are accessible
> in many different ways.
>
> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stan Silvert
> <ssilvert at redhat.com>
> Date: Thursday, February 18, 2016 at 12:26 PM
> To: "stian at redhat.com" <stian at redhat.com>
> Cc: Stian Thorgersen <sthorger at redhat.com>, keycloak-user
> <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Securely setting admin passwords
>
> On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
> It's security vs usability as usual. Allowing passing the password
> directly is convenient for developers, for Docker image, for
> provisioning tools, etc.. So we're not going to remove that it's
> required, but I do appreciate that if not used correctly it's a
> potential security risk. The worst case scenario here is really that
> someone gets an admins favorite password, as someone that has access to
> getting the bash history of that particular user will also be able to
> run the add-user script themselves. So if the admin wants to print his
> favorite password in clear text in the bash history we should not stop
> him.
>
> It's not our responsibility to clear the bash history, so we should not
> do that either.
> If there is a way to stop that one command from being saved in the bash
> history then we should do it.
>
> At the very least, we should print a warning message to let the
> administrator know he has done something that is potentially insecure.
>
>
> On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> It's about balance. I'm not arguing here against it, I just don't see
> how it could strengthen security. Nothing will stop people to get their
> own gun and automate it with stdin :)
>
> On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com>
> wrote:
> On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
> I can be wrong, but this is not only our responsibility. For example, on
> Linux you are prompted for the password with passwd, but at the same
> time you could circumvent this using: echo 12345678 | sudo passwd admin
> --stdin.
>
> In this scenario security auditors won't blame the OS for this, but
> pretty much sysadmins and bad security practices. Anyways, whatever
> people think is the best, I'm fine.
> I agree with you there.  In that case you are doing something extra to
> shoot yourself in the foot.  We can't guard against that.
>
> We just shouldn't put the gun in your hand.
>
>
> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com>
> wrote:
> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
> I think the Jira created by Stian pretty much fixes the problem. Nope?
> Stian's JIRA says that if it is not specified on the command line then
> do the prompt.  But if we still allow setting it from the command line
> then the password can still be saved to the log in plain text.  Security
> auditors will always frown on that.
>
> So I'm saying we should either disallow setting on the command line or
> somehow disable saving to the log.  We shouldn't rely on an
> administrator to do the right thing.
>
>
>
> Something like:
>
> ./add-user-keycloak.sh -u user
> Password: ******
>
> Or
>
> ./add-user-keycloak-sh
> Username: joe
> Password: ******
>
> If this can't fix the issue, is also possible to disable bash_history
> temporarily. But I wouldn't take this route, because this is pretty much
> system administration responsibility.
>
>
> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com>
> wrote:
> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>
>
> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com>
> wrote:
> It seems the add-user.sh  script for changing the admin password only
> accepts the password as a -p command-line parameter. This would expose
> the password in the command history, so I'd prefer not to use the
> command in its current form.
>
> That's a mistake we'll fix that. If not specified it should prompt for
> it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
> After attending several security talks the last couple of days, I've
> become rather sensitized to this kind of issue.  I feel quite strongly
> that we should never allow the password to be written to history in
> plain text.   I'm also afraid it could cause us to flunk government
> certifications.
>
> On Windows, this really isn't a problem because command history is not
> saved.  After a CMD session ends, the history is lost (unless you
> install some third-party tool).
>
> Perhaps there is a way to temporarily disable logging of command history
> in the add-user-keycloak.sh?
>
>
>
>
> Is there another way to do this?
>
> The situation is even more complicated with Docker, since running the
> script to change the Wildfly admin password requires restarting the
> server, which shuts down the container. If you have an autoscaling
> group, the container that gets brought up is not the container where you
> changed the password, but instead the original container. This seems to
> mean that the only way to have Keycloak run in Dockers in an autoscaling
> group is to bake the admin passwords into the Docker image beforehand.
> This isn't ideal; less so if the only way to add those passwords during
> build time is to run the shell script that exposes the password on the
> command line.
>
> You need to set the password once for your database. This can be done
> prior to accessing the admin console the first time. Take a look at
> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md
> ,
> you can use docker exec to do this.
>
>
> --
> http://www.fastmail.com - Access your email from home and the web
>
> _______________________________________________
> 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.orghttps://
> 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
>
>
> --
> http://www.fastmail.com - Choose from over 50 domains or use your own
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.orghttps://
> lists.jboss.org/mailman/listinfo/keycloak-user
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> --
> http://www.fastmail.com - Or how I learned to stop worrying and
>                           love email again
>
> _______________________________________________
> 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/20160223/68a1dafe/attachment-0001.html 

From sthorger at redhat.com  Tue Feb 23 01:56:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 07:56:35 +0100
Subject: [keycloak-user] Infinispan not working on HA environment with
	dockers.
In-Reply-To: <CAPLJng9O49JK+tzqs6xfNCc7QTYOqb5fkx-Obf7g8M6kybBvYQ@mail.gmail.com>
References: <CAPLJng9O49JK+tzqs6xfNCc7QTYOqb5fkx-Obf7g8M6kybBvYQ@mail.gmail.com>
Message-ID: <CAJgngAdeRwF5BQPcYM24oig0GhaQbyqVUyZyB4TzSQdFsr=t_A@mail.gmail.com>

Create a JIRA please

On 17 February 2016 at 15:03, Nicol?s Pozo <nicopozo at gmail.com> wrote:

> Hello all,
> I'm trying to set a Keycloak HA environment up with dockers. I tried with
> jboss/keycloak-ha-postgres:1.8.0.Final image.
>
> I can't make infinispan work when I run 2 instances of my docker images. I
> get the following log in every node:
>
> Received new cluster view for channel ejb: [f9032dc82244|0] (1)
> [f9032dc82244]
> Received new cluster view for channel hibernate: [f9032dc82244|0] (1)
> [f9032dc82244]
> Received new cluster view for channel keycloak: [f9032dc82244|0] (1)
> [f9032dc82244]
> Received new cluster view for channel web: [f9032dc82244|0] (1)
> [f9032dc82244]
> Channel hibernate local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> Channel keycloak local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> Channel ejb local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> Channel web local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
> Received new cluster view for channel server: [f9032dc82244|0] (1)
> [f9032dc82244]
> Channel server local address is f9032dc82244, physical addresses are [
> 127.0.0.1:55200]
>
> This is causing my user sessions are not shared between instances and it's
> not working properly.
>
> When I run 2 instances of keycloak without dockers, they work properly.
>
> Am I missing something? Is there any extra configuration that I need to
> change?
>
> Thanks,
> Nicolas.-
>
> _______________________________________________
> 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/20160223/f8536b12/attachment.html 

From mposolda at redhat.com  Tue Feb 23 03:09:10 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 Feb 2016 09:09:10 +0100
Subject: [keycloak-user] Renaming a user in Keycloak does not change the
 user's DN when using LDAP federation provider
In-Reply-To: <7AC7A3E8-E81A-4969-8959-59D48DF91FAC@info.nl>
References: <7AC7A3E8-E81A-4969-8959-59D48DF91FAC@info.nl>
Message-ID: <56CC13A6.9090001@redhat.com>

Yes, feel free to create JIRA. You can link with your other bit similar 
JIRA you already created for CN based on firstName + lastName.

However I don't know when we fix it (likely not earlier then in Keycloak 
2.0) as renaming DN is not very trivial change and may have various 
implications, so it would need to be properly tested.

Marek


On 22/02/16 17:08, Edgar Vonk - Info.nl wrote:
> Hi,
>
> Just checking if I have got this right. Our scenario is that we have set up an LDAP user federation from Keycloak to Active Directory. We map the username in Keycloak to the userPrincipalName attribute in MSAD.
>
> As is common the full DN in MSAD starts with the username. E.g. CN=edgar at info.nl,OU=Users,OU=Customers,DC=hf,DC=info,DC=nl
>
> Now when I change the username from Keycloak I see that the userPrincipalName attribute is updated, however the DN remains the same. If I look in the Keycloak source code it seems indeed that a user DN is only set once on creation of the user (LDAPUtils#addUserToLDAP).
>
> We would like renaming of the user in Keycloak to result in a renaming of the DN in MSAD/LDAP as well. Shall I create a JIRA feature request for this?
>
> cheers
>
> Edgar
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From bruno at abstractj.org  Tue Feb 23 04:03:30 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 23 Feb 2016 09:03:30 +0000
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <CAJgngAdCrg31bq8UPGkoC+TavKqfbLoeY1bXXPC_B3D_Uqb-nw@mail.gmail.com>
References: <1456155129.1348870.528320818.68611749@webmail.messagingengine.com>
	<CAJgngAdCrg31bq8UPGkoC+TavKqfbLoeY1bXXPC_B3D_Uqb-nw@mail.gmail.com>
Message-ID: <CAM5SUC6WJrgKaCjU4LKvz3zS0nnHMq+5vM-W9O5wMwWccEA1DA@mail.gmail.com>

I think the best approach is to add keycloak-user.json. Even if we provide
some sorta of public key encryption for protecting passwords, at some point
would be mandatory for automation scripts to be prompted for the admin's
password.

On Tue, Feb 23, 2016 at 3:19 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> If you have suggestions to changes/additions we can do to make it more
> secure feel free to let us now
>
> On 22 February 2016 at 16:32, Aikeaguinea <aikeaguinea at xsmail.com> wrote:
>
>> We're essentially doing this. Since we need to secure the Wildfly admin
>> password as well, we are basically running the add-user.sh scripts to
>> generate the keycloak-user.json and mgmt-users.properties before running
>> the Docker script, and then adding them to the image. This has the
>> disadvantage of baking the passwords into the image, but at least
>> they're encrypted and the image is stored in a secure repository, which
>> is probably as good as we're going to get.
>>
>>
>>
>> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Bill Burke
>> <bburke at redhat.com>
>> Date: Monday, February 22, 2016 at 10:21 AM
>> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>> Subject: Re: [keycloak-user] Securely setting admin passwords
>>
>> I'm too lazy to read this entire thread, sorry if somebody already
>> suggested this, but can't you
>>
>> 1) Create a minimal realm in your local environment and export the realm
>> to json.
>> 2) Import this json in your Docker script?
>>
>>
>>
>> On 2/22/2016 10:10 AM, Aikeaguinea wrote:
>> With regard to Docker, things get more complicated. I believe it's not
>> just the bash history but the Docker history itself that stores the
>> commands.
>>
>> Also, per one of the messages earlier on this chain, it is not advised
>> to put secrets into Docker environment variables. These are accessible
>> in many different ways.
>>
>> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stan Silvert
>> <ssilvert at redhat.com>
>> Date: Thursday, February 18, 2016 at 12:26 PM
>> To: "stian at redhat.com" <stian at redhat.com>
>> Cc: Stian Thorgersen <sthorger at redhat.com>, keycloak-user
>> <keycloak-user at lists.jboss.org>
>> Subject: Re: [keycloak-user] Securely setting admin passwords
>>
>> On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
>> It's security vs usability as usual. Allowing passing the password
>> directly is convenient for developers, for Docker image, for
>> provisioning tools, etc.. So we're not going to remove that it's
>> required, but I do appreciate that if not used correctly it's a
>> potential security risk. The worst case scenario here is really that
>> someone gets an admins favorite password, as someone that has access to
>> getting the bash history of that particular user will also be able to
>> run the add-user script themselves. So if the admin wants to print his
>> favorite password in clear text in the bash history we should not stop
>> him.
>>
>> It's not our responsibility to clear the bash history, so we should not
>> do that either.
>> If there is a way to stop that one command from being saved in the bash
>> history then we should do it.
>>
>> At the very least, we should print a warning message to let the
>> administrator know he has done something that is potentially insecure.
>>
>>
>> On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org>
>> wrote:
>> It's about balance. I'm not arguing here against it, I just don't see
>> how it could strengthen security. Nothing will stop people to get their
>> own gun and automate it with stdin :)
>>
>> On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com>
>> wrote:
>> On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>> I can be wrong, but this is not only our responsibility. For example, on
>> Linux you are prompted for the password with passwd, but at the same
>> time you could circumvent this using: echo 12345678 | sudo passwd admin
>> --stdin.
>>
>> In this scenario security auditors won't blame the OS for this, but
>> pretty much sysadmins and bad security practices. Anyways, whatever
>> people think is the best, I'm fine.
>> I agree with you there.  In that case you are doing something extra to
>> shoot yourself in the foot.  We can't guard against that.
>>
>> We just shouldn't put the gun in your hand.
>>
>>
>> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com>
>> wrote:
>> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>> I think the Jira created by Stian pretty much fixes the problem. Nope?
>> Stian's JIRA says that if it is not specified on the command line then
>> do the prompt.  But if we still allow setting it from the command line
>> then the password can still be saved to the log in plain text.  Security
>> auditors will always frown on that.
>>
>> So I'm saying we should either disallow setting on the command line or
>> somehow disable saving to the log.  We shouldn't rely on an
>> administrator to do the right thing.
>>
>>
>>
>> Something like:
>>
>> ./add-user-keycloak.sh -u user
>> Password: ******
>>
>> Or
>>
>> ./add-user-keycloak-sh
>> Username: joe
>> Password: ******
>>
>> If this can't fix the issue, is also possible to disable bash_history
>> temporarily. But I wouldn't take this route, because this is pretty much
>> system administration responsibility.
>>
>>
>> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com>
>> wrote:
>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>
>>
>> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com>
>> wrote:
>> It seems the add-user.sh  script for changing the admin password only
>> accepts the password as a -p command-line parameter. This would expose
>> the password in the command history, so I'd prefer not to use the
>> command in its current form.
>>
>> That's a mistake we'll fix that. If not specified it should prompt for
>> it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
>> After attending several security talks the last couple of days, I've
>> become rather sensitized to this kind of issue.  I feel quite strongly
>> that we should never allow the password to be written to history in
>> plain text.   I'm also afraid it could cause us to flunk government
>> certifications.
>>
>> On Windows, this really isn't a problem because command history is not
>> saved.  After a CMD session ends, the history is lost (unless you
>> install some third-party tool).
>>
>> Perhaps there is a way to temporarily disable logging of command history
>> in the add-user-keycloak.sh?
>>
>>
>>
>>
>> Is there another way to do this?
>>
>> The situation is even more complicated with Docker, since running the
>> script to change the Wildfly admin password requires restarting the
>> server, which shuts down the container. If you have an autoscaling
>> group, the container that gets brought up is not the container where you
>> changed the password, but instead the original container. This seems to
>> mean that the only way to have Keycloak run in Dockers in an autoscaling
>> group is to bake the admin passwords into the Docker image beforehand.
>> This isn't ideal; less so if the only way to add those passwords during
>> build time is to run the shell script that exposes the password on the
>> command line.
>>
>> You need to set the password once for your database. This can be done
>> prior to accessing the admin console the first time. Take a look at
>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md
>> ,
>> you can use docker exec to do this.
>>
>>
>> --
>> http://www.fastmail.com - Access your email from home and the web
>>
>> _______________________________________________
>> 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.orghttps://
>> 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
>>
>>
>> --
>> http://www.fastmail.com - Choose from over 50 domains or use your own
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.orghttps://
>> lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> --
>> http://www.fastmail.com - Or how I learned to stop worrying and
>>                           love email again
>>
>> _______________________________________________
>> 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/20160223/9ac228c3/attachment-0001.html 

From sthorger at redhat.com  Tue Feb 23 04:08:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 10:08:39 +0100
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <CAM5SUC6WJrgKaCjU4LKvz3zS0nnHMq+5vM-W9O5wMwWccEA1DA@mail.gmail.com>
References: <1456155129.1348870.528320818.68611749@webmail.messagingengine.com>
	<CAJgngAdCrg31bq8UPGkoC+TavKqfbLoeY1bXXPC_B3D_Uqb-nw@mail.gmail.com>
	<CAM5SUC6WJrgKaCjU4LKvz3zS0nnHMq+5vM-W9O5wMwWccEA1DA@mail.gmail.com>
Message-ID: <CAJgngAf7WYgagTrTsvEtXN=XQ8T_hRQQ5vWCs7uKgq8aLvSw0A@mail.gmail.com>

That doesn't seem ideal to me as you're then "hard-coding" the password
into the Docker image.

On 23 February 2016 at 10:03, Bruno Oliveira <bruno at abstractj.org> wrote:

> I think the best approach is to add keycloak-user.json. Even if we provide
> some sorta of public key encryption for protecting passwords, at some point
> would be mandatory for automation scripts to be prompted for the admin's
> password.
>
> On Tue, Feb 23, 2016 at 3:19 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> If you have suggestions to changes/additions we can do to make it more
>> secure feel free to let us now
>>
>> On 22 February 2016 at 16:32, Aikeaguinea <aikeaguinea at xsmail.com> wrote:
>>
>>> We're essentially doing this. Since we need to secure the Wildfly admin
>>> password as well, we are basically running the add-user.sh scripts to
>>> generate the keycloak-user.json and mgmt-users.properties before running
>>> the Docker script, and then adding them to the image. This has the
>>> disadvantage of baking the passwords into the image, but at least
>>> they're encrypted and the image is stored in a secure repository, which
>>> is probably as good as we're going to get.
>>>
>>>
>>>
>>> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Bill Burke
>>> <bburke at redhat.com>
>>> Date: Monday, February 22, 2016 at 10:21 AM
>>> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>>> Subject: Re: [keycloak-user] Securely setting admin passwords
>>>
>>> I'm too lazy to read this entire thread, sorry if somebody already
>>> suggested this, but can't you
>>>
>>> 1) Create a minimal realm in your local environment and export the realm
>>> to json.
>>> 2) Import this json in your Docker script?
>>>
>>>
>>>
>>> On 2/22/2016 10:10 AM, Aikeaguinea wrote:
>>> With regard to Docker, things get more complicated. I believe it's not
>>> just the bash history but the Docker history itself that stores the
>>> commands.
>>>
>>> Also, per one of the messages earlier on this chain, it is not advised
>>> to put secrets into Docker environment variables. These are accessible
>>> in many different ways.
>>>
>>> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stan Silvert
>>> <ssilvert at redhat.com>
>>> Date: Thursday, February 18, 2016 at 12:26 PM
>>> To: "stian at redhat.com" <stian at redhat.com>
>>> Cc: Stian Thorgersen <sthorger at redhat.com>, keycloak-user
>>> <keycloak-user at lists.jboss.org>
>>> Subject: Re: [keycloak-user] Securely setting admin passwords
>>>
>>> On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
>>> It's security vs usability as usual. Allowing passing the password
>>> directly is convenient for developers, for Docker image, for
>>> provisioning tools, etc.. So we're not going to remove that it's
>>> required, but I do appreciate that if not used correctly it's a
>>> potential security risk. The worst case scenario here is really that
>>> someone gets an admins favorite password, as someone that has access to
>>> getting the bash history of that particular user will also be able to
>>> run the add-user script themselves. So if the admin wants to print his
>>> favorite password in clear text in the bash history we should not stop
>>> him.
>>>
>>> It's not our responsibility to clear the bash history, so we should not
>>> do that either.
>>> If there is a way to stop that one command from being saved in the bash
>>> history then we should do it.
>>>
>>> At the very least, we should print a warning message to let the
>>> administrator know he has done something that is potentially insecure.
>>>
>>>
>>> On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org>
>>> wrote:
>>> It's about balance. I'm not arguing here against it, I just don't see
>>> how it could strengthen security. Nothing will stop people to get their
>>> own gun and automate it with stdin :)
>>>
>>> On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>> On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>>> I can be wrong, but this is not only our responsibility. For example, on
>>> Linux you are prompted for the password with passwd, but at the same
>>> time you could circumvent this using: echo 12345678 | sudo passwd admin
>>> --stdin.
>>>
>>> In this scenario security auditors won't blame the OS for this, but
>>> pretty much sysadmins and bad security practices. Anyways, whatever
>>> people think is the best, I'm fine.
>>> I agree with you there.  In that case you are doing something extra to
>>> shoot yourself in the foot.  We can't guard against that.
>>>
>>> We just shouldn't put the gun in your hand.
>>>
>>>
>>> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>> I think the Jira created by Stian pretty much fixes the problem. Nope?
>>> Stian's JIRA says that if it is not specified on the command line then
>>> do the prompt.  But if we still allow setting it from the command line
>>> then the password can still be saved to the log in plain text.  Security
>>> auditors will always frown on that.
>>>
>>> So I'm saying we should either disallow setting on the command line or
>>> somehow disable saving to the log.  We shouldn't rely on an
>>> administrator to do the right thing.
>>>
>>>
>>>
>>> Something like:
>>>
>>> ./add-user-keycloak.sh -u user
>>> Password: ******
>>>
>>> Or
>>>
>>> ./add-user-keycloak-sh
>>> Username: joe
>>> Password: ******
>>>
>>> If this can't fix the issue, is also possible to disable bash_history
>>> temporarily. But I wouldn't take this route, because this is pretty much
>>> system administration responsibility.
>>>
>>>
>>> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>
>>>
>>> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com>
>>> wrote:
>>> It seems the add-user.sh  script for changing the admin password only
>>> accepts the password as a -p command-line parameter. This would expose
>>> the password in the command history, so I'd prefer not to use the
>>> command in its current form.
>>>
>>> That's a mistake we'll fix that. If not specified it should prompt for
>>> it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
>>> After attending several security talks the last couple of days, I've
>>> become rather sensitized to this kind of issue.  I feel quite strongly
>>> that we should never allow the password to be written to history in
>>> plain text.   I'm also afraid it could cause us to flunk government
>>> certifications.
>>>
>>> On Windows, this really isn't a problem because command history is not
>>> saved.  After a CMD session ends, the history is lost (unless you
>>> install some third-party tool).
>>>
>>> Perhaps there is a way to temporarily disable logging of command history
>>> in the add-user-keycloak.sh?
>>>
>>>
>>>
>>>
>>> Is there another way to do this?
>>>
>>> The situation is even more complicated with Docker, since running the
>>> script to change the Wildfly admin password requires restarting the
>>> server, which shuts down the container. If you have an autoscaling
>>> group, the container that gets brought up is not the container where you
>>> changed the password, but instead the original container. This seems to
>>> mean that the only way to have Keycloak run in Dockers in an autoscaling
>>> group is to bake the admin passwords into the Docker image beforehand.
>>> This isn't ideal; less so if the only way to add those passwords during
>>> build time is to run the shell script that exposes the password on the
>>> command line.
>>>
>>> You need to set the password once for your database. This can be done
>>> prior to accessing the admin console the first time. Take a look at
>>>
>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md
>>> ,
>>> you can use docker exec to do this.
>>>
>>>
>>> --
>>> http://www.fastmail.com - Access your email from home and the web
>>>
>>> _______________________________________________
>>> 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.orghttps://
>>> 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
>>>
>>>
>>> --
>>> http://www.fastmail.com - Choose from over 50 domains or use your own
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.orghttps://
>>> lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>> --
>>> http://www.fastmail.com - Or how I learned to stop worrying and
>>>                           love email again
>>>
>>> _______________________________________________
>>> 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/20160223/93bcf0d7/attachment.html 

From sthorger at redhat.com  Tue Feb 23 04:10:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 10:10:07 +0100
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <1456153831.1343667.528300426.5376354D@webmail.messagingengine.com>
References: <1456153831.1343667.528300426.5376354D@webmail.messagingengine.com>
Message-ID: <CAJgngAfpNHr5zjc3O+e5V4fQiR=MW=tPn3Fhq9nr8y3wG5FMJw@mail.gmail.com>

On 22 February 2016 at 16:10, Aikeaguinea <aikeaguinea at xsmail.com> wrote:

> With regard to Docker, things get more complicated. I believe it's not
> just the bash history but the Docker history itself that stores the
> commands.
>

What about "docker exec" approach? We've fixed it in 1.9.0.Final so that
it'll now prompt for a password if one isn't specified.


>
> Also, per one of the messages earlier on this chain, it is not advised to
> put secrets into Docker environment variables. These are accessible in many
> different ways.
>
> *From: *<keycloak-user-bounces at lists.jboss.org> on behalf of Stan Silvert
> <ssilvert at redhat.com>
> *Date: *Thursday, February 18, 2016 at 12:26 PM
> *To: *"stian at redhat.com" <stian at redhat.com>
> *Cc: *Stian Thorgersen <sthorger at redhat.com>, keycloak-user <
> keycloak-user at lists.jboss.org>
> *Subject: *Re: [keycloak-user] Securely setting admin passwords
>
> On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
>
> It's security vs usability as usual. Allowing passing the password
> directly is convenient for developers, for Docker image, for provisioning
> tools, etc.. So we're not going to remove that it's required, but I do
> appreciate that if not used correctly it's a potential security risk. The
> worst case scenario here is really that someone gets an admins favorite
> password, as someone that has access to getting the bash history of that
> particular user will also be able to run the add-user script themselves. So
> if the admin wants to print his favorite password in clear text in the bash
> history we should not stop him.
>
> It's not our responsibility to clear the bash history, so we should not do
> that either.
>
> If there is a way to stop that one command from being saved in the bash
> history then we should do it.
>
> At the very least, we should print a warning message to let the
> administrator know he has done something that is potentially insecure.
>
>
>
> On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> It's about balance. I'm not arguing here against it, I just don't see how
>> it could strengthen security. Nothing will stop people to get their own gun
>> and automate it with stdin :)
>>
>> On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com>
>> wrote:
>>
>>> On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>>>
>>> I can be wrong, but this is not only our responsibility. For example, on
>>> Linux you are prompted for the password with passwd, but at the same time
>>> you could circumvent this using: echo 12345678 | sudo passwd admin --stdin.
>>>
>>> In this scenario security auditors won't blame the OS for this, but
>>> pretty much sysadmins and bad security practices. Anyways, whatever people
>>> think is the best, I'm fine.
>>>
>>> I agree with you there.  In that case you are doing something extra to
>>> shoot yourself in the foot.  We can't guard against that.
>>>
>>> We just shouldn't put the gun in your hand.
>>>
>>>
>>>
>>> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>>
>>>> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>>>
>>>> I think the Jira created by Stian pretty much fixes the problem. Nope?
>>>>
>>>> Stian's JIRA says that if it is not specified on the command line then
>>>> do the prompt.  But if we still allow setting it from the command line then
>>>> the password can still be saved to the log in plain text.  Security
>>>> auditors will always frown on that.
>>>>
>>>> So I'm saying we should either disallow setting on the command line or
>>>> somehow disable saving to the log.  We shouldn't rely on an administrator
>>>> to do the right thing.
>>>>
>>>>
>>>>
>>>>
>>>> Something like:
>>>>
>>>> ./add-user-keycloak.sh -u user
>>>> Password: ******
>>>>
>>>> Or
>>>>
>>>> ./add-user-keycloak-sh
>>>> Username: joe
>>>> Password: ******
>>>>
>>>> If this can't fix the issue, is also possible to disable bash_history
>>>> temporarily. But I wouldn't take this route, because this is pretty much
>>>> system administration responsibility.
>>>>
>>>>
>>>> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com>
>>>> wrote:
>>>>
>>>>> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com>
>>>>>  wrote:
>>>>>
>>>>>> It seems the add-user.sh  script for changing the admin password only
>>>>>> accepts the password as a -p command-line parameter. This would expose
>>>>>> the password in the command history, so I'd prefer not to use the
>>>>>> command in its current form.
>>>>>>
>>>>>
>>>>> That's a mistake we'll fix that. If not specified it should prompt for
>>>>> it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
>>>>>
>>>>> After attending several security talks the last couple of days, I've
>>>>> become rather sensitized to this kind of issue.  I feel quite strongly that
>>>>> we should never allow the password to be written to history in plain
>>>>> text.   I'm also afraid it could cause us to flunk government
>>>>> certifications.
>>>>>
>>>>> On Windows, this really isn't a problem because command history is not
>>>>> saved.  After a CMD session ends, the history is lost (unless you install
>>>>> some third-party tool).
>>>>>
>>>>> Perhaps there is a way to temporarily disable logging of command
>>>>> history in the add-user-keycloak.sh?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Is there another way to do this?
>>>>>>
>>>>>> The situation is even more complicated with Docker, since running the
>>>>>> script to change the Wildfly admin password requires restarting the
>>>>>> server, which shuts down the container. If you have an autoscaling
>>>>>> group, the container that gets brought up is not the container where
>>>>>> you
>>>>>> changed the password, but instead the original container. This seems
>>>>>> to
>>>>>> mean that the only way to have Keycloak run in Dockers in an
>>>>>> autoscaling
>>>>>> group is to bake the admin passwords into the Docker image beforehand.
>>>>>> This isn't ideal; less so if the only way to add those passwords
>>>>>> during
>>>>>> build time is to run the shell script that exposes the password on the
>>>>>> command line.
>>>>>>
>>>>>
>>>>> You need to set the password once for your database. This can be done
>>>>> prior to accessing the admin console the first time. Take a look at
>>>>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>>>> you can use docker exec to do this.
>>>>>
>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.fastmail.com - Access your email from home and the web
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user <keycloak-user at lists.jboss.org>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>
>
>
> -- http://www.fastmail.com - Choose from over 50 domains or use your own
>
>
> _______________________________________________
> 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/20160223/0e2c8648/attachment-0001.html 

From mposolda at redhat.com  Tue Feb 23 04:37:07 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 Feb 2016 10:37:07 +0100
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <CAJgngAfpNHr5zjc3O+e5V4fQiR=MW=tPn3Fhq9nr8y3wG5FMJw@mail.gmail.com>
References: <1456153831.1343667.528300426.5376354D@webmail.messagingengine.com>
	<CAJgngAfpNHr5zjc3O+e5V4fQiR=MW=tPn3Fhq9nr8y3wG5FMJw@mail.gmail.com>
Message-ID: <56CC2843.2040502@redhat.com>

Another possibility is to share the file keycloak-user.json with docker 
via volume. Then it's not hardcoded into the Docker image. The 
entrypoint script can check if the file shared through volume exists and 
copy it to standalone/configuration in that case.

Marek

On 23/02/16 10:10, Stian Thorgersen wrote:
>
>
> On 22 February 2016 at 16:10, Aikeaguinea <aikeaguinea at xsmail.com 
> <mailto:aikeaguinea at xsmail.com>> wrote:
>
>     With regard to Docker, things get more complicated. I believe it's
>     not just the bash history but the Docker history itself that
>     stores the commands.
>
>
> What about "docker exec" approach? We've fixed it in 1.9.0.Final so 
> that it'll now prompt for a password if one isn't specified.
>
>     Also, per one of the messages earlier on this chain, it is not
>     advised to put secrets into Docker environment variables. These
>     are accessible in many different ways.
>     *From: *<keycloak-user-bounces at lists.jboss.org
>     <mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Stan
>     Silvert <ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
>     *Date: *Thursday, February 18, 2016 at 12:26 PM
>     *To: *"stian at redhat.com <mailto:stian at redhat.com>"
>     <stian at redhat.com <mailto:stian at redhat.com>>
>     *Cc: *Stian Thorgersen <sthorger at redhat.com
>     <mailto:sthorger at redhat.com>>, keycloak-user
>     <keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>>
>     *Subject: *Re: [keycloak-user] Securely setting admin passwords
>     On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
>>     It's security vs usability as usual. Allowing passing the
>>     password directly is convenient for developers, for Docker image,
>>     for provisioning tools, etc.. So we're not going to remove that
>>     it's required, but I do appreciate that if not used correctly
>>     it's a potential security risk. The worst case scenario here is
>>     really that someone gets an admins favorite password, as someone
>>     that has access to getting the bash history of that particular
>>     user will also be able to run the add-user script themselves. So
>>     if the admin wants to print his favorite password in clear text
>>     in the bash history we should not stop him.
>>     It's not our responsibility to clear the bash history, so we
>>     should not do that either.
>     If there is a way to stop that one command from being saved in the
>     bash history then we should do it.
>     At the very least, we should print a warning message to let the
>     administrator know he has done something that is potentially insecure.
>>     On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org
>>     <mailto:bruno at abstractj.org>> wrote:
>>
>>         It's about balance. I'm not arguing here against it, I just
>>         don't see how it could strengthen security. Nothing will stop
>>         people to get their own gun and automate it with stdin :)
>>         On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert
>>         <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>
>>             On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
>>>             I can be wrong, but this is not only our responsibility.
>>>             For example, on Linux you are prompted for the password
>>>             with passwd, but at the same time you could circumvent
>>>             this using: echo 12345678 | sudo passwd admin --stdin.
>>>             In this scenario security auditors won't blame the OS
>>>             for this, but pretty much sysadmins and bad security
>>>             practices. Anyways, whatever people think is the best,
>>>             I'm fine.
>>             I agree with you there.  In that case you are doing
>>             something extra to shoot yourself in the foot.  We can't
>>             guard against that.
>>             We just shouldn't put the gun in your hand.
>>>             On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert
>>>             <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>                 On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
>>>>                 I think the Jira created by Stian pretty much fixes
>>>>                 the problem. Nope?
>>>                 Stian's JIRA says that if it is not specified on the
>>>                 command line then do the prompt. But if we still
>>>                 allow setting it from the command line then the
>>>                 password can still be saved to the log in plain
>>>                 text. Security auditors will always frown on that.
>>>                 So I'm saying we should either disallow setting on
>>>                 the command line or somehow disable saving to the
>>>                 log. We shouldn't rely on an administrator to do the
>>>                 right thing.
>>>>                 Something like:
>>>>                 ./add-user-keycloak.sh -u user
>>>>                 Password: ******
>>>>                 Or
>>>>                 ./add-user-keycloak-sh
>>>>                 Username: joe
>>>>                 Password: ******
>>>>                 If this can't fix the issue, is also possible to
>>>>                 disable bash_history temporarily. But I wouldn't
>>>>                 take this route, because this is pretty much system
>>>>                 administration responsibility.
>>>>                 On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert
>>>>                 <ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
>>>>                 wrote:
>>>>
>>>>                     On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>>>>>                     On 17 February 2016 at 17:09, Aikeaguinea
>>>>>                     <aikeaguinea at xsmail.com
>>>>>                     <mailto:aikeaguinea at xsmail.com>> wrote:
>>>>>
>>>>>                         It seems the add-user.sh script for
>>>>>                         changing the admin password only
>>>>>                         accepts the password as a -p command-line
>>>>>                         parameter. This would expose
>>>>>                         the password in the command history, so
>>>>>                         I'd prefer not to use the
>>>>>                         command in its current form.
>>>>>
>>>>>                     That's a mistake we'll fix that. If not
>>>>>                     specified it should prompt for it. Added
>>>>>                     https://issues.jboss.org/browse/KEYCLOAK-2501
>>>>                     After attending several security talks the last
>>>>                     couple of days, I've become rather sensitized
>>>>                     to this kind of issue.  I feel quite strongly
>>>>                     that we should never allow the password to be
>>>>                     written to history in plain text. I'm also
>>>>                     afraid it could cause us to flunk government
>>>>                     certifications.
>>>>                     On Windows, this really isn't a problem because
>>>>                     command history is not saved.  After a CMD
>>>>                     session ends, the history is lost (unless you
>>>>                     install some third-party tool).
>>>>                     Perhaps there is a way to temporarily disable
>>>>                     logging of command history in the
>>>>                     add-user-keycloak.sh?
>>>>>
>>>>>                         Is there another way to do this?
>>>>>                         The situation is even more complicated
>>>>>                         with Docker, since running the
>>>>>                         script to change the Wildfly admin
>>>>>                         password requires restarting the
>>>>>                         server, which shuts down the container. If
>>>>>                         you have an autoscaling
>>>>>                         group, the container that gets brought up
>>>>>                         is not the container where you
>>>>>                         changed the password, but instead the
>>>>>                         original container. This seems to
>>>>>                         mean that the only way to have Keycloak
>>>>>                         run in Dockers in an autoscaling
>>>>>                         group is to bake the admin passwords into
>>>>>                         the Docker image beforehand.
>>>>>                         This isn't ideal; less so if the only way
>>>>>                         to add those passwords during
>>>>>                         build time is to run the shell script that
>>>>>                         exposes the password on the
>>>>>                         command line.
>>>>>
>>>>>                     You need to set the password once for your
>>>>>                     database. This can be done prior to accessing
>>>>>                     the admin console the first time. Take a look
>>>>>                     at
>>>>>                     https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
>>>>>                     you can use docker exec to do this.
>>>>>
>>>>>
>>>>>                         --
>>>>>                         http://www.fastmail.com
>>>>>                         <http://www.fastmail.com/> - Access your
>>>>>                         email from home and the web
>>>>>
>>>>>                         _______________________________________________
>>>>>                         keycloak-user mailing list
>>>>>                         keycloak-user at lists.jboss.org
>>>>>                         <mailto:keycloak-user at lists.jboss.org>
>>>>>                         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>                     _______________________________________________
>>>>>                     keycloak-user mailing list
>>>>>                     keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>                     <mailto:keycloak-user at lists.jboss.org>
>>>>                     _______________________________________________
>>>>                     keycloak-user mailing list
>>>>                     keycloak-user at lists.jboss.org
>>>>                     <mailto:keycloak-user at lists.jboss.org>
>>>>                     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>         _______________________________________________
>>         keycloak-user mailing list
>>         keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>     -- 
>     http://www.fastmail.com  - Choose from over 50 domains or use your own
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/19205d2e/attachment-0001.html 

From andyyar66 at gmail.com  Tue Feb 23 07:36:32 2016
From: andyyar66 at gmail.com (Andy Yar)
Date: Tue, 23 Feb 2016 13:36:32 +0100
Subject: [keycloak-user] Spring Security - URL schema in "redirect_uri"
	generation
In-Reply-To: <47494416-B6D0-4629-9C10-079F478069B0@smartling.com>
References: <CAMBdEymLn=FpoXh4uTyCKp4wKjCF1SjwoEhsNetX9yb-dH1k8w@mail.gmail.com>
	<47494416-B6D0-4629-9C10-079F478069B0@smartling.com>
Message-ID: <CAMBdEy=zHMLtr713bAwNsFuHTEtOejV4-Au=c=9QmBgH83qKVQ@mail.gmail.com>

Thanks for pointing me right directon. I have already had the Wildfly side
set up correctly. However, client app hosting Tomcats were not aware of
being behind the proxy. Everything works smooth after adding following
settings to my Tomcat's Connector in server.xml.

proxyName="proxyhostname.com" proxyPort="443" scheme="https"


On Sat, Feb 20, 2016 at 12:26 AM, Scott Rossillo <srossillo at smartling.com>
wrote:

> It seems Wildfly isn?t aware of the fact that Nginx is handling secure
> connections.
>
> Take a look at these posts:
>
> http://lists.jboss.org/pipermail/keycloak-user/2016-January/004413.html
> http://lists.jboss.org/pipermail/keycloak-user/2015-September/003104.html
>
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
> On Feb 19, 2016, at 10:56 AM, Andy Yar <andyyar66 at gmail.com> wrote:
>
> Howdy,
> I use 1.8.0-Final integrated with Spring Security (which itself is
> integrated into Grails) using OpenID Connect method. The Keycloak and all
> integrated apps run behind a nginx SSL reverse proxy. Realm's SSL is set
> to: "ssl-required": "external".
>
> My issue is related to initial "redirect_uri" generation.
>
> When I'm logged out and try to access a protected resource via a HTTPS
> request, I receive 302 response with Location URL starting with plain HTTP
> scheme. Apparently the Location goes to the "redirect_uri" attribute and
> therefore it tries to redirect me back here after a successful login.
>
> Of course, it is possible to add both HTTP and HTTPS schemas as allowed
> redirect URI patterns. However, application's security gets lowered by that
> plain HTTP redirect...
>
> Is there any easy solution for non-SSL Keycloak/apps running behind SSL
> reverse proxy? I haven't looked into the source code but it seems as a
> plain redirect which wouldn't be schema-aware.
>
> Thanks in advance!
> Andy
> _______________________________________________
> 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/20160223/0c70f39c/attachment.html 

From sthorger at redhat.com  Tue Feb 23 08:20:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 14:20:19 +0100
Subject: [keycloak-user] We have a new logo!
Message-ID: <CAJgngAeUcpiTerQ4JSt+sFW1AcjqLHeeqz3BAvLNtjfmm_+_-A@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/3bea6f60/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak_google_plus_cover_1080x608.png
Type: image/png
Size: 103774 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/3bea6f60/attachment-0001.png 

From teatimej at gmail.com  Tue Feb 23 08:28:43 2016
From: teatimej at gmail.com (Michael Mok)
Date: Tue, 23 Feb 2016 21:28:43 +0800
Subject: [keycloak-user] Keycloak 1.9.0 CR1 not serving javascript in https
 when fronted with Apache2 and mod_proxy_ajp
Message-ID: <CAO=w+JMC9zMbrY=eJae46UxS25oeWr9d-RHJ-4Su88hq-GGcxg@mail.gmail.com>

Hi


Not sure if I missed any thing here. But I am getting the following error
when fronting keycloak 1.9.0 CR1 with Apache http server. I am running
keycloak 1.9.0 CR1 with Wildfly 10. it is a bug or something I missed in my
configuration. My setup is browser -> https -> Apache2 -> ajp -> keycloak
1.9.CR1.

The setup and files are taken from keycloak-1.9.0.CR1.tar.gz with no
modification apart from adding the ajp listener on start port 8009.

Any idea? Thanks.

but requested an insecure script '
http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/controllers/realm.js'.
This request has been blocked; the content must be served over HTTPS.
demo.test.com/:1 Mixed Content: The page at '
https://demo.test.com/auth/admin/master/console/' was loaded over HTTPS,
but requested an insecure script '
http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/controllers/clients.js'.
This request has been blocked; the content must be served over HTTPS.
demo.test.com/:1 Mixed Content: The page at '
https://demo.test.com/auth/admin/master/console/' was loaded over HTTPS,
but requested an insecure script '
http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/controllers/users.js'.
This request has been blocked; the content must be served over HTTPS.
demo.test.com/:1 Mixed Content: The page at '
https://demo.test.com/auth/admin/master/console/' was loaded over HTTPS,
but requested an insecure script '
http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/controllers/groups.js'.
This request has been blocked; the content must be served over HTTPS.
demo.test.com/:1 Mixed Content: The page at '
https://demo.test.com/auth/admin/master/console/' was loaded over HTTPS,
but requested an insecure script '
http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/loaders.js'.
This request has been blocked; the content must be served over HTTPS.
demo.test.com/:1 Mixed Content: The page at '
https://demo.test.com/auth/admin/master/console/' was loaded over HTTPS,
but requested an insecure script '
http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/services.js'.
This request has been blocked; the content must be served over HTTPS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/422edf43/attachment.html 

From sblanc at redhat.com  Tue Feb 23 08:33:42 2016
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 23 Feb 2016 14:33:42 +0100
Subject: [keycloak-user] We have a new logo!
In-Reply-To: <CAJgngAeUcpiTerQ4JSt+sFW1AcjqLHeeqz3BAvLNtjfmm_+_-A@mail.gmail.com>
References: <CAJgngAeUcpiTerQ4JSt+sFW1AcjqLHeeqz3BAvLNtjfmm_+_-A@mail.gmail.com>
Message-ID: <CAMZCGg_ciEsddNpp_-+umaSRqJKkicic90qVMUzTVwv+rn_FoA@mail.gmail.com>

Really nice !

On Tue, Feb 23, 2016 at 2:20 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

>
>
>
> _______________________________________________
> 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/20160223/2a357925/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak_google_plus_cover_1080x608.png
Type: image/png
Size: 103774 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/2a357925/attachment-0001.png 

From sthorger at redhat.com  Tue Feb 23 08:36:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 14:36:49 +0100
Subject: [keycloak-user] Keycloak 1.9.0 CR1 not serving javascript in
 https when fronted with Apache2 and mod_proxy_ajp
In-Reply-To: <CAO=w+JMC9zMbrY=eJae46UxS25oeWr9d-RHJ-4Su88hq-GGcxg@mail.gmail.com>
References: <CAO=w+JMC9zMbrY=eJae46UxS25oeWr9d-RHJ-4Su88hq-GGcxg@mail.gmail.com>
Message-ID: <CAJgngAc0kunOucB8L3H=UzTKJPzeX1B_RNaPb609yVjLLk1e8Q@mail.gmail.com>

Did you configure Keycloak according to
http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e386
?

On 23 February 2016 at 14:28, Michael Mok <teatimej at gmail.com> wrote:

> Hi
>
>
> Not sure if I missed any thing here. But I am getting the following error
> when fronting keycloak 1.9.0 CR1 with Apache http server. I am running
> keycloak 1.9.0 CR1 with Wildfly 10. it is a bug or something I missed in
> my configuration. My setup is browser -> https -> Apache2 -> ajp ->
> keycloak 1.9.CR1.
>
> The setup and files are taken from keycloak-1.9.0.CR1.tar.gz with no
> modification apart from adding the ajp listener on start port 8009.
>
> Any idea? Thanks.
>
> but requested an insecure script '
> http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/controllers/realm.js'.
> This request has been blocked; the content must be served over HTTPS.
> demo.test.com/:1 Mixed Content: The page at '
> https://demo.test.com/auth/admin/master/console/' was loaded over HTTPS,
> but requested an insecure script '
> http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/controllers/clients.js'.
> This request has been blocked; the content must be served over HTTPS.
> demo.test.com/:1 Mixed Content: The page at '
> https://demo.test.com/auth/admin/master/console/' was loaded over HTTPS,
> but requested an insecure script '
> http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/controllers/users.js'.
> This request has been blocked; the content must be served over HTTPS.
> demo.test.com/:1 Mixed Content: The page at '
> https://demo.test.com/auth/admin/master/console/' was loaded over HTTPS,
> but requested an insecure script '
> http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/controllers/groups.js'.
> This request has been blocked; the content must be served over HTTPS.
> demo.test.com/:1 Mixed Content: The page at '
> https://demo.test.com/auth/admin/master/console/' was loaded over HTTPS,
> but requested an insecure script '
> http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/loaders.js'.
> This request has been blocked; the content must be served over HTTPS.
> demo.test.com/:1 Mixed Content: The page at '
> https://demo.test.com/auth/admin/master/console/' was loaded over HTTPS,
> but requested an insecure script '
> http://demo.test.com/auth/resources/1.9.0.cr1/admin/keycloak/js/services.js'.
> This request has been blocked; the content must be served over HTTPS.
>
> _______________________________________________
> 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/20160223/9ae9e27c/attachment.html 

From bburke at redhat.com  Tue Feb 23 09:08:58 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 23 Feb 2016 09:08:58 -0500
Subject: [keycloak-user] Proxying SAML Login
In-Reply-To: <D2F23030.2BB4%akaya@expedia.com>
References: <D2F23030.2BB4%akaya@expedia.com>
Message-ID: <56CC67FA.3030909@redhat.com>

Ok, i read your post too quick last time sorry.  The Idnetity Provider 
SPIs only Keycloak delegating authentication to a "parent" IDP (like how 
social login works).  You can't have Keycloak UI screens in front of a 
"parent" IDP using this SPI.    What you can do is write a custom User 
Federation Provider.  Credentials can be acquired by the Keycloak UI and 
passed to whatever backend you need to validate them.

On 2/23/2016 12:52 AM, Sarp Kaya wrote:
> Hi,
>
> Identity Providers tab only have the SAML provider that I was talking
> about (which redirects you to SAML provider). If I go to User Federation
> there is no SAML there either, so mapping IDP to a User Federation does
> not seem possible. I could not find anywhere to set ?IDP Federation?,
> could you explain a little further?
>
> Kind Regards,
> Sarp Kaya
>
>
>> Date: Mon, 22 Feb 2016 09:04:18 -0500
>> From: Bill Burke <bburke at redhat.com>
>> Subject: Re: [keycloak-user] Proxying SAML Login
>> To: keycloak-user at lists.jboss.org
>> Message-ID: <56CB1562.2090106 at redhat.com>
>> Content-Type: text/plain; charset="windows-1252"
>>
>> Check the identity providers tab.  You can set u "IDP Federation".
>> Social login is under there too.
>>
>> On 2/22/2016 6:33 AM, Sarp Kaya wrote:
>>> Hi,
>>>
>>> I have looked around but couldn?t find what I was looking for.
>>> What I want to do is when user wants to login with IDP I still want
>>> the user to login via Keycloak UI and I want Keycloak to proxy the
>>> IDP. What makes sense to me is to have something like a new client
>>> which will use OpenID and then this client would proxy it to the IDP
>>> itself. Is this possible? If so then how can I do it?
>>>
>>>
>>> _______________________________________________
>>> 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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From aikeaguinea at xsmail.com  Tue Feb 23 09:24:42 2016
From: aikeaguinea at xsmail.com (Aikeaguinea)
Date: Tue, 23 Feb 2016 09:24:42 -0500
Subject: [keycloak-user] Securely setting admin passwords
Message-ID: <1456237482.2552063.529395538.62B7C79E@webmail.messagingengine.com>

I'd be happy with KEYCLOAK-2501 (accepting the password on the command
line). Then the docker exec approach wouldn't expose the password; this
is essentially the approach I started with before I ran into the issue
with the -p switch. (It would be equally desirable to have the same
change for add-user --container for the Wildfly password; should I open
a JIRA with Wildfly about this, or would the implementation of
KEYCLOAK-2501 require the corresponding modification in Wildfly anyway?)

Mounting the file via volume was something we looked into. We're setting
things up in Amazon's Elastic Container Service, which uses autoscaling
groups to bring up new instances automatically (though we don't think
we'll really need that aspect of it all that much). My recollection is
that the setup involved didn't seem worth the trouble because our Docker
image is in a secure repository anyway. If we have to store the file
someplace, might as well just copy it into the container and keep it in
the image; at least that was the thinking. For people who put their
images on a public registry this wouldn't be a good solution.


From: <keycloak-user-bounces at lists.jboss.org> on behalf of Marek Posolda
<mposolda at redhat.com>
Date: Tuesday, February 23, 2016 at 4:37 AM
To: "stian at redhat.com" <stian at redhat.com>, Aikeaguinea
<aikeaguinea at xsmail.com>
Cc: keycloak-user <keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Securely setting admin passwords

Another possibility is to share the file keycloak-user.json with docker
via volume. Then it's not hardcoded into the Docker image. The
entrypoint script can check if the file shared through volume exists and
copy it to standalone/configuration in that case.

Marek

On 23/02/16 10:10, Stian Thorgersen wrote:


On 22 February 2016 at 16:10, Aikeaguinea <aikeaguinea at xsmail.com>
wrote:
With regard to Docker, things get more complicated. I believe it's not
just the bash history but the Docker history itself that stores the
commands. 

What about "docker exec" approach? We've fixed it in 1.9.0.Final so that
it'll now prompt for a password if one isn't specified.
 
 
Also, per one of the messages earlier on this chain, it is not advised
to put secrets into Docker environment variables. These are accessible
in many different ways.
 
From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stan Silvert
<ssilvert at redhat.com>
Date: Thursday, February 18, 2016 at 12:26 PM
To: "stian at redhat.com" <stian at redhat.com>
Cc: Stian Thorgersen <sthorger at redhat.com>, keycloak-user
<keycloak-user at lists.jboss.org>
Subject: Re: [keycloak-user] Securely setting admin passwords
 
On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
It's security vs usability as usual. Allowing passing the password
directly is convenient for developers, for Docker image, for
provisioning tools, etc.. So we're not going to remove that it's
required, but I do appreciate that if not used correctly it's a
potential security risk. The worst case scenario here is really that
someone gets an admins favorite password, as someone that has access to
getting the bash history of that particular user will also be able to
run the add-user script themselves. So if the admin wants to print his
favorite password in clear text in the bash history we should not stop
him. 
 
It's not our responsibility to clear the bash history, so we should not
do that either. 
If there is a way to stop that one command from being saved in the bash
history then we should do it.  
 
At the very least, we should print a warning message to let the
administrator know he has done something that is potentially insecure.
 
 
On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org>
wrote:
It's about balance. I'm not arguing here against it, I just don't see
how it could strengthen security. Nothing will stop people to get their
own gun and automate it with stdin :)
 
On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com>
wrote:
On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
I can be wrong, but this is not only our responsibility. For example, on
Linux you are prompted for the password with passwd, but at the same
time you could circumvent this using: echo 12345678 | sudo passwd admin
--stdin.
 
In this scenario security auditors won't blame the OS for this, but
pretty much sysadmins and bad security practices. Anyways, whatever
people think is the best, I'm fine.
I agree with you there.  In that case you are doing something extra to
shoot yourself in the foot.  We can't guard against that.
 
We just shouldn't put the gun in your hand.
 
 
On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com>
wrote:
On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
I think the Jira created by Stian pretty much fixes the problem. Nope?
Stian's JIRA says that if it is not specified on the command line then
do the prompt.  But if we still allow setting it from the command line
then the password can still be saved to the log in plain text.  Security
auditors will always frown on that.
 
So I'm saying we should either disallow setting on the command line or
somehow disable saving to the log.  We shouldn't rely on an
administrator to do the right thing.
 
 
 
Something like:
 
./add-user-keycloak.sh -u user
Password: ******
 
Or 
 
./add-user-keycloak-sh
Username: joe
Password: ******
 
If this can't fix the issue, is also possible to disable bash_history
temporarily. But I wouldn't take this route, because this is pretty much
system administration responsibility.
 
 
On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com>
wrote:
On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
 
 
On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com>
wrote:
It seems the add-user.sh  script for changing the admin password only
accepts the password as a -p command-line parameter. This would expose
the password in the command history, so I'd prefer not to use the
command in its current form.
 
That's a mistake we'll fix that. If not specified it should prompt for
it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
After attending several security talks the last couple of days, I've
become rather sensitized to this kind of issue.  I feel quite strongly
that we should never allow the password to be written to history in
plain text.   I'm also afraid it could cause us to flunk government
certifications.
 
On Windows, this really isn't a problem because command history is not
saved.  After a CMD session ends, the history is lost (unless you
install some third-party tool).
 
Perhaps there is a way to temporarily disable logging of command history
in the add-user-keycloak.sh?
 
 
 
 
Is there another way to do this?
 
The situation is even more complicated with Docker, since running the
script to change the Wildfly admin password requires restarting the
server, which shuts down the container. If you have an autoscaling
group, the container that gets brought up is not the container where you
changed the password, but instead the original container. This seems to
mean that the only way to have Keycloak run in Dockers in an autoscaling
group is to bake the admin passwords into the Docker image beforehand.
This isn't ideal; less so if the only way to add those passwords during
build time is to run the shell script that exposes the password on the
command line.
 
You need to set the password once for your database. This can be done
prior to accessing the admin console the first time. Take a look at
https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md,
you can use docker exec to do this.
 

-- 
http://www.fastmail.com - Faster than the air-speed velocity of an
                          unladen european swallow


From jorsol at gmail.com  Tue Feb 23 09:54:49 2016
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Tue, 23 Feb 2016 08:54:49 -0600
Subject: [keycloak-user] We have a new logo!
In-Reply-To: <CAJgngAeUcpiTerQ4JSt+sFW1AcjqLHeeqz3BAvLNtjfmm_+_-A@mail.gmail.com>
References: <CAJgngAeUcpiTerQ4JSt+sFW1AcjqLHeeqz3BAvLNtjfmm_+_-A@mail.gmail.com>
Message-ID: <CA+cVU8O+ey0-dY5OahpM312mEkrxmAQCTrq3Yucbxk2-=mLynA@mail.gmail.com>

Nice!, just a comment... the contrast of the letters KE and the background
is not good, try just with the same color of the last K in all letters...

cheers,


*Ing. Jorge Sol?rzano*
about.me/jorsol
<https://about.me/jorsol?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>

On Tue, Feb 23, 2016 at 7:20 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

>
>
>
> _______________________________________________
> 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/20160223/f79bf5c8/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak_google_plus_cover_1080x608.png
Type: image/png
Size: 103774 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/f79bf5c8/attachment-0001.png 

From sthorger at redhat.com  Tue Feb 23 13:51:55 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 19:51:55 +0100
Subject: [keycloak-user] Securely setting admin passwords
In-Reply-To: <1456237482.2552063.529395538.62B7C79E@webmail.messagingengine.com>
References: <1456237482.2552063.529395538.62B7C79E@webmail.messagingengine.com>
Message-ID: <CAJgngAfr-Ykt0E0ceH66evYAp8nzFFuWD-CwA6w1QXXFJfKaXg@mail.gmail.com>

On 23 February 2016 at 15:24, Aikeaguinea <aikeaguinea at xsmail.com> wrote:

> I'd be happy with KEYCLOAK-2501 (accepting the password on the command
> line). Then the docker exec approach wouldn't expose the password; this
> is essentially the approach I started with before I ran into the issue
> with the -p switch. (It would be equally desirable to have the same
> change for add-user --container for the Wildfly password; should I open
> a JIRA with Wildfly about this, or would the implementation of
> KEYCLOAK-2501 require the corresponding modification in Wildfly anyway?)
>

WildFly already supports prompting for the password


>
> Mounting the file via volume was something we looked into. We're setting
> things up in Amazon's Elastic Container Service, which uses autoscaling
> groups to bring up new instances automatically (though we don't think
> we'll really need that aspect of it all that much). My recollection is
> that the setup involved didn't seem worth the trouble because our Docker
> image is in a secure repository anyway. If we have to store the file
> someplace, might as well just copy it into the container and keep it in
> the image; at least that was the thinking. For people who put their
> images on a public registry this wouldn't be a good solution.
>
>
> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Marek Posolda
> <mposolda at redhat.com>
> Date: Tuesday, February 23, 2016 at 4:37 AM
> To: "stian at redhat.com" <stian at redhat.com>, Aikeaguinea
> <aikeaguinea at xsmail.com>
> Cc: keycloak-user <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Securely setting admin passwords
>
> Another possibility is to share the file keycloak-user.json with docker
> via volume. Then it's not hardcoded into the Docker image. The
> entrypoint script can check if the file shared through volume exists and
> copy it to standalone/configuration in that case.
>
> Marek
>
> On 23/02/16 10:10, Stian Thorgersen wrote:
>
>
> On 22 February 2016 at 16:10, Aikeaguinea <aikeaguinea at xsmail.com>
> wrote:
> With regard to Docker, things get more complicated. I believe it's not
> just the bash history but the Docker history itself that stores the
> commands.
>
> What about "docker exec" approach? We've fixed it in 1.9.0.Final so that
> it'll now prompt for a password if one isn't specified.
>
>
> Also, per one of the messages earlier on this chain, it is not advised
> to put secrets into Docker environment variables. These are accessible
> in many different ways.
>
> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stan Silvert
> <ssilvert at redhat.com>
> Date: Thursday, February 18, 2016 at 12:26 PM
> To: "stian at redhat.com" <stian at redhat.com>
> Cc: Stian Thorgersen <sthorger at redhat.com>, keycloak-user
> <keycloak-user at lists.jboss.org>
> Subject: Re: [keycloak-user] Securely setting admin passwords
>
> On 2/18/2016 12:14 PM, Stian Thorgersen wrote:
> It's security vs usability as usual. Allowing passing the password
> directly is convenient for developers, for Docker image, for
> provisioning tools, etc.. So we're not going to remove that it's
> required, but I do appreciate that if not used correctly it's a
> potential security risk. The worst case scenario here is really that
> someone gets an admins favorite password, as someone that has access to
> getting the bash history of that particular user will also be able to
> run the add-user script themselves. So if the admin wants to print his
> favorite password in clear text in the bash history we should not stop
> him.
>
> It's not our responsibility to clear the bash history, so we should not
> do that either.
> If there is a way to stop that one command from being saved in the bash
> history then we should do it.
>
> At the very least, we should print a warning message to let the
> administrator know he has done something that is potentially insecure.
>
>
> On 18 February 2016 at 16:53, Bruno Oliveira <bruno at abstractj.org>
> wrote:
> It's about balance. I'm not arguing here against it, I just don't see
> how it could strengthen security. Nothing will stop people to get their
> own gun and automate it with stdin :)
>
> On Thu, Feb 18, 2016 at 12:45 PM Stan Silvert <ssilvert at redhat.com>
> wrote:
> On 2/18/2016 9:29 AM, Bruno Oliveira wrote:
> I can be wrong, but this is not only our responsibility. For example, on
> Linux you are prompted for the password with passwd, but at the same
> time you could circumvent this using: echo 12345678 | sudo passwd admin
> --stdin.
>
> In this scenario security auditors won't blame the OS for this, but
> pretty much sysadmins and bad security practices. Anyways, whatever
> people think is the best, I'm fine.
> I agree with you there.  In that case you are doing something extra to
> shoot yourself in the foot.  We can't guard against that.
>
> We just shouldn't put the gun in your hand.
>
>
> On Thu, Feb 18, 2016 at 12:18 PM Stan Silvert <ssilvert at redhat.com>
> wrote:
> On 2/18/2016 9:10 AM, Bruno Oliveira wrote:
> I think the Jira created by Stian pretty much fixes the problem. Nope?
> Stian's JIRA says that if it is not specified on the command line then
> do the prompt.  But if we still allow setting it from the command line
> then the password can still be saved to the log in plain text.  Security
> auditors will always frown on that.
>
> So I'm saying we should either disallow setting on the command line or
> somehow disable saving to the log.  We shouldn't rely on an
> administrator to do the right thing.
>
>
>
> Something like:
>
> ./add-user-keycloak.sh -u user
> Password: ******
>
> Or
>
> ./add-user-keycloak-sh
> Username: joe
> Password: ******
>
> If this can't fix the issue, is also possible to disable bash_history
> temporarily. But I wouldn't take this route, because this is pretty much
> system administration responsibility.
>
>
> On Thu, Feb 18, 2016 at 11:47 AM Stan Silvert <ssilvert at redhat.com>
> wrote:
> On 2/18/2016 2:15 AM, Stian Thorgersen wrote:
>
>
> On 17 February 2016 at 17:09, Aikeaguinea <aikeaguinea at xsmail.com>
> wrote:
> It seems the add-user.sh  script for changing the admin password only
> accepts the password as a -p command-line parameter. This would expose
> the password in the command history, so I'd prefer not to use the
> command in its current form.
>
> That's a mistake we'll fix that. If not specified it should prompt for
> it. Added https://issues.jboss.org/browse/KEYCLOAK-2501
> After attending several security talks the last couple of days, I've
> become rather sensitized to this kind of issue.  I feel quite strongly
> that we should never allow the password to be written to history in
> plain text.   I'm also afraid it could cause us to flunk government
> certifications.
>
> On Windows, this really isn't a problem because command history is not
> saved.  After a CMD session ends, the history is lost (unless you
> install some third-party tool).
>
> Perhaps there is a way to temporarily disable logging of command history
> in the add-user-keycloak.sh?
>
>
>
>
> Is there another way to do this?
>
> The situation is even more complicated with Docker, since running the
> script to change the Wildfly admin password requires restarting the
> server, which shuts down the container. If you have an autoscaling
> group, the container that gets brought up is not the container where you
> changed the password, but instead the original container. This seems to
> mean that the only way to have Keycloak run in Dockers in an autoscaling
> group is to bake the admin passwords into the Docker image beforehand.
> This isn't ideal; less so if the only way to add those passwords during
> build time is to run the shell script that exposes the password on the
> command line.
>
> You need to set the password once for your database. This can be done
> prior to accessing the admin console the first time. Take a look at
> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/README.md
> ,
> you can use docker exec to do this.
>
>
> --
> http://www.fastmail.com - Faster than the air-speed velocity of an
>                           unladen european swallow
>
> _______________________________________________
> 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/20160223/ed7e2608/attachment.html 

From sthorger at redhat.com  Tue Feb 23 15:08:02 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 21:08:02 +0100
Subject: [keycloak-user] Keycloak 1.9.0.Final Released
Message-ID: <CAJgngAd6=DgZ_9sq0QGjf0yasqn093xhz5f4ZYGXupWactbPWA@mail.gmail.com>

For the full list of issues resolved check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.0.Final>
and
to download the release go to the Keycloak homepage
<http://keycloak.org/downloads>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/70e1a00d/attachment.html 

From darkness.renann at gmail.com  Tue Feb 23 15:47:09 2016
From: darkness.renann at gmail.com (Renann Prado)
Date: Tue, 23 Feb 2016 17:47:09 -0300
Subject: [keycloak-user] What did you guys use to document your API?
Message-ID: <CAEBys6+4DmgQ1_zKf3zdhjb1P7U26i+pGhR5Y1mjdtCH-jJO7g@mail.gmail.com>

So I found very nice the way the API is being documented and I'd like to
know what you guys have used to generate it.

http://keycloak.github.io/docs/rest-api/index.html

Thanks

Renann Prado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/5751c31b/attachment.html 

From bburke at redhat.com  Tue Feb 23 15:53:56 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 23 Feb 2016 15:53:56 -0500
Subject: [keycloak-user] What did you guys use to document your API?
In-Reply-To: <CAEBys6+4DmgQ1_zKf3zdhjb1P7U26i+pGhR5Y1mjdtCH-jJO7g@mail.gmail.com>
References: <CAEBys6+4DmgQ1_zKf3zdhjb1P7U26i+pGhR5Y1mjdtCH-jJO7g@mail.gmail.com>
Message-ID: <56CCC6E4.1000900@redhat.com>

We do it by hand....

.... joking...

Looks like its swagger:

https://github.com/keycloak/keycloak/blob/master/services/pom.xml#L189


On 2/23/2016 3:47 PM, Renann Prado wrote:
> So I found very nice the way the API is being documented and I'd like 
> to know what you guys have used to generate it.
>
> http://keycloak.github.io/docs/rest-api/index.html
>
> Thanks
>
> Renann Prado
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160223/8a908ab3/attachment-0001.html 

From mstrukel at redhat.com  Tue Feb 23 17:38:06 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 23 Feb 2016 23:38:06 +0100
Subject: [keycloak-user] What did you guys use to document your API?
In-Reply-To: <56CCC6E4.1000900@redhat.com>
References: <CAEBys6+4DmgQ1_zKf3zdhjb1P7U26i+pGhR5Y1mjdtCH-jJO7g@mail.gmail.com>
	<56CCC6E4.1000900@redhat.com>
Message-ID: <CA+1OW+iFmWadfDuMh+rm86GNvq9hntZuan7ZTzywe5ezD0FxUw@mail.gmail.com>

It's a bit more complex.

You can read all about it here:
http://blog.keycloak.org/2015/09/having-fun-with-rest-api-documentation.html
On Feb 23, 2016 9:55 PM, "Bill Burke" <bburke at redhat.com> wrote:

> We do it by hand....
>
> .... joking...
>
> Looks like its swagger:
>
> https://github.com/keycloak/keycloak/blob/master/services/pom.xml#L189
>
>
> On 2/23/2016 3:47 PM, Renann Prado wrote:
>
> So I found very nice the way the API is being documented and I'd like to
> know what you guys have used to generate it.
>
> http://keycloak.github.io/docs/rest-api/index.html
>
> Thanks
>
> Renann Prado
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160223/fcc22584/attachment.html 

From tyvain at gmail.com  Tue Feb 23 18:23:10 2016
From: tyvain at gmail.com (=?UTF-8?Q?Sylvain_Auger=2DL=C3=A9ger?=)
Date: Wed, 24 Feb 2016 10:23:10 +1100
Subject: [keycloak-user] Same user with different "sub" in JWT Token?
Message-ID: <CADjy3384_19PK6cdwHDemYVBgGJ7mMEqiVVeB=Cd+FF7Eis3Pg@mail.gmail.com>

Hi,

Is it possible to setup keycloak so that:
the JWT "sub" attribute would be different in every client for the same
user ?

This is to prevent from crossing information between clients.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/f9b48916/attachment.html 

From teatimej at gmail.com  Tue Feb 23 18:44:52 2016
From: teatimej at gmail.com (Michael Mok)
Date: Wed, 24 Feb 2016 07:44:52 +0800
Subject: [keycloak-user] keycloak 1.8.1 to 1.9.0 upgrade failed
Message-ID: <CAO=w+JN_EiRhLOoJrz+q2Ha-a+8de3mTXDwBL8fyPk_5tYKRtg@mail.gmail.com>

Hi there.

Keycloak 1.9.0 is working but this error keeps appearing in the log every
time I restart keycloak. :<


23:41:51,546 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 51) WFLYCLINF0002: Started users cache from keycloak
container
23:41:51,551 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 47) WFLYCLINF0002: Started realms cache from keycloak
container
23:41:51,684 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 46) WFLYCLINF0002: Started realmVersions cache from keycloak
container
23:41:52,827 INFO  [org.keycloak.services] (ServerService Thread Pool --
50) KC-SERVICES0001: Loading config from
/opt/keycloak/standalone/configuration/keycloak-server.json
23:41:56,771 INFO  [org.hibernate.jpa.internal.util.LogHelper]
(ServerService Thread Pool -- 50) HHH000204: Processing PersistenceUnitInfo
[
name: keycloak-default
...]
23:41:56,844 INFO  [org.hibernate.Version] (ServerService Thread Pool --
50) HHH000412: Hibernate Core {5.0.7.Final}
23:41:56,846 INFO  [org.hibernate.cfg.Environment] (ServerService Thread
Pool -- 50) HHH000206: hibernate.properties not found
23:41:56,848 INFO  [org.hibernate.cfg.Environment] (ServerService Thread
Pool -- 50) HHH000021: Bytecode provider name : javassist
23:41:56,894 INFO  [org.hibernate.annotations.common.Version]
(ServerService Thread Pool -- 50) HCANN000001: Hibernate Commons
Annotations {5.0.1.Final}
23:41:57,063 INFO  [org.hibernate.dialect.Dialect] (ServerService Thread
Pool -- 50) HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
23:41:57,114 INFO  [org.hibernate.envers.boot.internal.EnversServiceImpl]
(ServerService Thread Pool -- 50) Envers integration enabled? : true
23:41:57,965 INFO  [org.hibernate.validator.internal.util.Version]
(ServerService Thread Pool -- 50) HV000001: Hibernate Validator 5.2.3.Final
23:41:58,990 INFO
 [org.hibernate.hql.internal.QueryTranslatorFactoryInitiator]
(ServerService Thread Pool -- 50) HHH000397: Using ASTQueryTranslatorFactory
23:42:00,007 ERROR [org.keycloak.services] (ServerService Thread Pool --
50) KC-SERVICES0002: Failed to migrate datamodel:
java.lang.NullPointerException
at
org.keycloak.migration.migrators.MigrateTo1_9_0.migrate(MigrateTo1_9_0.java:42)
at
org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:93)
at
org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:152)
at
org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:94)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
at
org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
at
org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
at
org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
at
io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at
org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at
io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at
io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
at
io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
at
io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
at
org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)

23:42:00,214 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
Thread Pool -- 50) RESTEASY002225: Deploying javax.ws.rs.core.Application:
class org.keycloak.services.resources.KeycloakApp
lication
23:42:00,216 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
Thread Pool -- 50) RESTEASY002200: Adding class resource
org.keycloak.services.resources.JsResource from Application class o
rg.keycloak.services.resources.KeycloakApplication
23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
Thread Pool -- 50) RESTEASY002205: Adding provider class
org.keycloak.services.filters.KeycloakTransactionCommitter from App
lication class org.keycloak.services.resources.KeycloakApplication
23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
Thread Pool -- 50) RESTEASY002200: Adding class resource
org.keycloak.services.resources.ThemeResource from Application clas
s org.keycloak.services.resources.KeycloakApplication
23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
Thread Pool -- 50) RESTEASY002200: Adding class resource
org.keycloak.services.resources.QRCodeResource from Application cla
ss org.keycloak.services.resources.KeycloakApplication
23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
Thread Pool -- 50) RESTEASY002220: Adding singleton resource
org.keycloak.services.resources.WelcomeResource from Applicatio
n class org.keycloak.services.resources.KeycloakApplication
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/82011eff/attachment.html 

From bruno at abstractj.org  Tue Feb 23 19:40:41 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 24 Feb 2016 00:40:41 +0000
Subject: [keycloak-user] keycloak 1.8.1 to 1.9.0 upgrade failed
In-Reply-To: <CAO=w+JN_EiRhLOoJrz+q2Ha-a+8de3mTXDwBL8fyPk_5tYKRtg@mail.gmail.com>
References: <CAO=w+JN_EiRhLOoJrz+q2Ha-a+8de3mTXDwBL8fyPk_5tYKRtg@mail.gmail.com>
Message-ID: <CAM5SUC46RqSq-vqmSeMwO1ymyvrw70hNaY6MTwt+HGTifqys5A@mail.gmail.com>

Could you please provide the steps to reproduce?

On Tue, Feb 23, 2016, 8:44 PM Michael Mok <teatimej at gmail.com> wrote:

> Hi there.
>
> Keycloak 1.9.0 is working but this error keeps appearing in the log every
> time I restart keycloak. :<
>
>
> 23:41:51,546 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 51) WFLYCLINF0002: Started users cache from keycloak
> container
> 23:41:51,551 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 47) WFLYCLINF0002: Started realms cache from keycloak
> container
> 23:41:51,684 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 46) WFLYCLINF0002: Started realmVersions cache from keycloak
> container
> 23:41:52,827 INFO  [org.keycloak.services] (ServerService Thread Pool --
> 50) KC-SERVICES0001: Loading config from
> /opt/keycloak/standalone/configuration/keycloak-server.json
> 23:41:56,771 INFO  [org.hibernate.jpa.internal.util.LogHelper]
> (ServerService Thread Pool -- 50) HHH000204: Processing PersistenceUnitInfo
> [
> name: keycloak-default
> ...]
> 23:41:56,844 INFO  [org.hibernate.Version] (ServerService Thread Pool --
> 50) HHH000412: Hibernate Core {5.0.7.Final}
> 23:41:56,846 INFO  [org.hibernate.cfg.Environment] (ServerService Thread
> Pool -- 50) HHH000206: hibernate.properties not found
> 23:41:56,848 INFO  [org.hibernate.cfg.Environment] (ServerService Thread
> Pool -- 50) HHH000021: Bytecode provider name : javassist
> 23:41:56,894 INFO  [org.hibernate.annotations.common.Version]
> (ServerService Thread Pool -- 50) HCANN000001: Hibernate Commons
> Annotations {5.0.1.Final}
> 23:41:57,063 INFO  [org.hibernate.dialect.Dialect] (ServerService Thread
> Pool -- 50) HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
> 23:41:57,114 INFO  [org.hibernate.envers.boot.internal.EnversServiceImpl]
> (ServerService Thread Pool -- 50) Envers integration enabled? : true
> 23:41:57,965 INFO  [org.hibernate.validator.internal.util.Version]
> (ServerService Thread Pool -- 50) HV000001: Hibernate Validator 5.2.3.Final
> 23:41:58,990 INFO
>  [org.hibernate.hql.internal.QueryTranslatorFactoryInitiator]
> (ServerService Thread Pool -- 50) HHH000397: Using ASTQueryTranslatorFactory
> 23:42:00,007 ERROR [org.keycloak.services] (ServerService Thread Pool --
> 50) KC-SERVICES0002: Failed to migrate datamodel:
> java.lang.NullPointerException
> at
> org.keycloak.migration.migrators.MigrateTo1_9_0.migrate(MigrateTo1_9_0.java:42)
> at
> org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:93)
> at
> org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:152)
> at
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:94)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
> at
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
> at
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
> at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
> at
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
> at
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
> at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
> at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>
> 23:42:00,214 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
> Thread Pool -- 50) RESTEASY002225: Deploying javax.ws.rs.core.Application:
> class org.keycloak.services.resources.KeycloakApp
> lication
> 23:42:00,216 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
> Thread Pool -- 50) RESTEASY002200: Adding class resource
> org.keycloak.services.resources.JsResource from Application class o
> rg.keycloak.services.resources.KeycloakApplication
> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
> Thread Pool -- 50) RESTEASY002205: Adding provider class
> org.keycloak.services.filters.KeycloakTransactionCommitter from App
> lication class org.keycloak.services.resources.KeycloakApplication
> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
> Thread Pool -- 50) RESTEASY002200: Adding class resource
> org.keycloak.services.resources.ThemeResource from Application clas
> s org.keycloak.services.resources.KeycloakApplication
> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
> Thread Pool -- 50) RESTEASY002200: Adding class resource
> org.keycloak.services.resources.QRCodeResource from Application cla
> ss org.keycloak.services.resources.KeycloakApplication
> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService
> Thread Pool -- 50) RESTEASY002220: Adding singleton resource
> org.keycloak.services.resources.WelcomeResource from Applicatio
> n class org.keycloak.services.resources.KeycloakApplication
>
> _______________________________________________
> 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/20160224/b63eab8b/attachment-0001.html 

From jaxley at expedia.com  Wed Feb 24 00:02:44 2016
From: jaxley at expedia.com (Jason Axley)
Date: Wed, 24 Feb 2016 05:02:44 +0000
Subject: [keycloak-user] Custom user attribute documentation correct?
Message-ID: <E0693522-564C-483D-8D03-47AE74483811@expedia.com>

Is the documentation here accurate for v1.9.0-Final? http://keycloak.github.io/docs/userguide/keycloak-server/html/custom-user-attributes.html#d4e3678  It says (for the user account profile pages, for example) that attributes must be of the form like ?user.attributes.mobile? but if you do this, Freemarker can?t render the template.  I can render it if I use ?account.mobile?, however it?s not displaying the data that is definitely there on the user profile (I can see it as an administrator on the Attributes tab).


        <div class="form-group ${messagesPerField.printIfExists('account.mobile','has-error')}">

            <div class="col-sm-2 col-md-2">

                <label for="account.mobile" class="control-label">${msg("mobile")}</label> <span class="required">*</span>

            </div>


            <div class="col-sm-10 col-md-10">

                <input type="text" class="form-control" id="account.mobile" name="account.mobile" value="${(account.mobile!'')?html}"/>

            </div>

        </div>

-Jason

Jason Axley
Sr. Security Engineer, Expedia Worldwide Engineering Team
425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv)
333 108th Ave NE, 9S-282, Bellevue, WA 98004
EWE Security Wiki<https://confluence/display/POS/EWE+Security>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/3d19d669/attachment.html 

From jaxley at expedia.com  Wed Feb 24 00:08:34 2016
From: jaxley at expedia.com (Jason Axley)
Date: Wed, 24 Feb 2016 05:08:34 +0000
Subject: [keycloak-user] Custom user attribute documentation correct?
Message-ID: <F32D9541-4293-4F46-BCCF-656CF622FC03@expedia.com>

2 seconds after I found that there were custom attribute template examples in examples/themes that gave me the nuance that is missing or lost on me in the documentation.

You need to use the format ?user.attributes.mobile? everywhere except when rendering the value from the model.  There you use ${account.attributes.mobile} for the interpolation.  Any chance those could match and both be account.attributes.<blah> rather than be different?


        <div class="form-group ${messagesPerField.printIfExists('user.attributes.mobile','has-error')}">

            <div class="col-sm-2 col-md-2">

                <label for="user.attributes.mobile" class="control-label">${msg("mobile")}</label> <span class="required">*</span>

            </div>


            <div class="col-sm-10 col-md-10">

                <input type="text" class="form-control" id="user.attributes.mobile" name="user.attributes.mobile" value="${(account.attributes.mobile!'')?html}"/>

            </div>

        </div>

-Jason

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Jason Axley <jaxley at expedia.com<mailto:jaxley at expedia.com>>
Date: Tuesday, February 23, 2016 at 9:02 PM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: [keycloak-user] Custom user attribute documentation correct?

Is the documentation here accurate for v1.9.0-Final? http://keycloak.github.io/docs/userguide/keycloak-server/html/custom-user-attributes.html#d4e3678  It says (for the user account profile pages, for example) that attributes must be of the form like ?user.attributes.mobile? but if you do this, Freemarker can?t render the template.  I can render it if I use ?account.mobile?, however it?s not displaying the data that is definitely there on the user profile (I can see it as an administrator on the Attributes tab).


        <div class="form-group ${messagesPerField.printIfExists('account.mobile','has-error')}">

            <div class="col-sm-2 col-md-2">

                <label for="account.mobile" class="control-label">${msg("mobile")}</label> <span class="required">*</span>

            </div>


            <div class="col-sm-10 col-md-10">

                <input type="text" class="form-control" id="account.mobile" name="account.mobile" value="${(account.mobile!'')?html}"/>

            </div>

        </div>

-Jason

Jason Axley
Sr. Security Engineer, Expedia Worldwide Engineering Team
425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv)
333 108th Ave NE, 9S-282, Bellevue, WA 98004
EWE Security Wiki<https://confluence/display/POS/EWE+Security>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/e766efcf/attachment.html 

From sthorger at redhat.com  Wed Feb 24 00:53:10 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Feb 2016 06:53:10 +0100
Subject: [keycloak-user] Same user with different "sub" in JWT Token?
In-Reply-To: <CADjy3384_19PK6cdwHDemYVBgGJ7mMEqiVVeB=Cd+FF7Eis3Pg@mail.gmail.com>
References: <CADjy3384_19PK6cdwHDemYVBgGJ7mMEqiVVeB=Cd+FF7Eis3Pg@mail.gmail.com>
Message-ID: <CAJgngAd_eBJvpXYDRygJ3jPr0M2Wjx95vmboy7yjmh=RxRaeKA@mail.gmail.com>

Not sure why you would want to. The user id isn't sensitive information.

This is not something we'd support out of the box, but you should be able
to use a custom protocol mapper to do this.

On 24 February 2016 at 00:23, Sylvain Auger-L?ger <tyvain at gmail.com> wrote:

> Hi,
>
> Is it possible to setup keycloak so that:
> the JWT "sub" attribute would be different in every client for the same
> user ?
>
> This is to prevent from crossing information between clients.
>
> Thank you.
>
> _______________________________________________
> 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/20160224/c747b0b6/attachment-0001.html 

From sthorger at redhat.com  Wed Feb 24 00:58:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Feb 2016 06:58:09 +0100
Subject: [keycloak-user] keycloak 1.8.1 to 1.9.0 upgrade failed
In-Reply-To: <CAM5SUC46RqSq-vqmSeMwO1ymyvrw70hNaY6MTwt+HGTifqys5A@mail.gmail.com>
References: <CAO=w+JN_EiRhLOoJrz+q2Ha-a+8de3mTXDwBL8fyPk_5tYKRtg@mail.gmail.com>
	<CAM5SUC46RqSq-vqmSeMwO1ymyvrw70hNaY6MTwt+HGTifqys5A@mail.gmail.com>
Message-ID: <CAJgngAek5PW=o8CkY30rDZNXEEZtaUNTHO5c8gEz1uFQO2GA6A@mail.gmail.com>

I've identified the problem and created
https://issues.jboss.org/browse/KEYCLOAK-2539.

There's a simple work around until we have a release with the fix, before
upgrading do the following:

1. Login to the admin console
2. Select the master realm
3. Under Realm Settings set a value for 'HTML Display Name'
4. Click 'Save'

On 24 February 2016 at 01:40, Bruno Oliveira <bruno at abstractj.org> wrote:

> Could you please provide the steps to reproduce?
>
> On Tue, Feb 23, 2016, 8:44 PM Michael Mok <teatimej at gmail.com> wrote:
>
>> Hi there.
>>
>> Keycloak 1.9.0 is working but this error keeps appearing in the log every
>> time I restart keycloak. :<
>>
>>
>> 23:41:51,546 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 51) WFLYCLINF0002: Started users cache from keycloak
>> container
>> 23:41:51,551 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 47) WFLYCLINF0002: Started realms cache from keycloak
>> container
>> 23:41:51,684 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 46) WFLYCLINF0002: Started realmVersions cache from keycloak
>> container
>> 23:41:52,827 INFO  [org.keycloak.services] (ServerService Thread Pool --
>> 50) KC-SERVICES0001: Loading config from
>> /opt/keycloak/standalone/configuration/keycloak-server.json
>> 23:41:56,771 INFO  [org.hibernate.jpa.internal.util.LogHelper]
>> (ServerService Thread Pool -- 50) HHH000204: Processing PersistenceUnitInfo
>> [
>> name: keycloak-default
>> ...]
>> 23:41:56,844 INFO  [org.hibernate.Version] (ServerService Thread Pool --
>> 50) HHH000412: Hibernate Core {5.0.7.Final}
>> 23:41:56,846 INFO  [org.hibernate.cfg.Environment] (ServerService Thread
>> Pool -- 50) HHH000206: hibernate.properties not found
>> 23:41:56,848 INFO  [org.hibernate.cfg.Environment] (ServerService Thread
>> Pool -- 50) HHH000021: Bytecode provider name : javassist
>> 23:41:56,894 INFO  [org.hibernate.annotations.common.Version]
>> (ServerService Thread Pool -- 50) HCANN000001: Hibernate Commons
>> Annotations {5.0.1.Final}
>> 23:41:57,063 INFO  [org.hibernate.dialect.Dialect] (ServerService Thread
>> Pool -- 50) HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>> 23:41:57,114 INFO  [org.hibernate.envers.boot.internal.EnversServiceImpl]
>> (ServerService Thread Pool -- 50) Envers integration enabled? : true
>> 23:41:57,965 INFO  [org.hibernate.validator.internal.util.Version]
>> (ServerService Thread Pool -- 50) HV000001: Hibernate Validator 5.2.3.Final
>> 23:41:58,990 INFO
>>  [org.hibernate.hql.internal.QueryTranslatorFactoryInitiator]
>> (ServerService Thread Pool -- 50) HHH000397: Using ASTQueryTranslatorFactory
>> 23:42:00,007 ERROR [org.keycloak.services] (ServerService Thread Pool --
>> 50) KC-SERVICES0002: Failed to migrate datamodel:
>> java.lang.NullPointerException
>> at
>> org.keycloak.migration.migrators.MigrateTo1_9_0.migrate(MigrateTo1_9_0.java:42)
>> at
>> org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:93)
>> at
>> org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:152)
>> at
>> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:94)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> at
>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>> at
>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>> at
>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>> at
>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>> at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>> at
>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>> at
>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>> at
>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>> at
>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>> at
>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>> at
>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>> at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>> at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:745)
>> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>
>> 23:42:00,214 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002225: Deploying
>> javax.ws.rs.core.Application: class
>> org.keycloak.services.resources.KeycloakApp
>> lication
>> 23:42:00,216 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002200: Adding class resource
>> org.keycloak.services.resources.JsResource from Application class o
>> rg.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002205: Adding provider class
>> org.keycloak.services.filters.KeycloakTransactionCommitter from App
>> lication class org.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002200: Adding class resource
>> org.keycloak.services.resources.ThemeResource from Application clas
>> s org.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002200: Adding class resource
>> org.keycloak.services.resources.QRCodeResource from Application cla
>> ss org.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002220: Adding singleton resource
>> org.keycloak.services.resources.WelcomeResource from Applicatio
>> n class org.keycloak.services.resources.KeycloakApplication
>>
>> _______________________________________________
>> 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/20160224/936e2a52/attachment.html 

From teatimej at gmail.com  Tue Feb 23 20:05:07 2016
From: teatimej at gmail.com (Michael Mok)
Date: Wed, 24 Feb 2016 09:05:07 +0800
Subject: [keycloak-user] Fwd:  keycloak 1.8.1 to 1.9.0 upgrade failed
In-Reply-To: <CAO=w+JM1JOdBO4SrQeb1=U0jcxjuYXUMAxXzB5WT2PbMa14+Bg@mail.gmail.com>
References: <CAO=w+JN_EiRhLOoJrz+q2Ha-a+8de3mTXDwBL8fyPk_5tYKRtg@mail.gmail.com>
	<CAM5SUC46RqSq-vqmSeMwO1ymyvrw70hNaY6MTwt+HGTifqys5A@mail.gmail.com>
	<CAO=w+JM1JOdBO4SrQeb1=U0jcxjuYXUMAxXzB5WT2PbMa14+Bg@mail.gmail.com>
Message-ID: <CAO=w+JND=LLGmxP1jTsANVJgvStePv6UiHF1HCp8LP8RpAt1Mw@mail.gmail.com>

Hi Bruno

I will try to provide the steps in another email. Here are more info.
Thanks.

Database is MySQL 5.7 , default char set is utf8

Database migration log table attached. Not sure why it decides to redo
1.6.1 again hmmm...


On 24 February 2016 at 08:40, Bruno Oliveira <bruno at abstractj.org> wrote:

> Could you please provide the steps to reproduce?
>
> On Tue, Feb 23, 2016, 8:44 PM Michael Mok <teatimej at gmail.com> wrote:
>
>> Hi there.
>>
>> Keycloak 1.9.0 is working but this error keeps appearing in the log every
>> time I restart keycloak. :<
>>
>>
>> 23:41:51,546 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 51) WFLYCLINF0002: Started users cache from keycloak
>> container
>> 23:41:51,551 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 47) WFLYCLINF0002: Started realms cache from keycloak
>> container
>> 23:41:51,684 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 46) WFLYCLINF0002: Started realmVersions cache from keycloak
>> container
>> 23:41:52,827 INFO  [org.keycloak.services] (ServerService Thread Pool --
>> 50) KC-SERVICES0001: Loading config from
>> /opt/keycloak/standalone/configuration/keycloak-server.json
>> 23:41:56,771 INFO  [org.hibernate.jpa.internal.util.LogHelper]
>> (ServerService Thread Pool -- 50) HHH000204: Processing PersistenceUnitInfo
>> [
>> name: keycloak-default
>> ...]
>> 23:41:56,844 INFO  [org.hibernate.Version] (ServerService Thread Pool --
>> 50) HHH000412: Hibernate Core {5.0.7.Final}
>> 23:41:56,846 INFO  [org.hibernate.cfg.Environment] (ServerService Thread
>> Pool -- 50) HHH000206: hibernate.properties not found
>> 23:41:56,848 INFO  [org.hibernate.cfg.Environment] (ServerService Thread
>> Pool -- 50) HHH000021: Bytecode provider name : javassist
>> 23:41:56,894 INFO  [org.hibernate.annotations.common.Version]
>> (ServerService Thread Pool -- 50) HCANN000001: Hibernate Commons
>> Annotations {5.0.1.Final}
>> 23:41:57,063 INFO  [org.hibernate.dialect.Dialect] (ServerService Thread
>> Pool -- 50) HHH000400: Using dialect: org.hibernate.dialect.MySQL5Dialect
>> 23:41:57,114 INFO  [org.hibernate.envers.boot.internal.EnversServiceImpl]
>> (ServerService Thread Pool -- 50) Envers integration enabled? : true
>> 23:41:57,965 INFO  [org.hibernate.validator.internal.util.Version]
>> (ServerService Thread Pool -- 50) HV000001: Hibernate Validator 5.2.3.Final
>> 23:41:58,990 INFO
>>  [org.hibernate.hql.internal.QueryTranslatorFactoryInitiator]
>> (ServerService Thread Pool -- 50) HHH000397: Using ASTQueryTranslatorFactory
>> 23:42:00,007 ERROR [org.keycloak.services] (ServerService Thread Pool --
>> 50) KC-SERVICES0002: Failed to migrate datamodel:
>> java.lang.NullPointerException
>> at
>> org.keycloak.migration.migrators.MigrateTo1_9_0.migrate(MigrateTo1_9_0.java:42)
>> at
>> org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:93)
>> at
>> org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:152)
>> at
>> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:94)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> at
>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>> at
>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>> at
>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>> at
>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>> at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>> at
>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>> at
>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>> at
>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>> at
>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>> at
>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>> at
>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>> at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>> at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> at java.lang.Thread.run(Thread.java:745)
>> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>
>> 23:42:00,214 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002225: Deploying
>> javax.ws.rs.core.Application: class
>> org.keycloak.services.resources.KeycloakApp
>> lication
>> 23:42:00,216 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002200: Adding class resource
>> org.keycloak.services.resources.JsResource from Application class o
>> rg.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002205: Adding provider class
>> org.keycloak.services.filters.KeycloakTransactionCommitter from App
>> lication class org.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002200: Adding class resource
>> org.keycloak.services.resources.ThemeResource from Application clas
>> s org.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002200: Adding class resource
>> org.keycloak.services.resources.QRCodeResource from Application cla
>> ss org.keycloak.services.resources.KeycloakApplication
>> 23:42:00,217 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (ServerService Thread Pool -- 50) RESTEASY002220: Adding singleton resource
>> org.keycloak.services.resources.WelcomeResource from Applicatio
>> n class org.keycloak.services.resources.KeycloakApplication
>>
>> _______________________________________________
>> 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/20160224/15bb1453/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2016-02-24 08:58:29.png
Type: image/png
Size: 214696 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/15bb1453/attachment-0001.png 

From sthorger at redhat.com  Wed Feb 24 01:25:01 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Feb 2016 07:25:01 +0100
Subject: [keycloak-user] Custom user attribute documentation correct?
In-Reply-To: <F32D9541-4293-4F46-BCCF-656CF622FC03@expedia.com>
References: <F32D9541-4293-4F46-BCCF-656CF622FC03@expedia.com>
Message-ID: <CAJgngAd3AYVkXs3g0BF__buyFeQkgD=GTXHBUFtAEJ6Atq1_Kw@mail.gmail.com>

You can create a JIRA for it.

On 24 February 2016 at 06:08, Jason Axley <jaxley at expedia.com> wrote:

> 2 seconds after I found that there were custom attribute template examples
> in examples/themes that gave me the nuance that is missing or lost on me in
> the documentation.
>
> You need to use the format ?user.attributes.mobile? everywhere except when
> rendering the value from the model.  There you use
> ${account.attributes.mobile} for the interpolation.  Any chance those could
> match and both be account.attributes.<blah> rather than be different?
>
>         <div class="form-group
> ${messagesPerField.printIfExists('user.attributes.mobile','has-error')}">
>
>             <div class="col-sm-2 col-md-2">
>
>                 <label for="user.attributes.mobile"
> class="control-label">${msg("mobile")}</label> <span
> class="required">*</span>
>
>             </div>
>
>
>             <div class="col-sm-10 col-md-10">
>
>                 <input type="text" class="form-control"
> id="user.attributes.mobile" name="user.attributes.mobile"
> value="${(account.attributes.mobile!'')?html}"/>
>
>             </div>
>
>         </div>
>
> -Jason
>
> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Jason Axley <
> jaxley at expedia.com>
> Date: Tuesday, February 23, 2016 at 9:02 PM
> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: [keycloak-user] Custom user attribute documentation correct?
>
> Is the documentation here accurate for v1.9.0-Final?
> http://keycloak.github.io/docs/userguide/keycloak-server/html/custom-user-attributes.html#d4e3678
> It says (for the user account profile pages, for example) that attributes
> must be of the form like ?user.attributes.mobile? but if you do this,
> Freemarker can?t render the template.  I can render it if I use
> ?account.mobile?, however it?s not displaying the data that is definitely
> there on the user profile (I can see it as an administrator on the
> Attributes tab).
>
>         <div class="form-group
> ${messagesPerField.printIfExists('account.mobile','has-error')}">
>
>             <div class="col-sm-2 col-md-2">
>
>                 <label for="account.mobile"
> class="control-label">${msg("mobile")}</label> <span
> class="required">*</span>
>
>             </div>
>
>
>             <div class="col-sm-10 col-md-10">
>
>                 <input type="text" class="form-control"
> id="account.mobile" name="account.mobile"
> value="${(account.mobile!'')?html}"/>
>
>             </div>
>
>         </div>
>
> -Jason
>
> *Jason Axley*
>
> Sr. Security Engineer, Expedia Worldwide Engineering Team
>
> 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv)
>
> 333 108th Ave NE, 9S-282, Bellevue, WA 98004
>
> EWE Security Wiki <https://confluence/display/POS/EWE+Security>
>
> _______________________________________________
> 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/20160224/8f6a8643/attachment.html 

From elathril at gmail.com  Wed Feb 24 04:57:03 2016
From: elathril at gmail.com (Maciek Dawidowicz)
Date: Wed, 24 Feb 2016 10:57:03 +0100
Subject: [keycloak-user] Getting username for Logout Event
Message-ID: <CAL1OwZquZ1uidJQLPqZQ5K0qeCKrRjMPHoHJtQWi12JkWpeFtw@mail.gmail.com>

Hello,

I am trying to log information about successful login and logouts in my
application. I've written a simple event listener to pass data to my
application audit logger in correct format. In case of Login event there
are following details available:
auth_method: openid-connect
auth_type: code
redirect_uri:
http://localhost:8080/auth/admin/master/console/?redirect_fragment=%2Frealms%2Fmaster%2Fevents
consent: no_consent_required
code_id: 28e74ada-cb0e-4901-91bb-2915f1a3b8e0

*username: admin*
however in logout event details there is only:
redirect_uri:
http://localhost:8080/auth/admin/master/console/#/realms/master/events

This means all i get in this event related to User is his id:


*User: a680de68-1c9a-40dd-a642-c56d5912b7b6*
Is there a simple way for my event listener to get username based on User
Id? Or perhaps a way to enable putting username in logout event details?

thanks,
Maciej Dawidowicz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/e4a51aab/attachment.html 

From satyajit.das at spire2grow.com  Wed Feb 24 04:58:50 2016
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Wed, 24 Feb 2016 15:28:50 +0530
Subject: [keycloak-user] Issue with logout.
Message-ID: <CA+oCsRo_zkZMb=A+XxDi6_g3UY-HHO_eKyYi7nwHpbocX6NynQ@mail.gmail.com>

Hi Team we are facing the below issue with logout.

i use login/logout restful service:

after login
i get tokenid say "t1" and refreshtokenid say "rt1"

1) We have registered a webservice as a keycloak client (example demo123)
with access type as bearer.
2) When I call the logout rest service:

if (isPublic()) { // if client is public access type formparams.add(new
BasicNameValuePair(OAuth2Constants.CLIENT_ID, "demo123")); }

URI logoutUri = KeycloakUriBuilder.fromUri(getBaseUrl(request) + "/auth")
.path(ServiceUrlConstants.TOKEN_SERVICE_LOGOUT_PATH) .build("RealmName");

the logout gives 204 for client's access type as open.

but when i again hit the service with the token id "t1" after logout.
Still i can get the response. *Note this response doesnt hit keycloak*.

Regards,
Satya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/4e6cf206/attachment.html 

From velias at redhat.com  Wed Feb 24 05:00:06 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Wed, 24 Feb 2016 11:00:06 +0100
Subject: [keycloak-user] Blacklisting/whitelisting of domains for email
 entered during user registration
Message-ID: <56CD7F26.3080306@redhat.com>

Hi,

Is there this feature (i was not able to find it) in Keycloak or is it 
planned (I was not able to find it in JIRA)?

It is extremely useful (mainly blacklisting) in some cases. Eg. 
yesterday we fought spammers in one of our public systems. Spammers 
registered lots of new users using disposable email service and then 
used them to create spam content. We blacklisted domains used by the 
disposable email service from registration, which stopped spammers 
immediately.
We do not use Keycloak there yet, but maybe in future. Current system we 
use has blacklisting available OOTB.

Registration email whitelisting may be useful if you create service for 
eg. your employees only, and want them to register there with company 
emails only.

I think it should be possible to add new step into "Registration" flow 
to perform this blacklisting, we can do it yourself probably, but it 
should be cool to have this very useful feature present in the Keycloak 
out of the box.

WDYT about this feature, can I create jira feature request for it?

Vlastimil

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team


From kga.official at gmail.com  Wed Feb 24 05:18:47 2016
From: kga.official at gmail.com (Akshay Kini)
Date: Wed, 24 Feb 2016 15:48:47 +0530
Subject: [keycloak-user] Keycloak as a SAML SP: Is it possible to
 configure Keycloak to use RSA-SHA256 as the algorithm to sign assertions.
In-Reply-To: <56BE672D.8090805@redhat.com>
References: <CAFtx=Tk2X-uQDuFbO5f_rEHRHkdNLPE7ArtMW3uLc-Q0_FJwgg@mail.gmail.com>
	<CAFtx=Tnutkf-X-bHjKXuOdiC1kRh-eM67ZnCmJ7ikuNrEEiXRg@mail.gmail.com>
	<56BE672D.8090805@redhat.com>
Message-ID: <CAFtx=TnCHGgxTvuhk4DDSe620NunNGVs1HWs_s-SVH-_a4v9-w@mail.gmail.com>

Hi Bill,

Sorry for the delay in replies.

I am only using Keycloak client SP adapter.

I had already tried your suggested configuration and it doesn't work.
Snippet of my keycloak configuration file:
<IDP entityID="hpsw-idp" signatureAlgorithm="RSA_SHA512"
signatureCanonicalizationMethod="http://www.w3.org/2001/10/xml-exc-c14n#"
signaturesRequired="true">


So I went further and I spent some time trying to debug the libraries and I
think I found the root cause (please excuse me if I've made a mistake in
the analysis).

I enabled TRACE logging on org.keycloak and couldn't figure out the cause
of the problem due to inadequate logging in the relevant classes.

Instead, I attached a debugger and I saw that the Parser does indeed pick
up the value correctly, but unfortunately the signing side of the library
don't seem to use the new value. I went as far back as
org.keycloak.saml.BaseSAML2BindingBuilder and saw that it's value is not
correctly initialized (see further in mail for root cause).

So, for example in org.keycloak.saml.BaseSAML2BindingBuilder#postBinding()
method a new  BasePostBindingBuilder is created and the constructor itself
is used to sign the document. No where in that call chain, the signing
algorithm is set to anything other than the default. I even tried attaching
a break-point to the "setter" method and can confirm that it isn't called
during the signing.

Here is a guess of the technical problem:
The thread stack snippet is:
org.keycloak.saml.BaseSAML2BindingBuilder#postBinding()
org.keycloak.adapters.saml.SamlUtil#sendSaml()
*org.keycloak.adapters.saml.profile.AbstractSamlAuthenticationHandler (near
line 438) ---
org.keycloak.adapters.saml.AbstractInitiateLogin#sendAuthnRequest() ::: *-->
At this point, the signature information is lost, i.e. we need to modify
this method and include signature information in the method calls. i.e.
deployment.signatureAlgorithm should be passed down to the relevant
methods.


*In case the mailing list is getting a bit difficult to work on this issue,
Could we create a defect in Jira and talk over there? I am pretty sure this
is a defect for the Keycloak as SAML SP case.*


Thanks,
Regards,
Akshay




On Sat, Feb 13, 2016 at 4:43 AM, Bill Burke <bburke at redhat.com> wrote:

> So, you're not using keycloak-server, just our SAML client SP adapter?
>
>
> http://keycloak.github.io/docs/userguide/saml-client-adapter/html/adapter-config.html#d4e124
>
> You can set the signature algorithm there.  The IDP section is basically
> describing what the IDP expects when you communicate to it.
>
>
> On 2/12/2016 6:43 AM, Akshay Kini wrote:
>
> Hi Bill,
>
> Thanks for looking into this.
>
> The usecase is:
>
> Keycloak is an SP and it is sending an AuthnRequest via HTTP Post. This
> AuthnRequest is always using RSA-SHA1 for signing.
>
> I have configured the Keycloak config file as follows:
> <keycloak-saml-adapter>
>     <SP entityID="exampleEntityID"
>         sslPolicy="NONE"
>         logoutPage="/logout.jsp"
>
> nameIDPolicyFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>         forceAuthentication="false"
>         signatureAlgorithm="RSA_SHA256">
>
>
> In-fact the SP element doesn't have the "signatureAlgorithm" documented
> anywhere in the SAML Client Apapter Reference Guide (it only exists for the
> IDP).
>
> Now this is a bit of unfamiliar territory for me, but I looked into the
> Keycloak Code base (master):
> I see that the org.keycloak.adapters.saml.config.parsers.SPXmlParser
> doesn't deal with ConfigXmlConstants.SIGNATURE_ALGORITHM_ATTR while the
> IDPXmlParser does.
>
>
> Again, thanks for looking into this.
>
> P.S. Sorry to all the mailing list subscribers, this "chain" might get
> broken despite me changing the subject. I am not sure how to fix that when
> using Gmail and subscribing to a digest mailing-list. Please send a direct
> e-mail to me if you know how to fix that.
>
> Thanks,
> Regards,
> Akshay
>
>
> On Thu, Feb 11, 2016 at 7:36 PM, < <keycloak-user-request at lists.jboss.org>
> keycloak-user-request at lists.jboss.org> wrote:
>
>> Send keycloak-user mailing list submissions to
>>         keycloak-user at lists.jboss.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>> or, via email, send a message with subject or body 'help' to
>>         keycloak-user-request at lists.jboss.org
>>
>> You can reach the person managing the list at
>>         keycloak-user-owner at lists.jboss.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of keycloak-user digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: User-Federation (Renann Prado)
>>    2. Re: User-Federation (Renann Prado)
>>    3. Re: Keycloak as a SAML SP: Is it possible to configure
>>       Keycloak to use RSA-SHA256 as the algorithm to sign assertions.
>>       (Bill Burke)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 11 Feb 2016 11:16:29 -0200
>> From: Renann Prado <prado.renann at gmail.com>
>> Subject: Re: [keycloak-user] User-Federation
>> To: Reed Lewis <RLewis at carbonite.com>
>> Cc: keycloak-user at lists.jboss.org
>> Message-ID:
>>         <CAEBys6KM1-n6wFqTJAAqb_aYaQdZwuiaUz2AspF5d-8Za=
>> <E9wQ at mail.gmail.com>E9wQ at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Is there any recommended way to make sure these endpoints won't be spammed
>> by an attacker? Looks like these endpoints need to be open to anyone.
>>
>> Thanks
>> On Feb 3, 2016 11:18, "Reed Lewis" < <RLewis at carbonite.com>
>> RLewis at carbonite.com> wrote:
>>
>> > If you use the federation provider listed here:
>> >
>> > [0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
>> > [1]: https://github.com/Smartling/keycloak-user-migration-provider
>> >
>> > You can specify a URL that will be called when a user needs to be
>> > validated.
>> >
>> > There are three requests that need to be implemented in your sever.
>> >
>> > GET <baseURL>/api/users/<username>/
>> > If the user exists, it should return a 200 with a json object with the
>> > return type ?application/json? with the following fields:
>> > username
>> > email
>> > emailVerified
>> > firstName
>> > lastName
>> > roles [?user?]
>> >
>> > If the user does not exist, return a 404
>> >
>> > HEAD <baseURL>/api/users/<username>/
>> > Always return 200
>> >
>> > POST <baseURL>/api/users/<username>/
>> > The password is posted to you in a json object.
>> > Return 200 if the password is OK, 401 if not.  In both cases return no
>> > data.
>> >
>> > I wrote a small python module which implements these methods which works
>> > quite well.
>> >
>> > Reed
>> >
>> > From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stuart
>> Jacobs <
>> > stuart.jacobs at symbiotics.co.za>
>> > Date: Wednesday, February 3, 2016 at 2:40 AM
>> > To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>> > Subject: [keycloak-user] User-Federation
>> >
>> > Hi Everyone,
>> >
>> > I have an application that runs on a postgresql database, keycloak has
>> > been configured and has created all the required tables/columns in my
>> > schema using liquibase on start up of the keycloak server.
>> >
>> > I need to authenticate users using the projects existing user table
>> > obtaining the username and password from this table.
>> >
>> > I have had a look at the federation provider project under the example
>> > projects but this still eludes me as to how I change the keycloak
>> mapping
>> > to use my own tables in postgress?
>> >
>> > Can someone please point me in the right direction or if someone has
>> > implemented such a solution please share how you have done it?
>> >
>> > Thanks everyone.
>> >
>> >   Regards,
>> >   Stuart Jacobs
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > www.symbiotics.co.za
>> >
>> >
>> ********************************************************************************
>> > This email and any accompanying attachments may contain confidential and
>> > proprietary information. This information is private and protected by
>> law
>> > and, accordingly, if you are not the intended recipient, you are
>> requested
>> > to delete this entire communication immediately and are notified that
>> any
>> > disclosure, copying or distribution of or taking any action based on
>> this
>> > information is prohibited.
>> >
>> > Emails cannot be guaranteed to be secure or free of errors or viruses.
>> The
>> > sender does not accept any liability or responsibility for any
>> > interception, corruption, destruction, loss, late arrival or
>> incompleteness
>> > of or tampering or interference with any of the information contained in
>> > this email or for its incorrect delivery or non-delivery for whatsoever
>> > reason or for its effect on any electronic device of the recipient.
>> >
>> >
>> ********************************************************************************
>> >
>> >
>> > _______________________________________________
>> > 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/20160211/d777c2bf/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 11 Feb 2016 11:17:14 -0200
>> From: Renann Prado <prado.renann at gmail.com>
>> Subject: Re: [keycloak-user] User-Federation
>> To: Reed Lewis <RLewis at carbonite.com>
>> Cc: keycloak-user at lists.jboss.org
>> Message-ID:
>>         <CAEBys6+i6jFdycaCg-rf9vC=
>> <T7chbrkKeWsfAbNvC2tidKdhZw at mail.gmail.com>
>> T7chbrkKeWsfAbNvC2tidKdhZw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Everyone*
>> On Feb 11, 2016 11:16, "Renann Prado" < <prado.renann at gmail.com>
>> prado.renann at gmail.com> wrote:
>>
>> > Is there any recommended way to make sure these endpoints won't be
>> spammed
>> > by an attacker? Looks like these endpoints need to be open to anyone.
>> >
>> > Thanks
>> > On Feb 3, 2016 11:18, "Reed Lewis" < <RLewis at carbonite.com>
>> RLewis at carbonite.com> wrote:
>> >
>> >> If you use the federation provider listed here:
>> >>
>> >> [0]: http://tech.smartling.com/migrate-to-keycloak-with-zero-downtime/
>> >> [1]: https://github.com/Smartling/keycloak-user-migration-provider
>> >>
>> >> You can specify a URL that will be called when a user needs to be
>> >> validated.
>> >>
>> >> There are three requests that need to be implemented in your sever.
>> >>
>> >> GET <baseURL>/api/users/<username>/
>> >> If the user exists, it should return a 200 with a json object with the
>> >> return type ?application/json? with the following fields:
>> >> username
>> >> email
>> >> emailVerified
>> >> firstName
>> >> lastName
>> >> roles [?user?]
>> >>
>> >> If the user does not exist, return a 404
>> >>
>> >> HEAD <baseURL>/api/users/<username>/
>> >> Always return 200
>> >>
>> >> POST <baseURL>/api/users/<username>/
>> >> The password is posted to you in a json object.
>> >> Return 200 if the password is OK, 401 if not.  In both cases return no
>> >> data.
>> >>
>> >> I wrote a small python module which implements these methods which
>> works
>> >> quite well.
>> >>
>> >> Reed
>> >>
>> >> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stuart
>> Jacobs
>> >> <stuart.jacobs at symbiotics.co.za>
>> >> Date: Wednesday, February 3, 2016 at 2:40 AM
>> >> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
>> >> Subject: [keycloak-user] User-Federation
>> >>
>> >> Hi Everyone,
>> >>
>> >> I have an application that runs on a postgresql database, keycloak has
>> >> been configured and has created all the required tables/columns in my
>> >> schema using liquibase on start up of the keycloak server.
>> >>
>> >> I need to authenticate users using the projects existing user table
>> >> obtaining the username and password from this table.
>> >>
>> >> I have had a look at the federation provider project under the example
>> >> projects but this still eludes me as to how I change the keycloak
>> mapping
>> >> to use my own tables in postgress?
>> >>
>> >> Can someone please point me in the right direction or if someone has
>> >> implemented such a solution please share how you have done it?
>> >>
>> >> Thanks everyone.
>> >>
>> >>   Regards,
>> >>   Stuart Jacobs
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> www.symbiotics.co.za
>> >>
>> >>
>> ********************************************************************************
>> >> This email and any accompanying attachments may contain confidential
>> and
>> >> proprietary information. This information is private and protected by
>> law
>> >> and, accordingly, if you are not the intended recipient, you are
>> requested
>> >> to delete this entire communication immediately and are notified that
>> any
>> >> disclosure, copying or distribution of or taking any action based on
>> this
>> >> information is prohibited.
>> >>
>> >> Emails cannot be guaranteed to be secure or free of errors or viruses.
>> >> The sender does not accept any liability or responsibility for any
>> >> interception, corruption, destruction, loss, late arrival or
>> incompleteness
>> >> of or tampering or interference with any of the information contained
>> in
>> >> this email or for its incorrect delivery or non-delivery for whatsoever
>> >> reason or for its effect on any electronic device of the recipient.
>> >>
>> >>
>> ********************************************************************************
>> >>
>> >>
>> >> _______________________________________________
>> >> 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/20160211/6164ad32/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 11 Feb 2016 09:06:49 -0500
>> From: Bill Burke <bburke at redhat.com>
>> Subject: Re: [keycloak-user] Keycloak as a SAML SP: Is it possible to
>>         configure Keycloak to use RSA-SHA256 as the algorithm to sign
>>         assertions.
>> To: keycloak-user at lists.jboss.org
>> Message-ID: <56BC9579.8080102 at redhat.com>
>> Content-Type: text/plain; charset="windows-1252"
>>
>> Where?  Keycloak Saml SP?  Keycloak Server interaction with an
>> app/client?  Or Keycloak Server acting as an SP in a broker scenario?
>>
>> They all *should* support plugging in the algorithm.  Did you configure
>> this correctly?
>>
>> On 2/11/2016 6:29 AM, Akshay Kini wrote:
>> > Hi Folks,
>> >
>> > We are using Keycloak as a SAML SP.
>> >
>> > I notice that SAML Assertions are signed using rsa-sha1, could we
>> > configure it to use RSA-SHA256?
>> >
>> > Thanks,
>> > Regards,
>> > Akshay
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.jboss.org/pipermail/keycloak-user/attachments/20160211/573d1ced/attachment.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> End of keycloak-user Digest, Vol 26, Issue 56
>> *********************************************
>>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/0cb58243/attachment-0001.html 

From adrianmatei at gmail.com  Wed Feb 24 05:35:10 2016
From: adrianmatei at gmail.com (Adrian Matei)
Date: Wed, 24 Feb 2016 11:35:10 +0100
Subject: [keycloak-user] 403 when loading user info
Message-ID: <CAG=THF0OPQVoMcRrGY8ALEn6dx1KEEO55W7g1siUabTzi=oJug@mail.gmail.com>

Hi everybody,

Could  you help me please with a hard nut to crack? We have the following
situation:
When calling the userinfo endpoint over an enterprise proxy server (js
adapter loadUserInfo() method):

https://hostname/auth/realms/realmname/protocol/openid-connect/userinfo

we get 403 Forbidden with no Access-Controls headers set. Here is the funny
part - it happens only in Chrome, Firefox and Opera. With Safari and IE11
it seems to be working.

The stacktrace from server.log does not tell me much....:
11:30:31,906 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n]
(http-/159.232.186.74:8443-6) RESTEASY000105: Failed to execute:
org.keycloak.services.ErrorResponseException
        at
org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issueUserInfo(UserInfoEndpoint.java:130)
[keycloak-services-1.7.0.Final.jar:1.7.0.Final]
        at
org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issueUserInfoGet(UserInfoEndpoint.java:103)
[keycloak-services-1.7.0.Final.jar:1.7.0.Final]
        at sun.reflect.GeneratedMethodAccessor342.invoke(Unknown Source)
[:1.8.0_66]
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_66]
        at java.lang.reflect.Method.invoke(Method.java:497)
[rt.jar:1.8.0_66]
        at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:158)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:106)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:153)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:561)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:543)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:128)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
[keycloak-services-1.7.0.Final.jar:1.7.0.Final]
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
[jboss-as-web-7.5.5.Final-redhat-3.jar:7.5.5.Final-redhat-3]
        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]


Thanks,
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/f7900663/attachment.html 

From mposolda at redhat.com  Wed Feb 24 05:49:39 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 24 Feb 2016 11:49:39 +0100
Subject: [keycloak-user] Blacklisting/whitelisting of domains for email
 entered during user registration
In-Reply-To: <56CD7F26.3080306@redhat.com>
References: <56CD7F26.3080306@redhat.com>
Message-ID: <56CD8AC3.4010700@redhat.com>

+1 to create JIRA for it and have it somehow available OOTB.

As you mentioned, you can already customize registration flow and add 
custom validation. But ATM this doesn't apply for account updates. So if 
attacker registers with some "valid" email, but then login to account 
management and change email to "evil at blacklisted.com" the validation 
won't be applied.

Also the validation won't be applied to users registered through social, 
so if you have "review profile" enabled, the attacker can register with 
some valid facebook account, but then change email to 
"evil at blacklisted.com" on the ReviewProfile page. This can be catched 
again by creating custom authenticator for firstBrokerLogin flow. Bad 
thing is, that you need separate validator for registration and separate 
for social (and still the account update is not handled)

AFAIK we have JIRA to allow easily configure set of validators for some 
fields, when validator will be applied to all of 3 usecases like:
- registration
- account update
- update profile required action (applies to reviewProfile after social too)

This will allow that you for example, you can specify regex for 
"birthDay" field in one place in Keycloak admin console and the same 
validator for "birthDay" field will be applied in all 3 places. We can 
have same type of validator for email blacklisting/whitelisting IMO.

Marek


On 24/02/16 11:00, Vlastimil Elias wrote:
> Hi,
>
> Is there this feature (i was not able to find it) in Keycloak or is it
> planned (I was not able to find it in JIRA)?
>
> It is extremely useful (mainly blacklisting) in some cases. Eg.
> yesterday we fought spammers in one of our public systems. Spammers
> registered lots of new users using disposable email service and then
> used them to create spam content. We blacklisted domains used by the
> disposable email service from registration, which stopped spammers
> immediately.
> We do not use Keycloak there yet, but maybe in future. Current system we
> use has blacklisting available OOTB.
>
> Registration email whitelisting may be useful if you create service for
> eg. your employees only, and want them to register there with company
> emails only.
>
> I think it should be possible to add new step into "Registration" flow
> to perform this blacklisting, we can do it yourself probably, but it
> should be cool to have this very useful feature present in the Keycloak
> out of the box.
>
> WDYT about this feature, can I create jira feature request for it?
>
> Vlastimil
>


From mposolda at redhat.com  Wed Feb 24 05:53:56 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 24 Feb 2016 11:53:56 +0100
Subject: [keycloak-user] Blacklisting/whitelisting of domains for email
 entered during user registration
In-Reply-To: <56CD8AC3.4010700@redhat.com>
References: <56CD7F26.3080306@redhat.com> <56CD8AC3.4010700@redhat.com>
Message-ID: <56CD8BC4.3060502@redhat.com>

On 24/02/16 11:49, Marek Posolda wrote:
> +1 to create JIRA for it and have it somehow available OOTB.
>
> As you mentioned, you can already customize registration flow and add
> custom validation. But ATM this doesn't apply for account updates. So if
> attacker registers with some "valid" email, but then login to account
> management and change email to "evil at blacklisted.com" the validation
> won't be applied.
>
> Also the validation won't be applied to users registered through social,
> so if you have "review profile" enabled, the attacker can register with
> some valid facebook account, but then change email to
> "evil at blacklisted.com" on the ReviewProfile page. This can be catched
> again by creating custom authenticator for firstBrokerLogin flow. Bad
> thing is, that you need separate validator for registration and separate
> for social (and still the account update is not handled)
>
> AFAIK we have JIRA to allow easily configure set of validators for some
> fields, when validator will be applied to all of 3 usecases like:
> - registration
> - account update
> - update profile required action (applies to reviewProfile after social too)
>
> This will allow that you for example, you can specify regex for
> "birthDay" field in one place in Keycloak admin console and the same
> validator for "birthDay" field will be applied in all 3 places. We can
> have same type of validator for email blacklisting/whitelisting IMO.
Found older thread when we discuss it - 
http://lists.jboss.org/pipermail/keycloak-dev/2015-November/005767.html .

Marek
>
> Marek
>
>
> On 24/02/16 11:00, Vlastimil Elias wrote:
>> Hi,
>>
>> Is there this feature (i was not able to find it) in Keycloak or is it
>> planned (I was not able to find it in JIRA)?
>>
>> It is extremely useful (mainly blacklisting) in some cases. Eg.
>> yesterday we fought spammers in one of our public systems. Spammers
>> registered lots of new users using disposable email service and then
>> used them to create spam content. We blacklisted domains used by the
>> disposable email service from registration, which stopped spammers
>> immediately.
>> We do not use Keycloak there yet, but maybe in future. Current system we
>> use has blacklisting available OOTB.
>>
>> Registration email whitelisting may be useful if you create service for
>> eg. your employees only, and want them to register there with company
>> emails only.
>>
>> I think it should be possible to add new step into "Registration" flow
>> to perform this blacklisting, we can do it yourself probably, but it
>> should be cool to have this very useful feature present in the Keycloak
>> out of the box.
>>
>> WDYT about this feature, can I create jira feature request for it?
>>
>> Vlastimil
>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From mposolda at redhat.com  Wed Feb 24 06:00:44 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 24 Feb 2016 12:00:44 +0100
Subject: [keycloak-user] Getting username for Logout Event
In-Reply-To: <CAL1OwZquZ1uidJQLPqZQ5K0qeCKrRjMPHoHJtQWi12JkWpeFtw@mail.gmail.com>
References: <CAL1OwZquZ1uidJQLPqZQ5K0qeCKrRjMPHoHJtQWi12JkWpeFtw@mail.gmail.com>
Message-ID: <56CD8D5C.3090109@redhat.com>

On 24/02/16 10:57, Maciek Dawidowicz wrote:
> Hello,
>
> I am trying to log information about successful login and logouts in 
> my application. I've written a simple event listener to pass data to 
> my application audit logger in correct format. In case of Login event 
> there are following details available:
> auth_method: openid-connect
> auth_type: code
> redirect_uri: 
> http://localhost:8080/auth/admin/master/console/?redirect_fragment=%2Frealms%2Fmaster%2Fevents
> consent: no_consent_required
> code_id: 28e74ada-cb0e-4901-91bb-2915f1a3b8e0
> *username: admin
> *
> however in logout event details there is only:
> redirect_uri: 
> http://localhost:8080/auth/admin/master/console/#/realms/master/events
>
> This means all i get in this event related to User is his id:
> *User: a680de68-1c9a-40dd-a642-c56d5912b7b6
>
> *
> Is there a simple way for my event listener to get username based on 
> User Id? Or perhaps a way to enable putting username in logout event 
> details?
Feel free to create JIRA for put username in logout event details.

The possibility to retrieve username in logout events is alreadt doable 
though, but it's a bit complicated. You will need to pass 
KeycloakSession to your EventListener implementation (KeycloakSession is 
available in EventListenerProviderFactory.create() ). Then once you have 
KeycloakSession you can use it to lookup realm and then username based 
on userId. Something like this:
RealmModel realm = session.getContext().getRealm();
UserModel user = session.users().getUserById(userId, realm);
String username = user.getUsername();

Marek
>
> thanks,
> Maciej Dawidowicz
>
>
> _______________________________________________
> 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/20160224/f6659670/attachment-0001.html 

From mposolda at redhat.com  Wed Feb 24 06:09:19 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 24 Feb 2016 12:09:19 +0100
Subject: [keycloak-user] Issue with logout.
In-Reply-To: <CA+oCsRo_zkZMb=A+XxDi6_g3UY-HHO_eKyYi7nwHpbocX6NynQ@mail.gmail.com>
References: <CA+oCsRo_zkZMb=A+XxDi6_g3UY-HHO_eKyYi7nwHpbocX6NynQ@mail.gmail.com>
Message-ID: <56CD8F5F.90806@redhat.com>

On 24/02/16 10:58, Satyajit Das wrote:
> Hi Team we are facing the below issue with logout.
>
> i use login/logout restful service:
>
> after login
> i get tokenid say "t1" and refreshtokenid say "rt1"
>
> 1) We have registered a webservice as a keycloak client (example 
> demo123) with access type as bearer.
> 2) When I call the logout rest service:
>
> if (isPublic()) { // if client is public access type 
> formparams.add(new BasicNameValuePair(OAuth2Constants.CLIENT_ID, 
> "demo123")); }
>
> URI logoutUri = KeycloakUriBuilder.fromUri(getBaseUrl(request) + 
> "/auth") .path(ServiceUrlConstants.TOKEN_SERVICE_LOGOUT_PATH) 
> .build("RealmName");
>
> the logout gives 204 for client's access type as open.
>
> but when i again hit the service with the token id "t1" after logout.
> Still i can get the response. *Note this response doesnt hit keycloak*.
Yes, it works this way and that's why we suggest to use short lifetimes 
for accessToken (1 minute). This means that access token needs to be 
refreshed every 1 minute and the request for refreshing token actually 
needs to hit Keycloak server (in your case, refresh won't success 
because you already did logout).

Marek
>
> Regards,
> Satya
>
>
> _______________________________________________
> 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/20160224/ced795fc/attachment.html 

From thomas.darimont at googlemail.com  Wed Feb 24 06:17:23 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 24 Feb 2016 12:17:23 +0100
Subject: [keycloak-user] Blacklisting/whitelisting of domains for email
 entered during user registration
In-Reply-To: <56CD8BC4.3060502@redhat.com>
References: <56CD7F26.3080306@redhat.com> <56CD8AC3.4010700@redhat.com>
	<56CD8BC4.3060502@redhat.com>
Message-ID: <CAK-7U1gzSX77AsX9gyGS8xSoo3ks_0Bqg7VNtOhjYsK_Jrd99w@mail.gmail.com>

Would be very helpful, indeed!

Additionally I'd recommend to use the recaptcha support see:
http://keycloak.github.io/docs/userguide/keycloak-server/html/recaptcha.html

2016-02-24 11:53 GMT+01:00 Marek Posolda <mposolda at redhat.com>:

> On 24/02/16 11:49, Marek Posolda wrote:
> > +1 to create JIRA for it and have it somehow available OOTB.
> >
> > As you mentioned, you can already customize registration flow and add
> > custom validation. But ATM this doesn't apply for account updates. So if
> > attacker registers with some "valid" email, but then login to account
> > management and change email to "evil at blacklisted.com" the validation
> > won't be applied.
> >
> > Also the validation won't be applied to users registered through social,
> > so if you have "review profile" enabled, the attacker can register with
> > some valid facebook account, but then change email to
> > "evil at blacklisted.com" on the ReviewProfile page. This can be catched
> > again by creating custom authenticator for firstBrokerLogin flow. Bad
> > thing is, that you need separate validator for registration and separate
> > for social (and still the account update is not handled)
> >
> > AFAIK we have JIRA to allow easily configure set of validators for some
> > fields, when validator will be applied to all of 3 usecases like:
> > - registration
> > - account update
> > - update profile required action (applies to reviewProfile after social
> too)
> >
> > This will allow that you for example, you can specify regex for
> > "birthDay" field in one place in Keycloak admin console and the same
> > validator for "birthDay" field will be applied in all 3 places. We can
> > have same type of validator for email blacklisting/whitelisting IMO.
> Found older thread when we discuss it -
> http://lists.jboss.org/pipermail/keycloak-dev/2015-November/005767.html .
>
> Marek
> >
> > Marek
> >
> >
> > On 24/02/16 11:00, Vlastimil Elias wrote:
> >> Hi,
> >>
> >> Is there this feature (i was not able to find it) in Keycloak or is it
> >> planned (I was not able to find it in JIRA)?
> >>
> >> It is extremely useful (mainly blacklisting) in some cases. Eg.
> >> yesterday we fought spammers in one of our public systems. Spammers
> >> registered lots of new users using disposable email service and then
> >> used them to create spam content. We blacklisted domains used by the
> >> disposable email service from registration, which stopped spammers
> >> immediately.
> >> We do not use Keycloak there yet, but maybe in future. Current system we
> >> use has blacklisting available OOTB.
> >>
> >> Registration email whitelisting may be useful if you create service for
> >> eg. your employees only, and want them to register there with company
> >> emails only.
> >>
> >> I think it should be possible to add new step into "Registration" flow
> >> to perform this blacklisting, we can do it yourself probably, but it
> >> should be cool to have this very useful feature present in the Keycloak
> >> out of the box.
> >>
> >> WDYT about this feature, can I create jira feature request for it?
> >>
> >> Vlastimil
> >>
> > _______________________________________________
> > 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/20160224/cd31dd72/attachment.html 

From thomas.raehalme at aitiofinland.com  Wed Feb 24 06:26:18 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 24 Feb 2016 13:26:18 +0200
Subject: [keycloak-user] Blacklisting/whitelisting of domains for email
 entered during user registration
In-Reply-To: <56CD8AC3.4010700@redhat.com>
References: <56CD7F26.3080306@redhat.com>
	<56CD8AC3.4010700@redhat.com>
Message-ID: <CAPyAMoY09acUWy_m3wyrGOJmU8ipHaLmLMmGoO6pGgPVEjLmTA@mail.gmail.com>

Hi!

This would be really useful!

In my opinion email addresses should be enforced also when using identity
providers and the email address originates from, for example, Google.
Combined with whitelisting you could then restrict users to a specific
Google Apps domain(s).

Best regards,
Thomas


On Wed, Feb 24, 2016 at 12:49 PM, Marek Posolda <mposolda at redhat.com> wrote:

> +1 to create JIRA for it and have it somehow available OOTB.
>
> As you mentioned, you can already customize registration flow and add
> custom validation. But ATM this doesn't apply for account updates. So if
> attacker registers with some "valid" email, but then login to account
> management and change email to "evil at blacklisted.com" the validation
> won't be applied.
>
> Also the validation won't be applied to users registered through social,
> so if you have "review profile" enabled, the attacker can register with
> some valid facebook account, but then change email to
> "evil at blacklisted.com" on the ReviewProfile page. This can be catched
> again by creating custom authenticator for firstBrokerLogin flow. Bad
> thing is, that you need separate validator for registration and separate
> for social (and still the account update is not handled)
>
> AFAIK we have JIRA to allow easily configure set of validators for some
> fields, when validator will be applied to all of 3 usecases like:
> - registration
> - account update
> - update profile required action (applies to reviewProfile after social
> too)
>
> This will allow that you for example, you can specify regex for
> "birthDay" field in one place in Keycloak admin console and the same
> validator for "birthDay" field will be applied in all 3 places. We can
> have same type of validator for email blacklisting/whitelisting IMO.
>
> Marek
>
>
> On 24/02/16 11:00, Vlastimil Elias wrote:
> > Hi,
> >
> > Is there this feature (i was not able to find it) in Keycloak or is it
> > planned (I was not able to find it in JIRA)?
> >
> > It is extremely useful (mainly blacklisting) in some cases. Eg.
> > yesterday we fought spammers in one of our public systems. Spammers
> > registered lots of new users using disposable email service and then
> > used them to create spam content. We blacklisted domains used by the
> > disposable email service from registration, which stopped spammers
> > immediately.
> > We do not use Keycloak there yet, but maybe in future. Current system we
> > use has blacklisting available OOTB.
> >
> > Registration email whitelisting may be useful if you create service for
> > eg. your employees only, and want them to register there with company
> > emails only.
> >
> > I think it should be possible to add new step into "Registration" flow
> > to perform this blacklisting, we can do it yourself probably, but it
> > should be cool to have this very useful feature present in the Keycloak
> > out of the box.
> >
> > WDYT about this feature, can I create jira feature request for it?
> >
> > Vlastimil
> >
>
> _______________________________________________
> 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/20160224/4a6f75b9/attachment.html 

From satyajit.das at spire2grow.com  Wed Feb 24 06:45:42 2016
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Wed, 24 Feb 2016 17:15:42 +0530
Subject: [keycloak-user] Issue with logout.
In-Reply-To: <56CD8F5F.90806@redhat.com>
References: <CA+oCsRo_zkZMb=A+XxDi6_g3UY-HHO_eKyYi7nwHpbocX6NynQ@mail.gmail.com>
	<56CD8F5F.90806@redhat.com>
Message-ID: <CA+oCsRr=hY6KDJntNxOy0W8mFPMQGJdHVcCGsDVeyv8taxnaJQ@mail.gmail.com>

Hi Marek,

We cant have access token so short lived because users can login and do
operations and can stay logged in for some time.

What we are relying is that once the logout url is called using refresh
token id. The user when tries to access a webservice using the token should
not be allowed to as the logout service has been called.

But the user can get the data, using the old token. Any suggesstion how to
stop this behaiviour.

Regards,
Satya.



On Wed, Feb 24, 2016 at 4:39 PM, Marek Posolda <mposolda at redhat.com> wrote:

> On 24/02/16 10:58, Satyajit Das wrote:
>
> Hi Team we are facing the below issue with logout.
>
> i use login/logout restful service:
>
> after login
> i get tokenid say "t1" and refreshtokenid say "rt1"
>
> 1) We have registered a webservice as a keycloak client (example demo123)
> with access type as bearer.
> 2) When I call the logout rest service:
>
> if (isPublic()) { // if client is public access type formparams.add(new
> BasicNameValuePair(OAuth2Constants.CLIENT_ID, "demo123")); }
>
> URI logoutUri = KeycloakUriBuilder.fromUri(getBaseUrl(request) + "/auth")
> .path(ServiceUrlConstants.TOKEN_SERVICE_LOGOUT_PATH) .build("RealmName");
>
> the logout gives 204 for client's access type as open.
>
> but when i again hit the service with the token id "t1" after logout.
> Still i can get the response. *Note this response doesnt hit keycloak*.
>
> Yes, it works this way and that's why we suggest to use short lifetimes
> for accessToken (1 minute). This means that access token needs to be
> refreshed every 1 minute and the request for refreshing token actually
> needs to hit Keycloak server (in your case, refresh won't success because
> you already did logout).
>
> Marek
>
>
> Regards,
> Satya
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160224/2ba47fc9/attachment-0001.html 

From mposolda at redhat.com  Wed Feb 24 07:31:15 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 24 Feb 2016 13:31:15 +0100
Subject: [keycloak-user] Issue with logout.
In-Reply-To: <CA+oCsRr=hY6KDJntNxOy0W8mFPMQGJdHVcCGsDVeyv8taxnaJQ@mail.gmail.com>
References: <CA+oCsRo_zkZMb=A+XxDi6_g3UY-HHO_eKyYi7nwHpbocX6NynQ@mail.gmail.com>
	<56CD8F5F.90806@redhat.com>
	<CA+oCsRr=hY6KDJntNxOy0W8mFPMQGJdHVcCGsDVeyv8taxnaJQ@mail.gmail.com>
Message-ID: <56CDA293.6080009@redhat.com>

On 24/02/16 12:45, Satyajit Das wrote:
> Hi Marek,
>
> We cant have access token so short lived because users can login and 
> do operations and can stay logged in for some time.
In that case, you can do refreshing tokens after some period. Basically 
before you send request to REST service, you will check if your 
accessToken is still valid (you can parse it and see expiration period). 
If it is outdated, you will send request to Keycloak to refresh the 
access token. That's how our adapters work. If you use adapter, you can 
be logged to application for a long time even if accessToken lifespan is 
just 1 minute.

If you really can't rely on short access token, there is possibility 
that your REST service will always send request to Keycloak to 
doublecheck if access token is still valid. We have support for Token 
introspection ( https://tools.ietf.org/html/rfc7662 ). The endpoint 
should be under 
http://localhost:8080/auth/realms/YourREALMName/protocol/openid-connect/token/introspect 
. Note that this has performance impact as REST service will always need 
to contact Keycloak to doublecheck token.

Marek
>
> What we are relying is that once the logout url is called using 
> refresh token id. The user when tries to access a webservice using the 
> token should not be allowed to as the logout service has been called.
>
> But the user can get the data, using the old token. Any suggesstion 
> how to stop this behaiviour.
>
> Regards,
> Satya.
>
>
>
> On Wed, Feb 24, 2016 at 4:39 PM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 24/02/16 10:58, Satyajit Das wrote:
>>     Hi Team we are facing the below issue with logout.
>>
>>     i use login/logout restful service:
>>
>>     after login
>>     i get tokenid say "t1" and refreshtokenid say "rt1"
>>
>>     1) We have registered a webservice as a keycloak client (example
>>     demo123) with access type as bearer.
>>     2) When I call the logout rest service:
>>
>>     if (isPublic()) { // if client is public access type
>>     formparams.add(new BasicNameValuePair(OAuth2Constants.CLIENT_ID,
>>     "demo123")); }
>>
>>     URI logoutUri = KeycloakUriBuilder.fromUri(getBaseUrl(request) +
>>     "/auth") .path(ServiceUrlConstants.TOKEN_SERVICE_LOGOUT_PATH)
>>     .build("RealmName");
>>
>>     the logout gives 204 for client's access type as open.
>>
>>     but when i again hit the service with the token id "t1" after logout.
>>     Still i can get the response. *Note this response doesnt hit
>>     keycloak*.
>     Yes, it works this way and that's why we suggest to use short
>     lifetimes for accessToken (1 minute). This means that access token
>     needs to be refreshed every 1 minute and the request for
>     refreshing token actually needs to hit Keycloak server (in your
>     case, refresh won't success because you already did logout).
>
>     Marek
>>
>>     Regards,
>>     Satya
>>
>>
>>     _______________________________________________
>>     keycloak-user mailing list
>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/8a2d3def/attachment.html 

From velias at redhat.com  Wed Feb 24 08:16:07 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Wed, 24 Feb 2016 14:16:07 +0100
Subject: [keycloak-user] Blacklisting/whitelisting of domains for email
 entered during user registration
In-Reply-To: <56CD8AC3.4010700@redhat.com>
References: <56CD7F26.3080306@redhat.com> <56CD8AC3.4010700@redhat.com>
Message-ID: <56CDAD17.3090204@redhat.com>

Hi,

you are right, it should be better to have common set of 
blacklisted/whitelisted domains for all user profile related actions 
(register, update profile), so it is similar as user profile attribute 
validation. But as it is not a common validation I'll create new Feature 
Request in jira for this (and probably link it to the common user 
attribute validation jira).

Thanks everybody in this thread for their opinion.

Vlastimil

On 24.2.2016 11:49, Marek Posolda wrote:
> +1 to create JIRA for it and have it somehow available OOTB.
>
> As you mentioned, you can already customize registration flow and add 
> custom validation. But ATM this doesn't apply for account updates. So 
> if attacker registers with some "valid" email, but then login to 
> account management and change email to "evil at blacklisted.com" the 
> validation won't be applied.
>
> Also the validation won't be applied to users registered through 
> social, so if you have "review profile" enabled, the attacker can 
> register with some valid facebook account, but then change email to 
> "evil at blacklisted.com" on the ReviewProfile page. This can be catched 
> again by creating custom authenticator for firstBrokerLogin flow. Bad 
> thing is, that you need separate validator for registration and 
> separate for social (and still the account update is not handled)
>
> AFAIK we have JIRA to allow easily configure set of validators for 
> some fields, when validator will be applied to all of 3 usecases like:
> - registration
> - account update
> - update profile required action (applies to reviewProfile after 
> social too)
>
> This will allow that you for example, you can specify regex for 
> "birthDay" field in one place in Keycloak admin console and the same 
> validator for "birthDay" field will be applied in all 3 places. We can 
> have same type of validator for email blacklisting/whitelisting IMO.
>
> Marek
>
>
> On 24/02/16 11:00, Vlastimil Elias wrote:
>> Hi,
>>
>> Is there this feature (i was not able to find it) in Keycloak or is it
>> planned (I was not able to find it in JIRA)?
>>
>> It is extremely useful (mainly blacklisting) in some cases. Eg.
>> yesterday we fought spammers in one of our public systems. Spammers
>> registered lots of new users using disposable email service and then
>> used them to create spam content. We blacklisted domains used by the
>> disposable email service from registration, which stopped spammers
>> immediately.
>> We do not use Keycloak there yet, but maybe in future. Current system we
>> use has blacklisting available OOTB.
>>
>> Registration email whitelisting may be useful if you create service for
>> eg. your employees only, and want them to register there with company
>> emails only.
>>
>> I think it should be possible to add new step into "Registration" flow
>> to perform this blacklisting, we can do it yourself probably, but it
>> should be cool to have this very useful feature present in the Keycloak
>> out of the box.
>>
>> WDYT about this feature, can I create jira feature request for it?
>>
>> Vlastimil
>>
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team


From marc.boorshtein at tremolosecurity.com  Wed Feb 24 08:20:17 2016
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Wed, 24 Feb 2016 08:20:17 -0500
Subject: [keycloak-user] Accurate description of Keycloak's capabilities?
Message-ID: <CAH2S7UAacB-wYAC+Dx_g9df2WBeGi=w2uAuiuOsuX7-5KqbbAQ@mail.gmail.com>

All,

I'm going to be presenting OpenUnison at an OpenShift briefing tomorrow and
have been asked to include a slide on how OpenUnison and Keycloak relate to
each other.  Based on getting Keycloak running and looking at the website
and following the list I'm planning on breaking down KC's features as such:

Authentication
* OIDC
* SAML2
* Social
* TOTP
* IdP "Proxy" for both SAML2 and OIDC

User Data Sources
* LDAP
* AD
* Custom

Role Management
* Local database
* Mapped to external data source

Application Integration
* SAML2
* OIDC/OAuth2
* Reverse Proxy with header injection

UI Pages
* Themed

I want to make sure this is accurate, so I'd appreciate any feedback that
you have.

Thanks

Marc Boorshtein
CTO Tremolo Security
marc.boorshtein at tremolosecurity.com
<marc.boorshtein at tremolosecurity.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/1610c507/attachment.html 

From tdudgeon.ml at gmail.com  Wed Feb 24 08:57:50 2016
From: tdudgeon.ml at gmail.com (Tim Dudgeon)
Date: Wed, 24 Feb 2016 13:57:50 +0000
Subject: [keycloak-user] 2 issue with docker images
Message-ID: <56CDB6DE.4040703@gmail.com>

I think I've encountered 2 problems with the docker images.

1. the docs state that logging can be configured using the 
KEYCLOAK_LOGLEVEL environment variable, but this does not seem to work, 
and on looking into this it looks like the correct section is not being 
copied into the standalone.xml file. The XSL here looks wrong?
https://github.com/jboss-dockerfiles/keycloak/blob/master/server/setLogLevel.xsl

2. The docs for the jboss/keycloak-postgres images state that the 
default postgres password that's used is 'keycloak', but in fact the 
default that is copied into standalone.xml is 'password'.
https://github.com/jboss-dockerfiles/keycloak/blob/master/server-postgres/changeDatabase.xsl#L15

Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/d2f33a27/attachment.html 

From thomas.darimont at googlemail.com  Wed Feb 24 09:00:28 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 24 Feb 2016 15:00:28 +0100
Subject: [keycloak-user] 2 issue with docker images
In-Reply-To: <56CDB6DE.4040703@gmail.com>
References: <56CDB6DE.4040703@gmail.com>
Message-ID: <CAK-7U1h=LzN1RQutFgkSBw0o=dD4uw3TN0HSqG3uQ-RPR7fO2w@mail.gmail.com>

I wonder why the configuration is updated via xslt since it is quite
brittle - I thought the "modern"
way to customize wildfly deployments is via the CLI in combination with
embed-server http://wildfly.org/news/2015/03/13/Offline-CLI/

Cheers,
Thomas

2016-02-24 14:57 GMT+01:00 Tim Dudgeon <tdudgeon.ml at gmail.com>:

> I think I've encountered 2 problems with the docker images.
>
> 1. the docs state that logging can be configured using the
> KEYCLOAK_LOGLEVEL environment variable, but this does not seem to work, and
> on looking into this it looks like the correct section is not being copied
> into the standalone.xml file. The XSL here looks wrong?
>
> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/setLogLevel.xsl
>
> 2. The docs for the jboss/keycloak-postgres images state that the default
> postgres password that's used is 'keycloak', but in fact the default that
> is copied into standalone.xml is 'password'.
>
> https://github.com/jboss-dockerfiles/keycloak/blob/master/server-postgres/changeDatabase.xsl#L15
>
> Tim
>
> _______________________________________________
> 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/20160224/80a93d4a/attachment-0001.html 

From battery4cid at gmail.com  Wed Feb 24 09:52:42 2016
From: battery4cid at gmail.com (Bruce Shaw)
Date: Wed, 24 Feb 2016 09:52:42 -0500
Subject: [keycloak-user] Confidential RESTful client
In-Reply-To: <CAJgngAfdBxbMcWkpPW2-6teUJZqo9pk=TsBpJitd2zRKVwHVFA@mail.gmail.com>
References: <CAFYKa1m677d+5V_GWjicJLPxFy71OmLhJ4YOsmR+VtaiF-nvdw@mail.gmail.com>
	<CAJgngAfdBxbMcWkpPW2-6teUJZqo9pk=TsBpJitd2zRKVwHVFA@mail.gmail.com>
Message-ID: <CAFYKa1=J4nagJNL-+N54D=DyH8ae1--mGq93Ft+BDexQ5R1c+Q@mail.gmail.com>

Thanks for the follow up. I understand how having my custom javascript post
to our server doesn't buy us anything.  I'm more curious what you think
about pointing the redirect_url to an api on our server that would take in
the Authorization Code and make the backchannel call for the access token
with the Client credentials.  Does that seem reasonable or does this seem
like overkill?

thanks

On Tue, Feb 23, 2016 at 1:11 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> As long as you use HTTPS and make sure you set redirect uris correctly
> it's secure. The authorization code has a short lifespan so there's very
> low chance that someone could retrieve it from the browser history. Further
> the redirect uris prevent other applications from sniffing it.
>
> I don't see how what you are proposing would be any more secure. You still
> have to transfer the token to the HTML5 application. So you've used moved
> the problem from the interaction between Keycloak to a custom
> implementation on your end.
>
> On 19 February 2016 at 23:18, Bruce Shaw <battery4cid at gmail.com> wrote:
>
>> I have a AngularJs single page web-app that makes RESTful API calls to
>> get secured data from our server (Play Framework).  I originally set it up
>> to be a public client using the keycloak.js adapter but I?m wondering if
>> there?s a more secure way.
>>
>> Instead of having the redirect response (with the authorization code)
>> come back to the keycloak.js followed by the request to get the access
>> token, wouldn?t it be more secure to have the javascript post the returned
>> authorization code to our server or just set the redirect url to an
>> endpoint on our server to make the backchannel request (with client secret
>> and id) for the access token?  Then we can redirect the user to the
>> appropriate location with the access token in the response?
>>
>> I guess I?m trying to make my RESTful api a confidential client, any
>> input or direction would help.
>>
>> thanks.
>>
>>
>>
>> _______________________________________________
>> 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/20160224/c7393390/attachment.html 

From bburke at redhat.com  Wed Feb 24 11:22:58 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 24 Feb 2016 11:22:58 -0500
Subject: [keycloak-user] Accurate description of Keycloak's capabilities?
In-Reply-To: <CAH2S7UAacB-wYAC+Dx_g9df2WBeGi=w2uAuiuOsuX7-5KqbbAQ@mail.gmail.com>
References: <CAH2S7UAacB-wYAC+Dx_g9df2WBeGi=w2uAuiuOsuX7-5KqbbAQ@mail.gmail.com>
Message-ID: <56CDD8E2.1000500@redhat.com>

Much more:
- IDP brokering (Keycloak can be a child IDP to a parent IDP)
- reset credentials
- registration (with or without recaptcha)
- required actions (verify email, update credentials, update profile)
- User session management

Custom SPIs to create/augment:
- browser login flow
- reset credential flow
- registration
- REST validation
- service accounts

With this SPI you can add custom authentication types, perform workflow 
actions, etc...

User self-help:
- Account management for logged in users.

Internationalization/Localization:
- Basically all UIs (admin console, login,

On 2/24/2016 8:20 AM, Marc Boorshtein wrote:
> All,
>
> I'm going to be presenting OpenUnison at an OpenShift briefing 
> tomorrow and have been asked to include a slide on how OpenUnison and 
> Keycloak relate to each other.  Based on getting Keycloak running and 
> looking at the website and following the list I'm planning on breaking 
> down KC's features as such:
>
> Authentication
> * OIDC
> * SAML2
> * Social
> * TOTP
> * IdP "Proxy" for both SAML2 and OIDC
>
> User Data Sources
> * LDAP
> * AD
> * Custom
>
> Role Management
> * Local database
> * Mapped to external data source
>
> Application Integration
> * SAML2
> * OIDC/OAuth2
> * Reverse Proxy with header injection
>
> UI Pages
> * Themed
>
> I want to make sure this is accurate, so I'd appreciate any feedback 
> that you have.
>
> Thanks
>
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein at tremolosecurity.com 
> <mailto:marc.boorshtein at tremolosecurity.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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/02d3a310/attachment.html 

From Edgar at info.nl  Wed Feb 24 11:59:37 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Wed, 24 Feb 2016 16:59:37 +0000
Subject: [keycloak-user] Our (customised version of) Keycloak 1.9.0.Final
	fails to start up
Message-ID: <6909F7E1-9B50-4026-970A-C3BF0219B955@info.nl>

hi,

Starting from 1.9.0.Final (it was working ok in 1.9.0.RC1) our Keycloak Docker image no longer starts up. We get the following exception. We have made a number of customisations so I am guessing the issue is somewhere there. Maybe someone already has an idea where to look from this stack trace? We based our Docker image on https://hub.docker.com/r/jboss/keycloak/ but customised it quite a bit.

cheers

Edgar

16:49:50,851 INFO  [org.keycloak.services] (ServerService Thread Pool -- 46) KC-SERVICES0050: Initializing master realm
16:49:52,621 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 46) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./auth: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: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: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
	at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162)
	at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
	at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
	at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
	at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
	at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
	at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
	... 6 more
Caused by: java.lang.NullPointerException
	at org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.lazyInit(InfinispanCacheUserProviderFactory.java:58)
	at org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:50)
	at org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:38)
	at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:101)
	at org.keycloak.services.DefaultKeycloakSession.getUserProvider(DefaultKeycloakSession.java:64)
	at org.keycloak.services.DefaultKeycloakSession.userStorage(DefaultKeycloakSession.java:90)
	at org.keycloak.models.UserFederationManager.getUsersCount(UserFederationManager.java:286)
	at org.keycloak.services.managers.ApplianceBootstrap.isNoMasterUser(ApplianceBootstrap.java:50)
	at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:134)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
	at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
	... 19 more

16:49:52,628 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: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
    Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
    Caused by: java.lang.NullPointerException"}}



From marc.boorshtein at tremolosecurity.com  Wed Feb 24 12:22:50 2016
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Wed, 24 Feb 2016 12:22:50 -0500
Subject: [keycloak-user] Accurate description of Keycloak's capabilities?
In-Reply-To: <56CDD8E2.1000500@redhat.com>
References: <CAH2S7UAacB-wYAC+Dx_g9df2WBeGi=w2uAuiuOsuX7-5KqbbAQ@mail.gmail.com>
	<56CDD8E2.1000500@redhat.com>
Message-ID: <CAH2S7UDAMK4sKOaVnH2Q095cqfqFn24uF5Vg=sU=H-FsKKhfuw@mail.gmail.com>

Thanks Bill.  I'm envisioning a slide with 3 columns (one for OpenUnison,
one for KC and one where there's overlap) so I'm going to try and keep it
brief but will certainly talk to anything I don't write down.

Here's what I'm thinking for each column including your comments:

OpenUnison
Authentication
* Kerberos
* Certificate
* Banner
* Username Only
* OTP over SMS
* OTP over Email
* Symantec VIP
* JIT Provisioning
* Authentication Levels

User Data Sources
* Integrated Virtual Directory

Role Management
* Workflow based approvals
* Multi stage approvals
* Escalations

Application Integration
* Reverse Proxy with LastMile (J2EE/Apache/.NET)
* Reverse Proxy with SAML Login
* Reverse Proxy with Kerberos Constrained Delegation

UI Pages
* Generic JSP


Common
Authentication
* OIDC
* SAML2
* Social
* TOTP
* IdP "Broker" for both SAML2 and OIDC
* Login Chain / Flow
* Custom Interface

User Data Stores
* LDAP
* DB
* AD
* Custom
* Password reset
* Profile Updates

Role Management
* Map to multiple data sources
* Web services integration

Application Integration
* SAML2
* OIDC/OAuth2
* Reverse Proxy with header injection


KeyCloak
Authentication
* OIDC
* Social
* TOTP
* User session management

User Data Sources
* Integrated SPI

Role Management
* Local database
* Mapped to external data source

Application Integration
* OIDC/OAuth2
* REST Web Services


UI Pages
* Themed
* Internationalization/Localization

Anything you would like changed or mentioned?

Thanks


Marc Boorshtein
CTO Tremolo Security
marc.boorshtein at tremolosecurity.com
<marc.boorshtein at tremolosecurity.com>(
<https://www.google.com/voice?utm_source=en-ha-na-us-bk&utm_medium=ha&utm_term=google+voice&utm_campaign=en&pli=1#phones>703)
828-4902

On Wed, Feb 24, 2016 at 11:22 AM, Bill Burke <bburke at redhat.com> wrote:

> Much more:
> - IDP brokering (Keycloak can be a child IDP to a parent IDP)
> - reset credentials
> - registration (with or without recaptcha)
> - required actions (verify email, update credentials, update profile)
> - User session management
>
> Custom SPIs to create/augment:
> - browser login flow
> - reset credential flow
> - registration
> - REST validation
> - service accounts
>
> With this SPI you can add custom authentication types, perform workflow
> actions, etc...
>
> User self-help:
> - Account management for logged in users.
>
> Internationalization/Localization:
> - Basically all UIs (admin console, login,
>
> On 2/24/2016 8:20 AM, Marc Boorshtein wrote:
>
> All,
>
> I'm going to be presenting OpenUnison at an OpenShift briefing tomorrow
> and have been asked to include a slide on how OpenUnison and Keycloak
> relate to each other.  Based on getting Keycloak running and looking at the
> website and following the list I'm planning on breaking down KC's features
> as such:
>
> Authentication
> * OIDC
> * SAML2
> * Social
> * TOTP
> * IdP "Proxy" for both SAML2 and OIDC
>
> User Data Sources
> * LDAP
> * AD
> * Custom
>
> Role Management
> * Local database
> * Mapped to external data source
>
> Application Integration
> * SAML2
> * OIDC/OAuth2
> * Reverse Proxy with header injection
>
> UI Pages
> * Themed
>
> I want to make sure this is accurate, so I'd appreciate any feedback that
> you have.
>
> Thanks
>
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein at tremolosecurity.com
>
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160224/3b0287cf/attachment-0001.html 

From marc.boorshtein at tremolosecurity.com  Wed Feb 24 12:56:39 2016
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Wed, 24 Feb 2016 12:56:39 -0500
Subject: [keycloak-user] Accurate description of Keycloak's capabilities?
In-Reply-To: <CAH2S7UDAMK4sKOaVnH2Q095cqfqFn24uF5Vg=sU=H-FsKKhfuw@mail.gmail.com>
References: <CAH2S7UAacB-wYAC+Dx_g9df2WBeGi=w2uAuiuOsuX7-5KqbbAQ@mail.gmail.com>
	<56CDD8E2.1000500@redhat.com>
	<CAH2S7UDAMK4sKOaVnH2Q095cqfqFn24uF5Vg=sU=H-FsKKhfuw@mail.gmail.com>
Message-ID: <CAH2S7UCYdE_n15S0KWAR1ePgh5AK+_n-dYNCd6s3-EBghr_Uwg@mail.gmail.com>

So after I actually put the slide together I realized I'd never be able to
put this much information on one slide.  So I tried to distill it down to
really key points:

https://s3.amazonaws.com/ts-public-downloads/random/Slide11.png

Let me know what you think.  Again, I appreciate the feedback.

Thanks

Marc Boorshtein
CTO Tremolo Security
marc.boorshtein at tremolosecurity.com
<marc.boorshtein at tremolosecurity.com>(
<https://www.google.com/voice?utm_source=en-ha-na-us-bk&utm_medium=ha&utm_term=google+voice&utm_campaign=en&pli=1#phones>703)
828-4902

On Wed, Feb 24, 2016 at 12:22 PM, Marc Boorshtein <
marc.boorshtein at tremolosecurity.com> wrote:

> Thanks Bill.  I'm envisioning a slide with 3 columns (one for OpenUnison,
> one for KC and one where there's overlap) so I'm going to try and keep it
> brief but will certainly talk to anything I don't write down.
>
> Here's what I'm thinking for each column including your comments:
>
> OpenUnison
> Authentication
> * Kerberos
> * Certificate
> * Banner
> * Username Only
> * OTP over SMS
> * OTP over Email
> * Symantec VIP
> * JIT Provisioning
> * Authentication Levels
>
> User Data Sources
> * Integrated Virtual Directory
>
> Role Management
> * Workflow based approvals
> * Multi stage approvals
> * Escalations
>
> Application Integration
> * Reverse Proxy with LastMile (J2EE/Apache/.NET)
> * Reverse Proxy with SAML Login
> * Reverse Proxy with Kerberos Constrained Delegation
>
> UI Pages
> * Generic JSP
>
>
> Common
> Authentication
> * OIDC
> * SAML2
> * Social
> * TOTP
> * IdP "Broker" for both SAML2 and OIDC
> * Login Chain / Flow
> * Custom Interface
>
> User Data Stores
> * LDAP
> * DB
> * AD
> * Custom
> * Password reset
> * Profile Updates
>
> Role Management
> * Map to multiple data sources
> * Web services integration
>
> Application Integration
> * SAML2
> * OIDC/OAuth2
> * Reverse Proxy with header injection
>
>
> KeyCloak
> Authentication
> * OIDC
> * Social
> * TOTP
> * User session management
>
> User Data Sources
> * Integrated SPI
>
> Role Management
> * Local database
> * Mapped to external data source
>
> Application Integration
> * OIDC/OAuth2
> * REST Web Services
>
>
> UI Pages
> * Themed
> * Internationalization/Localization
>
> Anything you would like changed or mentioned?
>
> Thanks
>
>
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein at tremolosecurity.com
> <marc.boorshtein at tremolosecurity.com>(
> <https://www.google.com/voice?utm_source=en-ha-na-us-bk&utm_medium=ha&utm_term=google+voice&utm_campaign=en&pli=1#phones>703)
> 828-4902
>
> On Wed, Feb 24, 2016 at 11:22 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> Much more:
>> - IDP brokering (Keycloak can be a child IDP to a parent IDP)
>> - reset credentials
>> - registration (with or without recaptcha)
>> - required actions (verify email, update credentials, update profile)
>> - User session management
>>
>> Custom SPIs to create/augment:
>> - browser login flow
>> - reset credential flow
>> - registration
>> - REST validation
>> - service accounts
>>
>> With this SPI you can add custom authentication types, perform workflow
>> actions, etc...
>>
>> User self-help:
>> - Account management for logged in users.
>>
>> Internationalization/Localization:
>> - Basically all UIs (admin console, login,
>>
>> On 2/24/2016 8:20 AM, Marc Boorshtein wrote:
>>
>> All,
>>
>> I'm going to be presenting OpenUnison at an OpenShift briefing tomorrow
>> and have been asked to include a slide on how OpenUnison and Keycloak
>> relate to each other.  Based on getting Keycloak running and looking at the
>> website and following the list I'm planning on breaking down KC's features
>> as such:
>>
>> Authentication
>> * OIDC
>> * SAML2
>> * Social
>> * TOTP
>> * IdP "Proxy" for both SAML2 and OIDC
>>
>> User Data Sources
>> * LDAP
>> * AD
>> * Custom
>>
>> Role Management
>> * Local database
>> * Mapped to external data source
>>
>> Application Integration
>> * SAML2
>> * OIDC/OAuth2
>> * Reverse Proxy with header injection
>>
>> UI Pages
>> * Themed
>>
>> I want to make sure this is accurate, so I'd appreciate any feedback that
>> you have.
>>
>> Thanks
>>
>> Marc Boorshtein
>> CTO Tremolo Security
>> marc.boorshtein at tremolosecurity.com
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://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/20160224/50af5dc0/attachment.html 

From sthorger at redhat.com  Wed Feb 24 13:46:57 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Feb 2016 19:46:57 +0100
Subject: [keycloak-user] Our (customised version of) Keycloak
 1.9.0.Final fails to start up
In-Reply-To: <6909F7E1-9B50-4026-970A-C3BF0219B955@info.nl>
References: <6909F7E1-9B50-4026-970A-C3BF0219B955@info.nl>
Message-ID: <CAJgngAdmjZcm0SGtmsezV9ygyAzFRFFoswp66_GVAJPJrR+46A@mail.gmail.com>

Well,
https://github.com/keycloak/keycloak/blob/1.9.0.Final/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/InfinispanCacheUserProviderFactory.java#L58
would be a start.

My guess is that session.getProvider(InfinispanConnectionProvider.class) is
returning null for some reason. When you say you've done customizations
you've not described what you've done.

On 24 February 2016 at 17:59, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:

> hi,
>
> Starting from 1.9.0.Final (it was working ok in 1.9.0.RC1) our Keycloak
> Docker image no longer starts up. We get the following exception. We have
> made a number of customisations so I am guessing the issue is somewhere
> there. Maybe someone already has an idea where to look from this stack
> trace? We based our Docker image on
> https://hub.docker.com/r/jboss/keycloak/ but customised it quite a bit.
>
> cheers
>
> Edgar
>
> 16:49:50,851 INFO  [org.keycloak.services] (ServerService Thread Pool --
> 46) KC-SERVICES0050: Initializing master realm
> 16:49:52,621 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool
> -- 46) MSC000001: Failed to start service
> jboss.undertow.deployment.default-server.default-host./auth:
> org.jboss.msc.service.StartException in service
> jboss.undertow.deployment.default-server.default-host./auth:
> java.lang.RuntimeException: RESTEASY003325: Failed to construct public
> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>         at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
>         at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: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: RESTEASY003325: Failed to construct
> public
> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>         at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162)
>         at
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>         at
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>         at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>         at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>         at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>         at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>         at
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>         at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>         at
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>         at
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>         at
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>         at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>         at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>         ... 6 more
> Caused by: java.lang.NullPointerException
>         at
> org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.lazyInit(InfinispanCacheUserProviderFactory.java:58)
>         at
> org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:50)
>         at
> org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:38)
>         at
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:101)
>         at
> org.keycloak.services.DefaultKeycloakSession.getUserProvider(DefaultKeycloakSession.java:64)
>         at
> org.keycloak.services.DefaultKeycloakSession.userStorage(DefaultKeycloakSession.java:90)
>         at
> org.keycloak.models.UserFederationManager.getUsersCount(UserFederationManager.java:286)
>         at
> org.keycloak.services.managers.ApplianceBootstrap.isNoMasterUser(ApplianceBootstrap.java:50)
>         at
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:134)
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>         at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>         at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>         at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>         ... 19 more
>
> 16:49:52,628 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: RESTEASY003325: Failed to construct public
> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>     Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to
> construct public
> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>     Caused by: java.lang.NullPointerException"}}
>
>
> _______________________________________________
> 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/20160224/cfc3702c/attachment-0001.html 

From prabhalar at yahoo.com  Wed Feb 24 13:47:48 2016
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Wed, 24 Feb 2016 13:47:48 -0500
Subject: [keycloak-user] Accurate description of Keycloak's capabilities?
In-Reply-To: <CAH2S7UCYdE_n15S0KWAR1ePgh5AK+_n-dYNCd6s3-EBghr_Uwg@mail.gmail.com>
References: <CAH2S7UAacB-wYAC+Dx_g9df2WBeGi=w2uAuiuOsuX7-5KqbbAQ@mail.gmail.com>
	<56CDD8E2.1000500@redhat.com>
	<CAH2S7UDAMK4sKOaVnH2Q095cqfqFn24uF5Vg=sU=H-FsKKhfuw@mail.gmail.com>
	<CAH2S7UCYdE_n15S0KWAR1ePgh5AK+_n-dYNCd6s3-EBghr_Uwg@mail.gmail.com>
Message-ID: <036B7353-F8CC-42C6-B90A-FC7AF2BF0B48@yahoo.com>

Under Keycloak authentication, I would suggest Kerberos, ldap, otp, certificates etc rather than oidc, saml which are not authentication mechanism. 

It should be similar to what you have put under openunison authentication 

Sent from my iPhone

> On Feb 24, 2016, at 12:56 PM, Marc Boorshtein <marc.boorshtein at tremolosecurity.com> wrote:
> 
> So after I actually put the slide together I realized I'd never be able to put this much information on one slide.  So I tried to distill it down to really key points:
> 
> https://s3.amazonaws.com/ts-public-downloads/random/Slide11.png
> 
> Let me know what you think.  Again, I appreciate the feedback.
> 
> Thanks
> 
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein at tremolosecurity.com
> (703) 828-4902
> 
>> On Wed, Feb 24, 2016 at 12:22 PM, Marc Boorshtein <marc.boorshtein at tremolosecurity.com> wrote:
>> Thanks Bill.  I'm envisioning a slide with 3 columns (one for OpenUnison, one for KC and one where there's overlap) so I'm going to try and keep it brief but will certainly talk to anything I don't write down.
>> 
>> Here's what I'm thinking for each column including your comments:
>> 
>> OpenUnison
>> Authentication
>> * Kerberos
>> * Certificate
>> * Banner
>> * Username Only
>> * OTP over SMS
>> * OTP over Email
>> * Symantec VIP
>> * JIT Provisioning
>> * Authentication Levels
>> 
>> User Data Sources
>> * Integrated Virtual Directory
>> 
>> Role Management
>> * Workflow based approvals
>> * Multi stage approvals
>> * Escalations
>> 
>> Application Integration
>> * Reverse Proxy with LastMile (J2EE/Apache/.NET)
>> * Reverse Proxy with SAML Login
>> * Reverse Proxy with Kerberos Constrained Delegation
>> 
>> UI Pages
>> * Generic JSP
>> 
>> 
>> Common
>> Authentication
>> * OIDC
>> * SAML2
>> * Social
>> * TOTP
>> * IdP "Broker" for both SAML2 and OIDC
>> * Login Chain / Flow
>> * Custom Interface
>> 
>> User Data Stores
>> * LDAP
>> * DB
>> * AD
>> * Custom
>> * Password reset
>> * Profile Updates
>> 
>> Role Management
>> * Map to multiple data sources
>> * Web services integration
>> 
>> Application Integration
>> * SAML2
>> * OIDC/OAuth2
>> * Reverse Proxy with header injection
>> 
>> 
>> KeyCloak
>> Authentication
>> * OIDC
>> * Social
>> * TOTP
>> * User session management
>> 
>> User Data Sources
>> * Integrated SPI
>> 
>> Role Management
>> * Local database
>> * Mapped to external data source
>> 
>> Application Integration
>> * OIDC/OAuth2
>> * REST Web Services
>> 
>> 
>> UI Pages
>> * Themed
>> * Internationalization/Localization
>> 
>> Anything you would like changed or mentioned?
>> 
>> Thanks
>> 
>> 
>> Marc Boorshtein
>> CTO Tremolo Security
>> marc.boorshtein at tremolosecurity.com
>> (703) 828-4902
>> 
>>> On Wed, Feb 24, 2016 at 11:22 AM, Bill Burke <bburke at redhat.com> wrote:
>>> Much more:
>>> - IDP brokering (Keycloak can be a child IDP to a parent IDP)
>>> - reset credentials
>>> - registration (with or without recaptcha)
>>> - required actions (verify email, update credentials, update profile)
>>> - User session management
>>> 
>>> Custom SPIs to create/augment:
>>> - browser login flow
>>> - reset credential flow
>>> - registration
>>> - REST validation
>>> - service accounts
>>> 
>>> With this SPI you can add custom authentication types, perform workflow actions, etc...
>>> 
>>> User self-help:
>>> - Account management for logged in users.
>>> 
>>> Internationalization/Localization:
>>> - Basically all UIs (admin console, login, 
>>> 
>>>> On 2/24/2016 8:20 AM, Marc Boorshtein wrote:
>>>> All,
>>>> 
>>>> I'm going to be presenting OpenUnison at an OpenShift briefing tomorrow and have been asked to include a slide on how OpenUnison and Keycloak relate to each other.  Based on getting Keycloak running and looking at the website and following the list I'm planning on breaking down KC's features as such:
>>>> 
>>>> Authentication
>>>> * OIDC
>>>> * SAML2
>>>> * Social
>>>> * TOTP
>>>> * IdP "Proxy" for both SAML2 and OIDC
>>>> 
>>>> User Data Sources
>>>> * LDAP
>>>> * AD
>>>> * Custom
>>>> 
>>>> Role Management
>>>> * Local database
>>>> * Mapped to external data source
>>>> 
>>>> Application Integration
>>>> * SAML2
>>>> * OIDC/OAuth2
>>>> * Reverse Proxy with header injection
>>>> 
>>>> UI Pages
>>>> * Themed
>>>> 
>>>> I want to make sure this is accurate, so I'd appreciate any feedback that you have.
>>>> 
>>>> Thanks
>>>> 
>>>> Marc Boorshtein
>>>> CTO Tremolo Security
>>>> marc.boorshtein at tremolosecurity.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
>>> 
>>> _______________________________________________
>>> 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/20160224/885b78a9/attachment.html 

From sthorger at redhat.com  Wed Feb 24 13:49:54 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Feb 2016 19:49:54 +0100
Subject: [keycloak-user] 2 issue with docker images
In-Reply-To: <CAK-7U1h=LzN1RQutFgkSBw0o=dD4uw3TN0HSqG3uQ-RPR7fO2w@mail.gmail.com>
References: <56CDB6DE.4040703@gmail.com>
	<CAK-7U1h=LzN1RQutFgkSBw0o=dD4uw3TN0HSqG3uQ-RPR7fO2w@mail.gmail.com>
Message-ID: <CAJgngAcbKFej5RumJ4h9yya0X2nHdGNjj7LXFiDC7kmXh2qEcQ@mail.gmail.com>

The xslt stuff pre-dates the embed-server. If anyone wants to send a PR for
it I'm more than happy to merge.

Same goes for password.

On 24 February 2016 at 15:00, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> I wonder why the configuration is updated via xslt since it is quite
> brittle - I thought the "modern"
> way to customize wildfly deployments is via the CLI in combination with
> embed-server http://wildfly.org/news/2015/03/13/Offline-CLI/
>
> Cheers,
> Thomas
>
> 2016-02-24 14:57 GMT+01:00 Tim Dudgeon <tdudgeon.ml at gmail.com>:
>
>> I think I've encountered 2 problems with the docker images.
>>
>> 1. the docs state that logging can be configured using the
>> KEYCLOAK_LOGLEVEL environment variable, but this does not seem to work, and
>> on looking into this it looks like the correct section is not being copied
>> into the standalone.xml file. The XSL here looks wrong?
>>
>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server/setLogLevel.xsl
>>
>> 2. The docs for the jboss/keycloak-postgres images state that the default
>> postgres password that's used is 'keycloak', but in fact the default that
>> is copied into standalone.xml is 'password'.
>>
>> https://github.com/jboss-dockerfiles/keycloak/blob/master/server-postgres/changeDatabase.xsl#L15
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/ea2cbd4e/attachment.html 

From sthorger at redhat.com  Wed Feb 24 13:53:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Feb 2016 19:53:12 +0100
Subject: [keycloak-user] Confidential RESTful client
In-Reply-To: <CAFYKa1=J4nagJNL-+N54D=DyH8ae1--mGq93Ft+BDexQ5R1c+Q@mail.gmail.com>
References: <CAFYKa1m677d+5V_GWjicJLPxFy71OmLhJ4YOsmR+VtaiF-nvdw@mail.gmail.com>
	<CAJgngAfdBxbMcWkpPW2-6teUJZqo9pk=TsBpJitd2zRKVwHVFA@mail.gmail.com>
	<CAFYKa1=J4nagJNL-+N54D=DyH8ae1--mGq93Ft+BDexQ5R1c+Q@mail.gmail.com>
Message-ID: <CAJgngAcPCy2VF=bRco4e_jfuUaw=DHKW3dM3Pmh6Gqq6KbEzCg@mail.gmail.com>

How would you transfer the token to your Angular app? In that case you also
need to transfer the refresh token, which is more important to keep safe.

I'd say that there's a fairly good chance that you'd end up doing something
less safe by doing something custom. Clever people have designed OpenID
Connect flows and the vulnerabilities are well understood and can be
mitigated.

If you are worried have a read up on OpenID Connect and also read the
vulnerabilities docs they have.

On 24 February 2016 at 15:52, Bruce Shaw <battery4cid at gmail.com> wrote:

> Thanks for the follow up. I understand how having my custom javascript
> post to our server doesn't buy us anything.  I'm more curious what you
> think about pointing the redirect_url to an api on our server that would
> take in the Authorization Code and make the backchannel call for the access
> token with the Client credentials.  Does that seem reasonable or does this
> seem like overkill?
>
> thanks
>
> On Tue, Feb 23, 2016 at 1:11 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> As long as you use HTTPS and make sure you set redirect uris correctly
>> it's secure. The authorization code has a short lifespan so there's very
>> low chance that someone could retrieve it from the browser history. Further
>> the redirect uris prevent other applications from sniffing it.
>>
>> I don't see how what you are proposing would be any more secure. You
>> still have to transfer the token to the HTML5 application. So you've used
>> moved the problem from the interaction between Keycloak to a custom
>> implementation on your end.
>>
>> On 19 February 2016 at 23:18, Bruce Shaw <battery4cid at gmail.com> wrote:
>>
>>> I have a AngularJs single page web-app that makes RESTful API calls to
>>> get secured data from our server (Play Framework).  I originally set it up
>>> to be a public client using the keycloak.js adapter but I?m wondering if
>>> there?s a more secure way.
>>>
>>> Instead of having the redirect response (with the authorization code)
>>> come back to the keycloak.js followed by the request to get the access
>>> token, wouldn?t it be more secure to have the javascript post the returned
>>> authorization code to our server or just set the redirect url to an
>>> endpoint on our server to make the backchannel request (with client secret
>>> and id) for the access token?  Then we can redirect the user to the
>>> appropriate location with the access token in the response?
>>>
>>> I guess I?m trying to make my RESTful api a confidential client, any
>>> input or direction would help.
>>>
>>> thanks.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20160224/57cddaeb/attachment-0001.html 

From sthorger at redhat.com  Wed Feb 24 13:56:34 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 24 Feb 2016 19:56:34 +0100
Subject: [keycloak-user] 403 when loading user info
In-Reply-To: <CAG=THF0OPQVoMcRrGY8ALEn6dx1KEEO55W7g1siUabTzi=oJug@mail.gmail.com>
References: <CAG=THF0OPQVoMcRrGY8ALEn6dx1KEEO55W7g1siUabTzi=oJug@mail.gmail.com>
Message-ID: <CAJgngAeF=SoUsTuvr489aybOyyENhLpPxHyK55UTub5_UoXMqg@mail.gmail.com>

Looks like the token session isn't valid.

https://github.com/keycloak/keycloak/blob/1.7.x/services/src/main/java/org/keycloak/protocol/oidc/endpoints/UserInfoEndpoint.java#L130

On 24 February 2016 at 11:35, Adrian Matei <adrianmatei at gmail.com> wrote:

> Hi everybody,
>
> Could  you help me please with a hard nut to crack? We have the following
> situation:
> When calling the userinfo endpoint over an enterprise proxy server (js
> adapter loadUserInfo() method):
>
> https://hostname/auth/realms/realmname/protocol/openid-connect/userinfo
>
> we get 403 Forbidden with no Access-Controls headers set. Here is the
> funny part - it happens only in Chrome, Firefox and Opera. With Safari and
> IE11 it seems to be working.
>
> The stacktrace from server.log does not tell me much....:
> 11:30:31,906 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n]
> (http-/159.232.186.74:8443-6) RESTEASY000105: Failed to execute:
> org.keycloak.services.ErrorResponseException
>         at
> org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issueUserInfo(UserInfoEndpoint.java:130)
> [keycloak-services-1.7.0.Final.jar:1.7.0.Final]
>         at
> org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issueUserInfoGet(UserInfoEndpoint.java:103)
> [keycloak-services-1.7.0.Final.jar:1.7.0.Final]
>         at sun.reflect.GeneratedMethodAccessor342.invoke(Unknown Source)
> [:1.8.0_66]
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_66]
>         at java.lang.reflect.Method.invoke(Method.java:497)
> [rt.jar:1.8.0_66]
>         at
> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:158)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:106)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:153)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:561)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:543)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:128)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
>         at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
> [keycloak-services-1.7.0.Final.jar:1.7.0.Final]
>         at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> [jboss-as-web-7.5.5.Final-redhat-3.jar:7.5.5.Final-redhat-3]
>         at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
>
>
> Thanks,
> Adrian
>
>
> _______________________________________________
> 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/20160224/595a7b15/attachment.html 

From marc.boorshtein at tremolosecurity.com  Wed Feb 24 13:57:36 2016
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Wed, 24 Feb 2016 13:57:36 -0500
Subject: [keycloak-user] Accurate description of Keycloak's capabilities?
In-Reply-To: <036B7353-F8CC-42C6-B90A-FC7AF2BF0B48@yahoo.com>
References: <CAH2S7UAacB-wYAC+Dx_g9df2WBeGi=w2uAuiuOsuX7-5KqbbAQ@mail.gmail.com>
	<56CDD8E2.1000500@redhat.com>
	<CAH2S7UDAMK4sKOaVnH2Q095cqfqFn24uF5Vg=sU=H-FsKKhfuw@mail.gmail.com>
	<CAH2S7UCYdE_n15S0KWAR1ePgh5AK+_n-dYNCd6s3-EBghr_Uwg@mail.gmail.com>
	<036B7353-F8CC-42C6-B90A-FC7AF2BF0B48@yahoo.com>
Message-ID: <CAH2S7UBnu1Y49-JjnkwFQ-e-=_bu+a+JdCHwgO9GE1ybuh8Y3A@mail.gmail.com>

Thanks Ragu.  I didn't mention certificates for KC because its says "coming
soon" on the website's front page.  The slide I linked to is my current
draft (I won't be able to fit all this information onto a single slide).
In OpenUnison we separate authentication mechanisms from data source and
include federation as a form of authentication (even though strictly
speaking we don't collect credentials).  So there's no "LDAP
Authentication" in OpenUnison, there's a username & password authentication
mechanism (that can be added to a chain) that would then validate that
credential through the virtual directory.  Same thing for SAML and OIDC,
once we validate the assertion/token we link the user in the virtual
directory (or create a virtual user or run a just-in-time provisioning
workflow to create the user)

Thanks

Marc Boorshtein
CTO Tremolo Security
marc.boorshtein at tremolosecurity.com
<marc.boorshtein at tremolosecurity.com>(
<https://www.google.com/voice?utm_source=en-ha-na-us-bk&utm_medium=ha&utm_term=google+voice&utm_campaign=en&pli=1#phones>703)
828-4902

On Wed, Feb 24, 2016 at 1:47 PM, Raghu Prabhala <prabhalar at yahoo.com> wrote:

> Under Keycloak authentication, I would suggest Kerberos, ldap, otp,
> certificates etc rather than oidc, saml which are not authentication
> mechanism.
>
> It should be similar to what you have put under openunison authentication
>
> Sent from my iPhone
>
> On Feb 24, 2016, at 12:56 PM, Marc Boorshtein <
> marc.boorshtein at tremolosecurity.com> wrote:
>
> So after I actually put the slide together I realized I'd never be able to
> put this much information on one slide.  So I tried to distill it down to
> really key points:
>
> https://s3.amazonaws.com/ts-public-downloads/random/Slide11.png
>
> Let me know what you think.  Again, I appreciate the feedback.
>
> Thanks
>
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein at tremolosecurity.com
> <marc.boorshtein at tremolosecurity.com>(
> <https://www.google.com/voice?utm_source=en-ha-na-us-bk&utm_medium=ha&utm_term=google+voice&utm_campaign=en&pli=1#phones>703)
> 828-4902
>
> On Wed, Feb 24, 2016 at 12:22 PM, Marc Boorshtein <
> marc.boorshtein at tremolosecurity.com> wrote:
>
>> Thanks Bill.  I'm envisioning a slide with 3 columns (one for OpenUnison,
>> one for KC and one where there's overlap) so I'm going to try and keep it
>> brief but will certainly talk to anything I don't write down.
>>
>> Here's what I'm thinking for each column including your comments:
>>
>> OpenUnison
>> Authentication
>> * Kerberos
>> * Certificate
>> * Banner
>> * Username Only
>> * OTP over SMS
>> * OTP over Email
>> * Symantec VIP
>> * JIT Provisioning
>> * Authentication Levels
>>
>> User Data Sources
>> * Integrated Virtual Directory
>>
>> Role Management
>> * Workflow based approvals
>> * Multi stage approvals
>> * Escalations
>>
>> Application Integration
>> * Reverse Proxy with LastMile (J2EE/Apache/.NET)
>> * Reverse Proxy with SAML Login
>> * Reverse Proxy with Kerberos Constrained Delegation
>>
>> UI Pages
>> * Generic JSP
>>
>>
>> Common
>> Authentication
>> * OIDC
>> * SAML2
>> * Social
>> * TOTP
>> * IdP "Broker" for both SAML2 and OIDC
>> * Login Chain / Flow
>> * Custom Interface
>>
>> User Data Stores
>> * LDAP
>> * DB
>> * AD
>> * Custom
>> * Password reset
>> * Profile Updates
>>
>> Role Management
>> * Map to multiple data sources
>> * Web services integration
>>
>> Application Integration
>> * SAML2
>> * OIDC/OAuth2
>> * Reverse Proxy with header injection
>>
>>
>> KeyCloak
>> Authentication
>> * OIDC
>> * Social
>> * TOTP
>> * User session management
>>
>> User Data Sources
>> * Integrated SPI
>>
>> Role Management
>> * Local database
>> * Mapped to external data source
>>
>> Application Integration
>> * OIDC/OAuth2
>> * REST Web Services
>>
>>
>> UI Pages
>> * Themed
>> * Internationalization/Localization
>>
>> Anything you would like changed or mentioned?
>>
>> Thanks
>>
>>
>> Marc Boorshtein
>> CTO Tremolo Security
>> marc.boorshtein at tremolosecurity.com
>> <marc.boorshtein at tremolosecurity.com>(
>> <https://www.google.com/voice?utm_source=en-ha-na-us-bk&utm_medium=ha&utm_term=google+voice&utm_campaign=en&pli=1#phones>703)
>> 828-4902
>>
>> On Wed, Feb 24, 2016 at 11:22 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>>> Much more:
>>> - IDP brokering (Keycloak can be a child IDP to a parent IDP)
>>> - reset credentials
>>> - registration (with or without recaptcha)
>>> - required actions (verify email, update credentials, update profile)
>>> - User session management
>>>
>>> Custom SPIs to create/augment:
>>> - browser login flow
>>> - reset credential flow
>>> - registration
>>> - REST validation
>>> - service accounts
>>>
>>> With this SPI you can add custom authentication types, perform workflow
>>> actions, etc...
>>>
>>> User self-help:
>>> - Account management for logged in users.
>>>
>>> Internationalization/Localization:
>>> - Basically all UIs (admin console, login,
>>>
>>> On 2/24/2016 8:20 AM, Marc Boorshtein wrote:
>>>
>>> All,
>>>
>>> I'm going to be presenting OpenUnison at an OpenShift briefing tomorrow
>>> and have been asked to include a slide on how OpenUnison and Keycloak
>>> relate to each other.  Based on getting Keycloak running and looking at the
>>> website and following the list I'm planning on breaking down KC's features
>>> as such:
>>>
>>> Authentication
>>> * OIDC
>>> * SAML2
>>> * Social
>>> * TOTP
>>> * IdP "Proxy" for both SAML2 and OIDC
>>>
>>> User Data Sources
>>> * LDAP
>>> * AD
>>> * Custom
>>>
>>> Role Management
>>> * Local database
>>> * Mapped to external data source
>>>
>>> Application Integration
>>> * SAML2
>>> * OIDC/OAuth2
>>> * Reverse Proxy with header injection
>>>
>>> UI Pages
>>> * Themed
>>>
>>> I want to make sure this is accurate, so I'd appreciate any feedback
>>> that you have.
>>>
>>> Thanks
>>>
>>> Marc Boorshtein
>>> CTO Tremolo Security
>>> marc.boorshtein at tremolosecurity.com
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://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/20160224/03413dd0/attachment-0001.html 

From bburke at redhat.com  Wed Feb 24 14:46:37 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 24 Feb 2016 14:46:37 -0500
Subject: [keycloak-user] Our (customised version of) Keycloak
 1.9.0.Final fails to start up
In-Reply-To: <CAJgngAdmjZcm0SGtmsezV9ygyAzFRFFoswp66_GVAJPJrR+46A@mail.gmail.com>
References: <6909F7E1-9B50-4026-970A-C3BF0219B955@info.nl>
	<CAJgngAdmjZcm0SGtmsezV9ygyAzFRFFoswp66_GVAJPJrR+46A@mail.gmail.com>
Message-ID: <56CE089D.6020204@redhat.com>

Please check the distributions keycloak-server.json, it is changed. 
standalone.xml has also changed to add an additional cache.

On 2/24/2016 1:46 PM, Stian Thorgersen wrote:
> Well, 
> https://github.com/keycloak/keycloak/blob/1.9.0.Final/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/InfinispanCacheUserProviderFactory.java#L58 
> would be a start.
>
> My guess is that 
> session.getProvider(InfinispanConnectionProvider.class) is returning 
> null for some reason. When you say you've done customizations you've 
> not described what you've done.
>
> On 24 February 2016 at 17:59, Edgar Vonk - Info.nl <Edgar at info.nl 
> <mailto:Edgar at info.nl>> wrote:
>
>     hi,
>
>     Starting from 1.9.0.Final (it was working ok in 1.9.0.RC1) our
>     Keycloak Docker image no longer starts up. We get the following
>     exception. We have made a number of customisations so I am
>     guessing the issue is somewhere there. Maybe someone already has
>     an idea where to look from this stack trace? We based our Docker
>     image on https://hub.docker.com/r/jboss/keycloak/ but customised
>     it quite a bit.
>
>     cheers
>
>     Edgar
>
>     16:49:50,851 INFO  [org.keycloak.services] (ServerService Thread
>     Pool -- 46) KC-SERVICES0050: Initializing master realm
>     16:49:52,621 ERROR [org.jboss.msc.service.fail] (ServerService
>     Thread Pool -- 46) MSC000001: Failed to start service
>     jboss.undertow.deployment.default-server.default-host./auth:
>     org.jboss.msc.service.StartException in service
>     jboss.undertow.deployment.default-server.default-host./auth:
>     java.lang.RuntimeException: RESTEASY003325: Failed to construct
>     public
>     org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>             at
>     org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
>             at
>     java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>             at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>             at
>     java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: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: RESTEASY003325: Failed to
>     construct public
>     org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>             at
>     org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162)
>             at
>     org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>             at
>     org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>             at
>     org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>             at
>     org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>             at
>     org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>             at
>     io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>             at
>     org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>             at
>     io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>             at
>     io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>             at
>     io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>             at
>     io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>             at
>     org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>             at
>     org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>             ... 6 more
>     Caused by: java.lang.NullPointerException
>             at
>     org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.lazyInit(InfinispanCacheUserProviderFactory.java:58)
>             at
>     org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:50)
>             at
>     org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:38)
>             at
>     org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:101)
>             at
>     org.keycloak.services.DefaultKeycloakSession.getUserProvider(DefaultKeycloakSession.java:64)
>             at
>     org.keycloak.services.DefaultKeycloakSession.userStorage(DefaultKeycloakSession.java:90)
>             at
>     org.keycloak.models.UserFederationManager.getUsersCount(UserFederationManager.java:286)
>             at
>     org.keycloak.services.managers.ApplianceBootstrap.isNoMasterUser(ApplianceBootstrap.java:50)
>             at
>     org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:134)
>             at
>     sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>             at
>     sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>             at
>     sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>             at
>     java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>             at
>     org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>             ... 19 more
>
>     16:49:52,628 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: RESTEASY003325: Failed to construct
>     public
>     org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>         Caused by: java.lang.RuntimeException: RESTEASY003325: Failed
>     to construct public
>     org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>         Caused by: java.lang.NullPointerException"}}
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/7e43ade7/attachment.html 

From RLewis at carbonite.com  Wed Feb 24 15:33:57 2016
From: RLewis at carbonite.com (Reed Lewis)
Date: Wed, 24 Feb 2016 20:33:57 +0000
Subject: [keycloak-user] Client Mappers. Can I define mappers
	programmatically?
Message-ID: <2697F06A-E3A8-408E-B949-AC25194BFAD9@carbonite.com>

I have the need to define mappers programmatically instead of using fixed entries from user attributes.   For example, I might want the following entries in my JWT:

xxx: {d1:{[V1:123, V2:345, V3:567]},d2:{[V1:321, V2:xyz, V3:876]}}

So I might have the following values in my attributes for the user:
Xxx.d1.v1 123
Xxx.d1.v2 345
Xxx.d1.v3 567
Xxx.d2.v1 321
Xxx.d2.v2 xyz
Xxx.d2.v3 876

But I might also have xxx.d3, xxx.d4, ?.

Is there a way to have Keycloak generate a JWT with all of the entries?   Can I write a plug in that does this?


Thank you,

Reed Lewis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/c219df59/attachment.html 

From scossu at artic.edu  Wed Feb 24 15:44:31 2016
From: scossu at artic.edu (Stefano Cossu)
Date: Wed, 24 Feb 2016 14:44:31 -0600
Subject: [keycloak-user] Hybrid SSO access and custom user database
Message-ID: <20160224144431.0d8b84b2@artic.edu>

Hello,
I am currently evaluating Keycloak to resolve an SSO scenario that we
are unable to resolve with our current setup. 

We have a SAML2 environment made up of a Shibboleth SP and a
SimpleSamlPHP IdP. The IdP authenticates requests against a custom
identity database exposed via a very simple REST API. The IdP sends
usersname and password to the REST API, which either responds
with a 401 or sends a JSON object with the authenticated user's
attributes and membership information. 

So far so good, but now we need to authenticate an API client in the
system. SAML2 is not great for this, so I am looking for an alternative
SSO solution, either based on SAML or not. 

Our requirements are: 
1. The SSO system needs to be able to authenticate against the custom
REST API. This seems to be possible in Keycloak by defining a custom
federation provider. 
2. The SSO system needs to be able to authenticate both browser- and
API-based clients and let a client authenticated via API use the same
SSO token in a browser.
3. The SSO system needs to pass the identity information to the web
server (Apache) so that they are available as environment variables, in
a similar way Shibboleth does. 

I have installed and started testing Keycloak locally but I am unsure
which scenario I should look at within Keycloak to accomplish what I am
looking for. Can someone give me some directions? 

Thanks,
Stefano

-- 
Stefano Cossu
Director of Application Services, Collections

The Art Institute of Chicago
116 S. Michigan Avenue
Chicago, IL 60603

From thomas.darimont at googlemail.com  Wed Feb 24 16:31:42 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 24 Feb 2016 22:31:42 +0100
Subject: [keycloak-user] Client Mappers. Can I define mappers
	programmatically?
In-Reply-To: <2697F06A-E3A8-408E-B949-AC25194BFAD9@carbonite.com>
References: <2697F06A-E3A8-408E-B949-AC25194BFAD9@carbonite.com>
Message-ID: <CAK-7U1gJ=7H9ULu90fRTK0wEBObKL_Dzmcco-50KmVd7gL7a1g@mail.gmail.com>

Hello Reed,

yes you should be able to do that via the:
org.keycloak.protocol.ProtocolMapperSpi

You can provide your own org.keycloak.protocol.ProtocolMapper
(org.keycloak.protocol.oidc.mappers.OIDCAccessTokenMapper) to introduce
computed attributes to the access tokens.

You can find the predefined mappers in the package:
org/keycloak/protocol/oidc/mappers within the keycloak-services project.

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160224/b7eb121b/attachment.html 

From tyvain at gmail.com  Wed Feb 24 18:40:53 2016
From: tyvain at gmail.com (=?UTF-8?Q?Sylvain_Auger=2DL=C3=A9ger?=)
Date: Thu, 25 Feb 2016 10:40:53 +1100
Subject: [keycloak-user] How to build the war?
Message-ID: <CADjy33_2Nb66OTgNStX3faoL304uKYv0jvDunigD3oYC6K+=zg@mail.gmail.com>

I am trying to deploy on tomcat, following this section:
http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#tomcat-adapter

I am stuck here:
"The first thing you must do is create a META-INF/context.xml file in your
WAR package."

Q: How can I generate the war?? Or should I just DL it (and where in that
case)?

PS: Already did a git clone + mvn install (but then I don't know what to do)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/22a25945/attachment.html 

From akaya at expedia.com  Wed Feb 24 19:39:21 2016
From: akaya at expedia.com (Sarp Kaya)
Date: Thu, 25 Feb 2016 00:39:21 +0000
Subject: [keycloak-user] SSO amongst two realms
Message-ID: <D2F48A58.2D31%akaya@expedia.com>

Hi,

I want to know whether it is possible to have SSO amongst two realms. Ie User 1 logins to an app1 that auths against realm1, then user 1 tries to use app2 which auths against realm2 which should work fine as user 1 logged into realm1 before and it should SSO into app2 fine.

If this is possible then what would be the setup like?

Kind Regards,
Sarp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/f50f6717/attachment.html 

From ornot2008 at yahoo.com  Wed Feb 24 20:54:12 2016
From: ornot2008 at yahoo.com (Mai Zi)
Date: Thu, 25 Feb 2016 01:54:12 +0000 (UTC)
Subject: [keycloak-user] Is there any way to allow only session per account?
References: <1623065542.9736665.1456365252909.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1623065542.9736665.1456365252909.JavaMail.yahoo@mail.yahoo.com>

Suppose we have an angular-js  client which is controlled by keycloak server.  
Is there any way to kick the first user off  if the second user logins in with the same  account ?
or if the first has login-ed  then the second can not be allowed in again?   

In short, is it possible to only allow one session per account ?


Thanks 

From mposolda at redhat.com  Thu Feb 25 02:16:42 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 25 Feb 2016 08:16:42 +0100
Subject: [keycloak-user] Is there any way to allow only session per
 account?
In-Reply-To: <1623065542.9736665.1456365252909.JavaMail.yahoo@mail.yahoo.com>
References: <1623065542.9736665.1456365252909.JavaMail.yahoo.ref@mail.yahoo.com>
	<1623065542.9736665.1456365252909.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <56CEAA5A.1090309@redhat.com>

On 25/02/16 02:54, Mai Zi wrote:
> Suppose we have an angular-js  client which is controlled by keycloak server.
> Is there any way to kick the first user off  if the second user logins in with the same  account ?
For the usecase "kick the first user off" you can create either 
EventListener (will listen for login events and once user logins, it 
will destroy the first userSession) or custom Authenticator (which will 
be last authenticator in the executions chain and will again destroy the 
first userSession once the second authenticates)
> or if the first has login-ed  then the second can not be allowed in again?
This usecase is possible also with the Authenticator (authenticator 
won't allow login of user "john" if there is existing userSession for 
this user).

In shortcut both usecases are possible. See documentation and see 
examples in "provider" folder for how to create custom Authenticator or 
EventListener - we have examples for both.

Marek
>
> In short, is it possible to only allow one session per account ?
>
>
> Thanks
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From mposolda at redhat.com  Thu Feb 25 02:25:01 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 25 Feb 2016 08:25:01 +0100
Subject: [keycloak-user] SSO amongst two realms
In-Reply-To: <D2F48A58.2D31%akaya@expedia.com>
References: <D2F48A58.2D31%akaya@expedia.com>
Message-ID: <56CEAC4D.9090801@redhat.com>

It's possible to achieve something like this with identity provider. You 
can create identityProvider in realm2, which will authenticate against 
realm1. In that case, there will be button in login screen of realm2 
like "Login with realm1" and when user clicks on this, he will be 
logged-in automatically. There is also possibility to use switch 
"Authenticate by default" in identity provider and then login screen of 
realm2 won't be shown, but instead it will always automatically redirect 
to realm1 login screen.

The thing is, that you will end with duplicated user accounts (Account 
of user "john" will be in both realm1 and realm2). AFAIK we plan to 
improve this in the future to have this use-case more "friendly" as more 
people ask about that.

Marek

On 25/02/16 01:39, Sarp Kaya wrote:
> Hi,
>
> I want to know whether it is possible to have SSO amongst two realms. 
> Ie User 1 logins to an app1 that auths against realm1, then user 1 
> tries to use app2 which auths against realm2 which should work fine as 
> user 1 logged into realm1 before and it should SSO into app2 fine.
>
> If this is possible then what would be the setup like?
>
> Kind Regards,
> Sarp
>
>
> _______________________________________________
> 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/20160225/bfcc9b92/attachment.html 

From mposolda at redhat.com  Thu Feb 25 02:25:20 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 25 Feb 2016 08:25:20 +0100
Subject: [keycloak-user] SSO amongst two realms
In-Reply-To: <D2F48A58.2D31%akaya@expedia.com>
References: <D2F48A58.2D31%akaya@expedia.com>
Message-ID: <56CEAC60.2030105@redhat.com>

It's possible to achieve something like this with identity provider. You 
can create identityProvider in realm2, which will authenticate against 
realm1. In that case, there will be button in login screen of realm2 
like "Login with realm1" and when user clicks on this, he will be 
logged-in automatically. There is also possibility to use switch 
"Authenticate by default" in identity provider and then login screen of 
realm2 won't be shown, but instead it will always automatically redirect 
to realm1 login screen.

The thing is, that you will end with duplicated user accounts (Account 
of user "john" will be in both realm1 and realm2). AFAIK we plan to 
improve this in the future to have this use-case more "friendly" as more 
people ask about that.

Marek

On 25/02/16 01:39, Sarp Kaya wrote:
> Hi,
>
> I want to know whether it is possible to have SSO amongst two realms. 
> Ie User 1 logins to an app1 that auths against realm1, then user 1 
> tries to use app2 which auths against realm2 which should work fine as 
> user 1 logged into realm1 before and it should SSO into app2 fine.
>
> If this is possible then what would be the setup like?
>
> Kind Regards,
> Sarp
>
>
> _______________________________________________
> 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/20160225/36413622/attachment-0001.html 

From mposolda at redhat.com  Thu Feb 25 02:29:20 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 25 Feb 2016 08:29:20 +0100
Subject: [keycloak-user] How to build the war?
In-Reply-To: <CADjy33_2Nb66OTgNStX3faoL304uKYv0jvDunigD3oYC6K+=zg@mail.gmail.com>
References: <CADjy33_2Nb66OTgNStX3faoL304uKYv0jvDunigD3oYC6K+=zg@mail.gmail.com>
Message-ID: <56CEAD50.80503@redhat.com>

On 25/02/16 00:40, Sylvain Auger-L?ger wrote:
> I am trying to deploy on tomcat, following this section:
> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#tomcat-adapter
>
> I am stuck here:
> "The first thing you must do is create a |META-INF/context.xml| file 
> in your WAR package."
This means the WAR file of your application. As long as you use maven 
and you have project with declared packaging "war" in pom.xml, the WAR 
file is build automatically from your application when you do "mvn clean 
install". So just put it to src/main/webapp/META-INF/context.xml of your 
app and it should be included automatically in the WAR.

Marek
>
> Q: How can I generate the war?? Or should I just DL it (and where in 
> that case)?
>
> PS: Already did a git clone + mvn install (but then I don't know what 
> to do)
>
>
> _______________________________________________
> 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/20160225/7053311f/attachment.html 

From Edgar at info.nl  Thu Feb 25 03:31:41 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 25 Feb 2016 08:31:41 +0000
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
Message-ID: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>

Hi,

It seems that the themes folder has moved in Keycloak 1.9.0.Final (from 1.9.0.RC1)?

The themes folder used to be:
$KEYCLOAK_HOME/standalone/configuration/themes

but now it seems to be:
$KEYCLOAK_HOME/themes

The documentation still mentions the old location so I think needs to be updated?
http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431

cheers

Edgar

From Edgar at info.nl  Thu Feb 25 03:32:21 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 25 Feb 2016 08:32:21 +0000
Subject: [keycloak-user] Our (customised version of) Keycloak
 1.9.0.Final fails to start up
In-Reply-To: <56CE089D.6020204@redhat.com>
References: <6909F7E1-9B50-4026-970A-C3BF0219B955@info.nl>
	<CAJgngAdmjZcm0SGtmsezV9ygyAzFRFFoswp66_GVAJPJrR+46A@mail.gmail.com>
	<56CE089D.6020204@redhat.com>
Message-ID: <18944BF6-8B01-4963-BBEF-866712CF799D@info.nl>

Thanks Bill! Yes, the issue was indeed our version of the keycloak-server.json.

On 24 Feb 2016, at 20:46, Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>> wrote:

Please check the distributions keycloak-server.json, it is changed.  standalone.xml has also changed to add an additional cache.

On 2/24/2016 1:46 PM, Stian Thorgersen wrote:
Well, https://github.com/keycloak/keycloak/blob/1.9.0.Final/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/InfinispanCacheUserProviderFactory.java#L58 would be a start.

My guess is that session.getProvider(InfinispanConnectionProvider.class) is returning null for some reason. When you say you've done customizations you've not described what you've done.

On 24 February 2016 at 17:59, Edgar Vonk - Info.nl<http://info.nl> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:
hi,

Starting from 1.9.0.Final (it was working ok in 1.9.0.RC1) our Keycloak Docker image no longer starts up. We get the following exception. We have made a number of customisations so I am guessing the issue is somewhere there. Maybe someone already has an idea where to look from this stack trace? We based our Docker image on https://hub.docker.com/r/jboss/keycloak/ but customised it quite a bit.

cheers

Edgar

16:49:50,851 INFO  [org.keycloak.services] (ServerService Thread Pool -- 46) KC-SERVICES0050: Initializing master realm
16:49:52,621 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 46) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./auth: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: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: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
        at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162)
        at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
        at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
        at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
        at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
        at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
        at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
        at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
        at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
        at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
        at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
        ... 6 more
Caused by: java.lang.NullPointerException
        at org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.lazyInit(InfinispanCacheUserProviderFactory.java:58)
        at org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:50)
        at org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:38)
        at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:101)
        at org.keycloak.services.DefaultKeycloakSession.getUserProvider(DefaultKeycloakSession.java:64)
        at org.keycloak.services.DefaultKeycloakSession.userStorage(DefaultKeycloakSession.java:90)
        at org.keycloak.models.UserFederationManager.getUsersCount(UserFederationManager.java:286)
        at org.keycloak.services.managers.ApplianceBootstrap.isNoMasterUser(ApplianceBootstrap.java:50)
        at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:134)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
        at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
        ... 19 more

16:49:52,628 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: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
    Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
    Caused by: java.lang.NullPointerException"}}


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




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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com<http://bill.burkecentral.com/>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/cfe86ba2/attachment-0001.html 

From adrianmatei at gmail.com  Thu Feb 25 03:49:12 2016
From: adrianmatei at gmail.com (Adrian Matei)
Date: Thu, 25 Feb 2016 09:49:12 +0100
Subject: [keycloak-user] 403 when loading user info
In-Reply-To: <CAJgngAeF=SoUsTuvr489aybOyyENhLpPxHyK55UTub5_UoXMqg@mail.gmail.com>
References: <CAG=THF0OPQVoMcRrGY8ALEn6dx1KEEO55W7g1siUabTzi=oJug@mail.gmail.com>
	<CAJgngAeF=SoUsTuvr489aybOyyENhLpPxHyK55UTub5_UoXMqg@mail.gmail.com>
Message-ID: <CAG=THF3webPbhuctsgRZ6DTFUGup0BU9mWaotsnoS0TTwfXy0Q@mail.gmail.com>

Hi everyone,

The problem was that our engineering team had set up a jboss cluster via a
reverse-proxy/load-balancer server and that's why some of the token
sessions were invalid...

Best regards,
Adrian

On Wed, Feb 24, 2016 at 7:56 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Looks like the token session isn't valid.
>
>
> https://github.com/keycloak/keycloak/blob/1.7.x/services/src/main/java/org/keycloak/protocol/oidc/endpoints/UserInfoEndpoint.java#L130
>
> On 24 February 2016 at 11:35, Adrian Matei <adrianmatei at gmail.com> wrote:
>
>> Hi everybody,
>>
>> Could  you help me please with a hard nut to crack? We have the following
>> situation:
>> When calling the userinfo endpoint over an enterprise proxy server (js
>> adapter loadUserInfo() method):
>>
>> https://hostname/auth/realms/realmname/protocol/openid-connect/userinfo
>>
>> we get 403 Forbidden with no Access-Controls headers set. Here is the
>> funny part - it happens only in Chrome, Firefox and Opera. With Safari and
>> IE11 it seems to be working.
>>
>> The stacktrace from server.log does not tell me much....:
>> 11:30:31,906 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (http-/159.232.186.74:8443-6) RESTEASY000105: Failed to execute:
>> org.keycloak.services.ErrorResponseException
>>         at
>> org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issueUserInfo(UserInfoEndpoint.java:130)
>> [keycloak-services-1.7.0.Final.jar:1.7.0.Final]
>>         at
>> org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issueUserInfoGet(UserInfoEndpoint.java:103)
>> [keycloak-services-1.7.0.Final.jar:1.7.0.Final]
>>         at sun.reflect.GeneratedMethodAccessor342.invoke(Unknown Source)
>> [:1.8.0_66]
>>         at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.8.0_66]
>>         at java.lang.reflect.Method.invoke(Method.java:497)
>> [rt.jar:1.8.0_66]
>>         at
>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:158)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:106)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:153)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:561)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:543)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:128)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
>> [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>> [keycloak-services-1.7.0.Final.jar:1.7.0.Final]
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
>> [jboss-as-web-7.5.5.Final-redhat-3.jar:7.5.5.Final-redhat-3]
>>         at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
>> [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
>>
>>
>> Thanks,
>> Adrian
>>
>>
>> _______________________________________________
>> 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/20160225/ae43e5c4/attachment.html 

From Edgar at info.nl  Thu Feb 25 03:51:56 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 25 Feb 2016 08:51:56 +0000
Subject: [keycloak-user] Our (customised version of) Keycloak
 1.9.0.Final fails to start up
In-Reply-To: <18944BF6-8B01-4963-BBEF-866712CF799D@info.nl>
References: <6909F7E1-9B50-4026-970A-C3BF0219B955@info.nl>
	<CAJgngAdmjZcm0SGtmsezV9ygyAzFRFFoswp66_GVAJPJrR+46A@mail.gmail.com>
	<56CE089D.6020204@redhat.com>
	<18944BF6-8B01-4963-BBEF-866712CF799D@info.nl>
Message-ID: <44488FF8-07A8-45E5-A23E-2D7AF5804A1D@info.nl>

PS: we did have another issue with 1.9.0.Final in that Keycloak failed to upgrade its database model from 1.9.0.RC1. We solved that simply by starting again with an empty database, as we import our realm every time anyway. I guess the database upgrade path from a release candidate version is not something that is supported in any case?


08:41:42,161 INFO  [org.keycloak.services] (ServerService Thread Pool -- 46) KC-SERVICES0001: Loading config from /opt/jboss/keycloak/standalone/configuration/keycloak-server.json
08:41:45,659 ERROR [org.keycloak.services] (ServerService Thread Pool -- 46) KC-SERVICES0002: Failed to migrate datamodel: java.lang.RuntimeException: Failed to update database
at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:91)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:170)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:59)
at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:47)
at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:101)
at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:51)
at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:33)
at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:101)
at org.keycloak.models.cache.infinispan.locking.LockingCacheRealmProvider.getDelegate(LockingCacheRealmProvider.java:104)
at org.keycloak.models.cache.infinispan.locking.LockingCacheRealmProvider.getMigrationModel(LockingCacheRealmProvider.java:97)
at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:39)
at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:152)
at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:94)
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:150)
at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: liquibase.exception.ValidationFailedException: Validation Failed:
     1 change sets check sum
          META-INF/jpa-changelog-1.9.0.xml::1.9.0::mposolda at redhat.com<mailto:mposolda at redhat.com> is now: 7:ed2dc7f799d19ac452cbcda56c929e47

at liquibase.changelog.DatabaseChangeLog.validate(DatabaseChangeLog.java:206)
at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1139)
at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1126)
at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1122)
at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:67)
... 36 more


On 25 Feb 2016, at 09:32, Edgar Vonk - Info.nl<http://info.nl> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:

Thanks Bill! Yes, the issue was indeed our version of the keycloak-server.json.

On 24 Feb 2016, at 20:46, Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>> wrote:

Please check the distributions keycloak-server.json, it is changed.  standalone.xml has also changed to add an additional cache.

On 2/24/2016 1:46 PM, Stian Thorgersen wrote:
Well, https://github.com/keycloak/keycloak/blob/1.9.0.Final/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/InfinispanCacheUserProviderFactory.java#L58 would be a start.

My guess is that session.getProvider(InfinispanConnectionProvider.class) is returning null for some reason. When you say you've done customizations you've not described what you've done.

On 24 February 2016 at 17:59, Edgar Vonk - Info.nl<http://info.nl/> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:
hi,

Starting from 1.9.0.Final (it was working ok in 1.9.0.RC1) our Keycloak Docker image no longer starts up. We get the following exception. We have made a number of customisations so I am guessing the issue is somewhere there. Maybe someone already has an idea where to look from this stack trace? We based our Docker image on https://hub.docker.com/r/jboss/keycloak/ but customised it quite a bit.

cheers

Edgar

16:49:50,851 INFO  [org.keycloak.services] (ServerService Thread Pool -- 46) KC-SERVICES0050: Initializing master realm
16:49:52,621 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 46) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./auth: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: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: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
        at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162)
        at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
        at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
        at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
        at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
        at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
        at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
        at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
        at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
        at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
        at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
        at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
        ... 6 more
Caused by: java.lang.NullPointerException
        at org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.lazyInit(InfinispanCacheUserProviderFactory.java:58)
        at org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:50)
        at org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:38)
        at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:101)
        at org.keycloak.services.DefaultKeycloakSession.getUserProvider(DefaultKeycloakSession.java:64)
        at org.keycloak.services.DefaultKeycloakSession.userStorage(DefaultKeycloakSession.java:90)
        at org.keycloak.models.UserFederationManager.getUsersCount(UserFederationManager.java:286)
        at org.keycloak.services.managers.ApplianceBootstrap.isNoMasterUser(ApplianceBootstrap.java:50)
        at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:134)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
        at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
        ... 19 more

16:49:52,628 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: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
    Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
    Caused by: java.lang.NullPointerException"}}


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




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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com<http://bill.burkecentral.com/>

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/c84a0383/attachment-0001.html 

From thomas.darimont at googlemail.com  Thu Feb 25 03:55:35 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 25 Feb 2016 09:55:35 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CADjGaadXezH5kURnkP87c8g6opKnkb0Zzek3P-W2TwnV42-mng@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
	<CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
	<CAJgngAdLyk=O8DY5go+m+B6+tJzbj0wnF362FG+=HOGQPYH81A@mail.gmail.com>
	<CADjGaacaf+3tAPocJdsPno=X221UgRRd_X+yMkoH=91HLp8F8w@mail.gmail.com>
	<CAJgngAdmjMyMUSw6LG_5y_WaB+PPEsZb1WqQ3N_uMJcq3Kh-tw@mail.gmail.com>
	<CADjGaafD9p=jzOVnBEMwpvJKS7VzMYTpQD1Ujgr+Vnj5A=xpUA@mail.gmail.com>
	<CAJgngAdD6_iA_cFob0dKU+vJm84BfY8K-woUjaHJr=20gAXjSA@mail.gmail.com>
	<CAK-7U1hqdiqQjeTfCp_nUeehQdrDsPb1Qptqf+oWOPE9Ghc07g@mail.gmail.com>
	<CADjGaadXezH5kURnkP87c8g6opKnkb0Zzek3P-W2TwnV42-mng@mail.gmail.com>
Message-ID: <CAK-7U1jG6kN5zpJ9YQi154ajm0Lii4KQ5W+a0HmGjm7rPFFJcA@mail.gmail.com>

FYI, back to the original question of allowing edit of client attributes
from admin console...

Some use cases where client attributes would be very handy:
* additional metadata for applications
* display-order for application listing
* icon name in application listing (more flexible than deriving from client
id)
* tagging of clients as internal, public etc.
* application version
* url for checking application status (health check endpoint) - ok,
maintenance, offline

Would be happy to send a PR for editing of client attributes in the admin
console.

Cheers,
Thomas

2016-02-22 13:58 GMT+01:00 Bystrik Horvath <bystrik.horvath at gmail.com>:

> Thank you guys for the answers, I think you & Stian directed me to the
> right way, so it should solve my requirements.
>
> Best regards,
> Bystrik
>
>
>
> On Mon, Feb 22, 2016 at 1:48 PM, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> You could define the set of secret questions on the authenticator - you
>> could either hardcode them or make them configurable by implementing
>> ConfiguredProvider see [0].
>> Then you could store a reference to the selected secret question and the
>> answer as a custom user-attribute.
>>
>> Cheers,
>>
>> Thomas
>>
>> [0] -
>> https://github.com/keycloak/keycloak/blob/60f9f73c4ca2ddf4ad49ff53a03a63dca8148ea9/server-spi/src/main/java/org/keycloak/provider/ConfiguredProvider.java#L26
>>
>> Stian Thorgersen <sthorger at redhat.com> schrieb am Mo., 22. Feb. 2016,
>> 13:40:
>>
>>> I thought the example did allow configuring the security question on the
>>> authenticator, but you can create your own that does it. Then the security
>>> questions are configured on the authenticator itself.
>>>
>>> On 22 February 2016 at 13:24, Bystrik Horvath <bystrik.horvath at gmail.com
>>> > wrote:
>>>
>>>> Hi,
>>>>
>>>> I went through the example (
>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator).
>>>> The security questions are written in secret-question.ftl
>>>> and secret-question-config.ftl files. From my point of view, the security
>>>> questions are know in advance and they can be "hardcoded" in ftl files. My
>>>> case is that security questions are defined during the runtime (preferably
>>>> via  admin REST API). The admin REST API does not provide the functionality
>>>> to store attributes on realm level. I agree that security questions belongs
>>>> to realm, but how to provision them - *.ftl files are not an option for me.
>>>>
>>>> Best regards,
>>>> Bystrik
>>>>
>>>> On Mon, Feb 22, 2016 at 12:55 PM, Stian Thorgersen <sthorger at redhat.com
>>>> > wrote:
>>>>
>>>>> If you look at our security questions example it stores the
>>>>> configuration on the authenticator itself.
>>>>>
>>>>> On 22 February 2016 at 12:46, Bystrik Horvath <
>>>>> bystrik.horvath at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> what would be a recommended way to provision a security question on
>>>>>> realm base if the question is not known in advance? May be it is an misuse
>>>>>> of client representation for provisioning that.
>>>>>>
>>>>>> Best regards,
>>>>>> Bystrik
>>>>>>
>>>>>> On Mon, Feb 22, 2016 at 12:28 PM, Stian Thorgersen <
>>>>>> sthorger at redhat.com> wrote:
>>>>>>
>>>>>>> I don't understand how you can have security questions that are
>>>>>>> particular to a client. A user logs-in to a realm, not a client.
>>>>>>>
>>>>>>> On 22 February 2016 at 10:20, Juraj Janosik <
>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>
>>>>>>>> @ Stian:
>>>>>>>> generally said, I did not find any description, that the client
>>>>>>>> attributes are for internal use only.
>>>>>>>> Parameter "attributes" is propagated in ClientRepresentation in the
>>>>>>>> REST Admin API,
>>>>>>>> therefore should be used for CRUD admin operations.
>>>>>>>> We plan to attach Security Answers to the user (Security questions
>>>>>>>> are common for particular client).
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Juraj
>>>>>>>>
>>>>>>>> 2016-02-22 10:18 GMT+01:00 Bystrik Horvath <
>>>>>>>> bystrik.horvath at gmail.com>:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I think the case here is to provision the text of security
>>>>>>>>> question to the client attributes when it is not known in advance.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Bystrik
>>>>>>>>>
>>>>>>>>> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
>>>>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Interesting - do you need client specific security questions?
>>>>>>>>>>
>>>>>>>>>> The keycloak examples contain a custom provider for user specific
>>>>>>>>>> security questions - perhaps this would suit your needs better.
>>>>>>>>>>
>>>>>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Thomas
>>>>>>>>>>
>>>>>>>>>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <
>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> Hi Thomas,
>>>>>>>>>>>
>>>>>>>>>>> for example security questions.... :-)
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Juraj
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>>>>>>>>>> thomas.darimont at googlemail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> Hello Juraj,
>>>>>>>>>>>>
>>>>>>>>>>>> I wondered about that too a while ago - may I ask what client
>>>>>>>>>>>> attributes you are planning to store?
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Thomas
>>>>>>>>>>>>
>>>>>>>>>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <
>>>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> The user configuration has the possibility to
>>>>>>>>>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>>>>>>>>>>
>>>>>>>>>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>>>>>>>>>> The client does not. I think, the logic and the focus is the
>>>>>>>>>>>>> same for both.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <
>>>>>>>>>>>>> sthorger at redhat.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> We don't. Why would we add it though?
>>>>>>>>>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <
>>>>>>>>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> is there any plan to support for displaying of "attributes"
>>>>>>>>>>>>>>> from Client Representation
>>>>>>>>>>>>>>> (like users configuration) in Admin Console?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/6029006a/attachment.html 

From thomas.darimont at googlemail.com  Thu Feb 25 04:00:33 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 25 Feb 2016 10:00:33 +0100
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
Message-ID: <CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>

This was discussed a few days ago on the dev list:
http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html

Perhaphs there should have sent a mail to the user-list as well...

Cheers,
Thomas

2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl <Edgar at info.nl>:

> Hi,
>
> It seems that the themes folder has moved in Keycloak 1.9.0.Final (from
> 1.9.0.RC1)?
>
> The themes folder used to be:
> $KEYCLOAK_HOME/standalone/configuration/themes
>
> but now it seems to be:
> $KEYCLOAK_HOME/themes
>
> The documentation still mentions the old location so I think needs to be
> updated?
>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>
> cheers
>
> Edgar
> _______________________________________________
> 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/20160225/bb410438/attachment-0001.html 

From sthorger at redhat.com  Thu Feb 25 04:19:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Feb 2016 10:19:16 +0100
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
Message-ID: <CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>

Yes, it has moved. I forgot to update the themes doc, but it's included in
the migration guide.

Always read the migration guide before upgrading! It will quite likely save
you a lot of time.
http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997

On 25 February 2016 at 10:00, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> This was discussed a few days ago on the dev list:
> http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>
> Perhaphs there should have sent a mail to the user-list as well...
>
> Cheers,
> Thomas
>
> 2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl <Edgar at info.nl>:
>
>> Hi,
>>
>> It seems that the themes folder has moved in Keycloak 1.9.0.Final (from
>> 1.9.0.RC1)?
>>
>> The themes folder used to be:
>> $KEYCLOAK_HOME/standalone/configuration/themes
>>
>> but now it seems to be:
>> $KEYCLOAK_HOME/themes
>>
>> The documentation still mentions the old location so I think needs to be
>> updated?
>>
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>
>> cheers
>>
>> Edgar
>> _______________________________________________
>> 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/20160225/320cf49b/attachment.html 

From sthorger at redhat.com  Thu Feb 25 04:20:53 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Feb 2016 10:20:53 +0100
Subject: [keycloak-user] Our (customised version of) Keycloak
 1.9.0.Final fails to start up
In-Reply-To: <44488FF8-07A8-45E5-A23E-2D7AF5804A1D@info.nl>
References: <6909F7E1-9B50-4026-970A-C3BF0219B955@info.nl>
	<CAJgngAdmjZcm0SGtmsezV9ygyAzFRFFoswp66_GVAJPJrR+46A@mail.gmail.com>
	<56CE089D.6020204@redhat.com>
	<18944BF6-8B01-4963-BBEF-866712CF799D@info.nl>
	<44488FF8-07A8-45E5-A23E-2D7AF5804A1D@info.nl>
Message-ID: <CAJgngAcEnZ1_WANm4SrqDr=52s1hJQGbvAh6abG7dTaJ9wskHg@mail.gmail.com>

That's expected. We don't support migrating from a CR release. CR releases
are only aimed at testing, not production.

On 25 February 2016 at 09:51, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:

> PS: we did have another issue with 1.9.0.Final in that Keycloak failed to
> upgrade its database model from 1.9.0.RC1. We solved that simply by
> starting again with an empty database, as we import our realm every time
> anyway. I guess the database upgrade path from a release candidate version
> is not something that is supported in any case?
>
>
> 08:41:42,161 INFO  [org.keycloak.services] (ServerService Thread
> Pool -- 46) KC-SERVICES0001: Loading config from
> /opt/jboss/keycloak/standalone/configuration/keycloak-server.json
> 08:41:45,659 ERROR [org.keycloak.services] (ServerService Thread
> Pool -- 46) KC-SERVICES0002: Failed to migrate datamodel:
> java.lang.RuntimeException: Failed to update database
> at
> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:91)
> at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:170)
> at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:59)
> at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:47)
> at
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:101)
> at
> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:51)
> at
> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:33)
> at
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:101)
> at
> org.keycloak.models.cache.infinispan.locking.LockingCacheRealmProvider.getDelegate(LockingCacheRealmProvider.java:104)
> at
> org.keycloak.models.cache.infinispan.locking.LockingCacheRealmProvider.getMigrationModel(LockingCacheRealmProvider.java:97)
> at
> org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:39)
> at
> org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:152)
> at
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:94)
> 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:150)
> at
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
> at
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
> at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
> at
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
> at
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
> at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
> at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: liquibase.exception.ValidationFailedException: Validation
> Failed:
>      1 change sets check sum
>           META-INF/jpa-changelog-1.9.0.xml::1.9.0::mposolda at redhat.com is
> now: 7:ed2dc7f799d19ac452cbcda56c929e47
>
> at
> liquibase.changelog.DatabaseChangeLog.validate(DatabaseChangeLog.java:206)
> at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1139)
> at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1126)
> at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1122)
> at
> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:67)
> ... 36 more
>
>
> On 25 Feb 2016, at 09:32, Edgar Vonk - Info.nl <http://info.nl> <
> Edgar at info.nl> wrote:
>
> Thanks Bill! Yes, the issue was indeed our version of the
> keycloak-server.json.
>
> On 24 Feb 2016, at 20:46, Bill Burke <bburke at redhat.com> wrote:
>
> Please check the distributions keycloak-server.json, it is changed.
> standalone.xml has also changed to add an additional cache.
>
> On 2/24/2016 1:46 PM, Stian Thorgersen wrote:
>
> Well,
> https://github.com/keycloak/keycloak/blob/1.9.0.Final/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/InfinispanCacheUserProviderFactory.java#L58
> would be a start.
>
> My guess is that session.getProvider(InfinispanConnectionProvider.class) is
> returning null for some reason. When you say you've done customizations
> you've not described what you've done.
>
> On 24 February 2016 at 17:59, Edgar Vonk - Info.nl <http://info.nl/> <
> Edgar at info.nl> wrote:
>
>> hi,
>>
>> Starting from 1.9.0.Final (it was working ok in 1.9.0.RC1) our Keycloak
>> Docker image no longer starts up. We get the following exception. We have
>> made a number of customisations so I am guessing the issue is somewhere
>> there. Maybe someone already has an idea where to look from this stack
>> trace? We based our Docker image on
>> https://hub.docker.com/r/jboss/keycloak/ but customised it quite a bit.
>>
>> cheers
>>
>> Edgar
>>
>> 16:49:50,851 INFO  [org.keycloak.services] (ServerService Thread Pool --
>> 46) KC-SERVICES0050: Initializing master realm
>> 16:49:52,621 ERROR [org.jboss.msc.service.fail] (ServerService Thread
>> Pool -- 46) MSC000001: Failed to start service
>> jboss.undertow.deployment.default-server.default-host./auth:
>> org.jboss.msc.service.StartException in service
>> jboss.undertow.deployment.default-server.default-host./auth:
>> java.lang.RuntimeException: RESTEASY003325: Failed to construct public
>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>         at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
>>         at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>         at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: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: RESTEASY003325: Failed to
>> construct public
>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>         at
>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162)
>>         at
>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>>         at
>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>>         at
>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>>         at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>>         at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>>         at
>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>>         at
>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>>         at
>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>>         at
>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>>         at
>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>>         at
>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>>         at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>>         at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>>         ... 6 more
>> Caused by: java.lang.NullPointerException
>>         at
>> org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.lazyInit(InfinispanCacheUserProviderFactory.java:58)
>>         at
>> org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:50)
>>         at
>> org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory.create(InfinispanCacheUserProviderFactory.java:38)
>>         at
>> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:101)
>>         at
>> org.keycloak.services.DefaultKeycloakSession.getUserProvider(DefaultKeycloakSession.java:64)
>>         at
>> org.keycloak.services.DefaultKeycloakSession.userStorage(DefaultKeycloakSession.java:90)
>>         at
>> org.keycloak.models.UserFederationManager.getUsersCount(UserFederationManager.java:286)
>>         at
>> org.keycloak.services.managers.ApplianceBootstrap.isNoMasterUser(ApplianceBootstrap.java:50)
>>         at
>> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:134)
>>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>>         at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>>         at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>         at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>>         at
>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>>         ... 19 more
>>
>> 16:49:52,628 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: RESTEASY003325: Failed to construct public
>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>     Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to
>> construct public
>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>     Caused by: java.lang.NullPointerException"}}
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160225/a90fdafe/attachment-0001.html 

From Edgar at info.nl  Thu Feb 25 04:21:54 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 25 Feb 2016 09:21:54 +0000
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
Message-ID: <B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>

ok, thanks! you are right, I should have read the migration guide.

On 25 Feb 2016, at 10:19, Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>> wrote:

Yes, it has moved. I forgot to update the themes doc, but it's included in the migration guide.

Always read the migration guide before upgrading! It will quite likely save you a lot of time.
http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997

On 25 February 2016 at 10:00, Thomas Darimont <thomas.darimont at googlemail.com<mailto:thomas.darimont at googlemail.com>> wrote:
This was discussed a few days ago on the dev list:
http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html

Perhaphs there should have sent a mail to the user-list as well...

Cheers,
Thomas

2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl<http://info.nl> <Edgar at info.nl<mailto:Edgar at info.nl>>:
Hi,

It seems that the themes folder has moved in Keycloak 1.9.0.Final (from 1.9.0.RC1)?

The themes folder used to be:
$KEYCLOAK_HOME/standalone/configuration/themes

but now it seems to be:
$KEYCLOAK_HOME/themes

The documentation still mentions the old location so I think needs to be updated?
http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431

cheers

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


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/41aafa8e/attachment.html 

From sthorger at redhat.com  Thu Feb 25 04:23:36 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Feb 2016 10:23:36 +0100
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
Message-ID: <CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>

Any tips on how we can make it more obvious to users to read the migration
guide?

On 25 February 2016 at 10:21, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:

> ok, thanks! you are right, I should have read the migration guide.
>
> On 25 Feb 2016, at 10:19, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> Yes, it has moved. I forgot to update the themes doc, but it's included in
> the migration guide.
>
> Always read the migration guide before upgrading! It will quite likely
> save you a lot of time.
>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997
>
> On 25 February 2016 at 10:00, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> This was discussed a few days ago on the dev list:
>> http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>>
>> Perhaphs there should have sent a mail to the user-list as well...
>>
>> Cheers,
>> Thomas
>>
>> 2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl <http://info.nl> <
>> Edgar at info.nl>:
>>
>>> Hi,
>>>
>>> It seems that the themes folder has moved in Keycloak 1.9.0.Final (from
>>> 1.9.0.RC1)?
>>>
>>> The themes folder used to be:
>>> $KEYCLOAK_HOME/standalone/configuration/themes
>>>
>>> but now it seems to be:
>>> $KEYCLOAK_HOME/themes
>>>
>>> The documentation still mentions the old location so I think needs to be
>>> updated?
>>>
>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>>
>>> cheers
>>>
>>> Edgar
>>> _______________________________________________
>>> 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/20160225/ca3815f9/attachment.html 

From bruno at abstractj.org  Thu Feb 25 04:25:55 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 25 Feb 2016 09:25:55 +0000
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
	<CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
Message-ID: <CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>

I will review the whole theme chapter today and see if I find any
mismatches.

Regarding your question, I'd add a section in the very beginning of our
guide called "Before you get started".

On Thu, Feb 25, 2016 at 6:23 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Any tips on how we can make it more obvious to users to read the migration
> guide?
>
> On 25 February 2016 at 10:21, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:
>
>> ok, thanks! you are right, I should have read the migration guide.
>>
>> On 25 Feb 2016, at 10:19, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>> Yes, it has moved. I forgot to update the themes doc, but it's included
>> in the migration guide.
>>
>> Always read the migration guide before upgrading! It will quite likely
>> save you a lot of time.
>>
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997
>>
>> On 25 February 2016 at 10:00, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> This was discussed a few days ago on the dev list:
>>> http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>>>
>>> Perhaphs there should have sent a mail to the user-list as well...
>>>
>>> Cheers,
>>> Thomas
>>>
>>> 2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl <http://info.nl> <
>>> Edgar at info.nl>:
>>>
>>>> Hi,
>>>>
>>>> It seems that the themes folder has moved in Keycloak 1.9.0.Final (from
>>>> 1.9.0.RC1)?
>>>>
>>>> The themes folder used to be:
>>>> $KEYCLOAK_HOME/standalone/configuration/themes
>>>>
>>>> but now it seems to be:
>>>> $KEYCLOAK_HOME/themes
>>>>
>>>> The documentation still mentions the old location so I think needs to
>>>> be updated?
>>>>
>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>>>
>>>> cheers
>>>>
>>>> Edgar
>>>> _______________________________________________
>>>> 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/20160225/c7788550/attachment-0001.html 

From sthorger at redhat.com  Thu Feb 25 04:26:14 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Feb 2016 10:26:14 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CAK-7U1jG6kN5zpJ9YQi154ajm0Lii4KQ5W+a0HmGjm7rPFFJcA@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
	<CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
	<CAJgngAdLyk=O8DY5go+m+B6+tJzbj0wnF362FG+=HOGQPYH81A@mail.gmail.com>
	<CADjGaacaf+3tAPocJdsPno=X221UgRRd_X+yMkoH=91HLp8F8w@mail.gmail.com>
	<CAJgngAdmjMyMUSw6LG_5y_WaB+PPEsZb1WqQ3N_uMJcq3Kh-tw@mail.gmail.com>
	<CADjGaafD9p=jzOVnBEMwpvJKS7VzMYTpQD1Ujgr+Vnj5A=xpUA@mail.gmail.com>
	<CAJgngAdD6_iA_cFob0dKU+vJm84BfY8K-woUjaHJr=20gAXjSA@mail.gmail.com>
	<CAK-7U1hqdiqQjeTfCp_nUeehQdrDsPb1Qptqf+oWOPE9Ghc07g@mail.gmail.com>
	<CADjGaadXezH5kURnkP87c8g6opKnkb0Zzek3P-W2TwnV42-mng@mail.gmail.com>
	<CAK-7U1jG6kN5zpJ9YQi154ajm0Lii4KQ5W+a0HmGjm7rPFFJcA@mail.gmail.com>
Message-ID: <CAJgngAeyfBhvp+XZb9B9Fs0UKeOiUOc9n6H6jf4C7d7faAuSMQ@mail.gmail.com>

I can see those details are things that you may want to add to a client,
but I don't see how you're going to utilize that information?

On 25 February 2016 at 09:55, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> FYI, back to the original question of allowing edit of client attributes
> from admin console...
>
> Some use cases where client attributes would be very handy:
> * additional metadata for applications
> * display-order for application listing
> * icon name in application listing (more flexible than deriving from
> client id)
> * tagging of clients as internal, public etc.
> * application version
> * url for checking application status (health check endpoint) - ok,
> maintenance, offline
>
> Would be happy to send a PR for editing of client attributes in the admin
> console.
>
> Cheers,
> Thomas
>
> 2016-02-22 13:58 GMT+01:00 Bystrik Horvath <bystrik.horvath at gmail.com>:
>
>> Thank you guys for the answers, I think you & Stian directed me to the
>> right way, so it should solve my requirements.
>>
>> Best regards,
>> Bystrik
>>
>>
>>
>> On Mon, Feb 22, 2016 at 1:48 PM, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> You could define the set of secret questions on the authenticator - you
>>> could either hardcode them or make them configurable by implementing
>>> ConfiguredProvider see [0].
>>> Then you could store a reference to the selected secret question and the
>>> answer as a custom user-attribute.
>>>
>>> Cheers,
>>>
>>> Thomas
>>>
>>> [0] -
>>> https://github.com/keycloak/keycloak/blob/60f9f73c4ca2ddf4ad49ff53a03a63dca8148ea9/server-spi/src/main/java/org/keycloak/provider/ConfiguredProvider.java#L26
>>>
>>> Stian Thorgersen <sthorger at redhat.com> schrieb am Mo., 22. Feb. 2016,
>>> 13:40:
>>>
>>>> I thought the example did allow configuring the security question on
>>>> the authenticator, but you can create your own that does it. Then the
>>>> security questions are configured on the authenticator itself.
>>>>
>>>> On 22 February 2016 at 13:24, Bystrik Horvath <
>>>> bystrik.horvath at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I went through the example (
>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator).
>>>>> The security questions are written in secret-question.ftl
>>>>> and secret-question-config.ftl files. From my point of view, the security
>>>>> questions are know in advance and they can be "hardcoded" in ftl files. My
>>>>> case is that security questions are defined during the runtime (preferably
>>>>> via  admin REST API). The admin REST API does not provide the functionality
>>>>> to store attributes on realm level. I agree that security questions belongs
>>>>> to realm, but how to provision them - *.ftl files are not an option for me.
>>>>>
>>>>> Best regards,
>>>>> Bystrik
>>>>>
>>>>> On Mon, Feb 22, 2016 at 12:55 PM, Stian Thorgersen <
>>>>> sthorger at redhat.com> wrote:
>>>>>
>>>>>> If you look at our security questions example it stores the
>>>>>> configuration on the authenticator itself.
>>>>>>
>>>>>> On 22 February 2016 at 12:46, Bystrik Horvath <
>>>>>> bystrik.horvath at gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> what would be a recommended way to provision a security question on
>>>>>>> realm base if the question is not known in advance? May be it is an misuse
>>>>>>> of client representation for provisioning that.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Bystrik
>>>>>>>
>>>>>>> On Mon, Feb 22, 2016 at 12:28 PM, Stian Thorgersen <
>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>> I don't understand how you can have security questions that are
>>>>>>>> particular to a client. A user logs-in to a realm, not a client.
>>>>>>>>
>>>>>>>> On 22 February 2016 at 10:20, Juraj Janosik <
>>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> @ Stian:
>>>>>>>>> generally said, I did not find any description, that the client
>>>>>>>>> attributes are for internal use only.
>>>>>>>>> Parameter "attributes" is propagated in ClientRepresentation in
>>>>>>>>> the REST Admin API,
>>>>>>>>> therefore should be used for CRUD admin operations.
>>>>>>>>> We plan to attach Security Answers to the user (Security questions
>>>>>>>>> are common for particular client).
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Juraj
>>>>>>>>>
>>>>>>>>> 2016-02-22 10:18 GMT+01:00 Bystrik Horvath <
>>>>>>>>> bystrik.horvath at gmail.com>:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I think the case here is to provision the text of security
>>>>>>>>>> question to the client attributes when it is not known in advance.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Bystrik
>>>>>>>>>>
>>>>>>>>>> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
>>>>>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Interesting - do you need client specific security questions?
>>>>>>>>>>>
>>>>>>>>>>> The keycloak examples contain a custom provider for user
>>>>>>>>>>> specific security questions - perhaps this would suit your needs better.
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Thomas
>>>>>>>>>>>
>>>>>>>>>>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <
>>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Thomas,
>>>>>>>>>>>>
>>>>>>>>>>>> for example security questions.... :-)
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Juraj
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>>>>>>>>>>> thomas.darimont at googlemail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Juraj,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I wondered about that too a while ago - may I ask what client
>>>>>>>>>>>>> attributes you are planning to store?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <
>>>>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The user configuration has the possibility to
>>>>>>>>>>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>>>>>>>>>>> The client does not. I think, the logic and the focus is the
>>>>>>>>>>>>>> same for both.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <
>>>>>>>>>>>>>> sthorger at redhat.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We don't. Why would we add it though?
>>>>>>>>>>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <
>>>>>>>>>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> is there any plan to support for displaying of "attributes"
>>>>>>>>>>>>>>>> from Client Representation
>>>>>>>>>>>>>>>> (like users configuration) in Admin Console?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/5cc8b788/attachment.html 

From sthorger at redhat.com  Thu Feb 25 04:28:03 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Feb 2016 10:28:03 +0100
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
	<CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
	<CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>
Message-ID: <CAJgngAcJcNYF0vezwT0ctp0Hg3KQLvOFmXO9YEk=gxayz6xtzA@mail.gmail.com>

Bruno: No need to update theme chapter - Marc from APIMan is already on the
task :)

"Before you get started" will that be read though? I can't see current
users reading that.

On 25 February 2016 at 10:25, Bruno Oliveira <bruno at abstractj.org> wrote:

> I will review the whole theme chapter today and see if I find any
> mismatches.
>
> Regarding your question, I'd add a section in the very beginning of our
> guide called "Before you get started".
>
> On Thu, Feb 25, 2016 at 6:23 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Any tips on how we can make it more obvious to users to read the
>> migration guide?
>>
>> On 25 February 2016 at 10:21, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:
>>
>>> ok, thanks! you are right, I should have read the migration guide.
>>>
>>> On 25 Feb 2016, at 10:19, Stian Thorgersen <sthorger at redhat.com> wrote:
>>>
>>> Yes, it has moved. I forgot to update the themes doc, but it's included
>>> in the migration guide.
>>>
>>> Always read the migration guide before upgrading! It will quite likely
>>> save you a lot of time.
>>>
>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997
>>>
>>> On 25 February 2016 at 10:00, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> This was discussed a few days ago on the dev list:
>>>> http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>>>>
>>>> Perhaphs there should have sent a mail to the user-list as well...
>>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>> 2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl <http://info.nl> <
>>>> Edgar at info.nl>:
>>>>
>>>>> Hi,
>>>>>
>>>>> It seems that the themes folder has moved in Keycloak 1.9.0.Final
>>>>> (from 1.9.0.RC1)?
>>>>>
>>>>> The themes folder used to be:
>>>>> $KEYCLOAK_HOME/standalone/configuration/themes
>>>>>
>>>>> but now it seems to be:
>>>>> $KEYCLOAK_HOME/themes
>>>>>
>>>>> The documentation still mentions the old location so I think needs to
>>>>> be updated?
>>>>>
>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>>>>
>>>>> cheers
>>>>>
>>>>> Edgar
>>>>> _______________________________________________
>>>>> 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/20160225/15f24aeb/attachment-0001.html 

From bystrik.horvath at gmail.com  Thu Feb 25 04:44:10 2016
From: bystrik.horvath at gmail.com (Bystrik Horvath)
Date: Thu, 25 Feb 2016 10:44:10 +0100
Subject: [keycloak-user] Forgot password flow
Message-ID: <CADjGaad-yvaC=-RtaoeBjRBOx8XAJQX8NUzvEj=Brq+szCwVYw@mail.gmail.com>

Hello,

it is perfectly possible to reset the forgotten password via
execute-actions-email on UsersResource which leads to generation of email
containing the link for completing the password reset action (e.g:
http://localhost:8080/auth/realms/publicRealm/login-actions/execute-actions?key=q8ySsRJNmt0G_LUP3IlL_TvNTTSiGnKa9ScRC7HxtOU.8b26e57f-811b-4a77-bc35-47c37a03909e
)
Reset password flows ends in account client where the user changes the
password to the one he likes.

How would  it be possible to finish the flow without with interacting with
account client? E.g. directly set new credential via REST call?


Best regards,
Bystrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/e294e626/attachment.html 

From thomas.darimont at googlemail.com  Thu Feb 25 05:10:10 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 25 Feb 2016 11:10:10 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CAJgngAeyfBhvp+XZb9B9Fs0UKeOiUOc9n6H6jf4C7d7faAuSMQ@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
	<CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
	<CAJgngAdLyk=O8DY5go+m+B6+tJzbj0wnF362FG+=HOGQPYH81A@mail.gmail.com>
	<CADjGaacaf+3tAPocJdsPno=X221UgRRd_X+yMkoH=91HLp8F8w@mail.gmail.com>
	<CAJgngAdmjMyMUSw6LG_5y_WaB+PPEsZb1WqQ3N_uMJcq3Kh-tw@mail.gmail.com>
	<CADjGaafD9p=jzOVnBEMwpvJKS7VzMYTpQD1Ujgr+Vnj5A=xpUA@mail.gmail.com>
	<CAJgngAdD6_iA_cFob0dKU+vJm84BfY8K-woUjaHJr=20gAXjSA@mail.gmail.com>
	<CAK-7U1hqdiqQjeTfCp_nUeehQdrDsPb1Qptqf+oWOPE9Ghc07g@mail.gmail.com>
	<CADjGaadXezH5kURnkP87c8g6opKnkb0Zzek3P-W2TwnV42-mng@mail.gmail.com>
	<CAK-7U1jG6kN5zpJ9YQi154ajm0Lii4KQ5W+a0HmGjm7rPFFJcA@mail.gmail.com>
	<CAJgngAeyfBhvp+XZb9B9Fs0UKeOiUOc9n6H6jf4C7d7faAuSMQ@mail.gmail.com>
Message-ID: <CAK-7U1iGArA43jBnTOVMG-Or8k3Cm6eYabbGtPJVH64s_BjiYg@mail.gmail.com>

Thanks for the quick response :)

Well, one example would be the applications listing in the self-service
account UI:

* I want to control the order of application items in the list
* I want to show whether the application can be currently accessed or not
(at least I want to give a hint)
* I want to group certain applications (HR, Finance, Customers) etc. based
on tags

Other areas would be a mobile app that presents the "service-portfolio"
with the apps currently available for a user.
(this would be provided by a intermediate service though but the data would
be read from client attributes).

Cheers,
Thomas


2016-02-25 10:26 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> I can see those details are things that you may want to add to a client,
> but I don't see how you're going to utilize that information?
>
> On 25 February 2016 at 09:55, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> FYI, back to the original question of allowing edit of client attributes
>> from admin console...
>>
>> Some use cases where client attributes would be very handy:
>> * additional metadata for applications
>> * display-order for application listing
>> * icon name in application listing (more flexible than deriving from
>> client id)
>> * tagging of clients as internal, public etc.
>> * application version
>> * url for checking application status (health check endpoint) - ok,
>> maintenance, offline
>>
>> Would be happy to send a PR for editing of client attributes in the admin
>> console.
>>
>> Cheers,
>> Thomas
>>
>> 2016-02-22 13:58 GMT+01:00 Bystrik Horvath <bystrik.horvath at gmail.com>:
>>
>>> Thank you guys for the answers, I think you & Stian directed me to the
>>> right way, so it should solve my requirements.
>>>
>>> Best regards,
>>> Bystrik
>>>
>>>
>>>
>>> On Mon, Feb 22, 2016 at 1:48 PM, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> You could define the set of secret questions on the authenticator - you
>>>> could either hardcode them or make them configurable by implementing
>>>> ConfiguredProvider see [0].
>>>> Then you could store a reference to the selected secret question and
>>>> the answer as a custom user-attribute.
>>>>
>>>> Cheers,
>>>>
>>>> Thomas
>>>>
>>>> [0] -
>>>> https://github.com/keycloak/keycloak/blob/60f9f73c4ca2ddf4ad49ff53a03a63dca8148ea9/server-spi/src/main/java/org/keycloak/provider/ConfiguredProvider.java#L26
>>>>
>>>> Stian Thorgersen <sthorger at redhat.com> schrieb am Mo., 22. Feb. 2016,
>>>> 13:40:
>>>>
>>>>> I thought the example did allow configuring the security question on
>>>>> the authenticator, but you can create your own that does it. Then the
>>>>> security questions are configured on the authenticator itself.
>>>>>
>>>>> On 22 February 2016 at 13:24, Bystrik Horvath <
>>>>> bystrik.horvath at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I went through the example (
>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator).
>>>>>> The security questions are written in secret-question.ftl
>>>>>> and secret-question-config.ftl files. From my point of view, the security
>>>>>> questions are know in advance and they can be "hardcoded" in ftl files. My
>>>>>> case is that security questions are defined during the runtime (preferably
>>>>>> via  admin REST API). The admin REST API does not provide the functionality
>>>>>> to store attributes on realm level. I agree that security questions belongs
>>>>>> to realm, but how to provision them - *.ftl files are not an option for me.
>>>>>>
>>>>>> Best regards,
>>>>>> Bystrik
>>>>>>
>>>>>> On Mon, Feb 22, 2016 at 12:55 PM, Stian Thorgersen <
>>>>>> sthorger at redhat.com> wrote:
>>>>>>
>>>>>>> If you look at our security questions example it stores the
>>>>>>> configuration on the authenticator itself.
>>>>>>>
>>>>>>> On 22 February 2016 at 12:46, Bystrik Horvath <
>>>>>>> bystrik.horvath at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> what would be a recommended way to provision a security question on
>>>>>>>> realm base if the question is not known in advance? May be it is an misuse
>>>>>>>> of client representation for provisioning that.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Bystrik
>>>>>>>>
>>>>>>>> On Mon, Feb 22, 2016 at 12:28 PM, Stian Thorgersen <
>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> I don't understand how you can have security questions that are
>>>>>>>>> particular to a client. A user logs-in to a realm, not a client.
>>>>>>>>>
>>>>>>>>> On 22 February 2016 at 10:20, Juraj Janosik <
>>>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> @ Stian:
>>>>>>>>>> generally said, I did not find any description, that the client
>>>>>>>>>> attributes are for internal use only.
>>>>>>>>>> Parameter "attributes" is propagated in ClientRepresentation in
>>>>>>>>>> the REST Admin API,
>>>>>>>>>> therefore should be used for CRUD admin operations.
>>>>>>>>>> We plan to attach Security Answers to the user (Security
>>>>>>>>>> questions are common for particular client).
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Juraj
>>>>>>>>>>
>>>>>>>>>> 2016-02-22 10:18 GMT+01:00 Bystrik Horvath <
>>>>>>>>>> bystrik.horvath at gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I think the case here is to provision the text of security
>>>>>>>>>>> question to the client attributes when it is not known in advance.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Bystrik
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
>>>>>>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Interesting - do you need client specific security questions?
>>>>>>>>>>>>
>>>>>>>>>>>> The keycloak examples contain a custom provider for user
>>>>>>>>>>>> specific security questions - perhaps this would suit your needs better.
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Thomas
>>>>>>>>>>>>
>>>>>>>>>>>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <
>>>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Thomas,
>>>>>>>>>>>>>
>>>>>>>>>>>>> for example security questions.... :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>>>>>>>>>>>> thomas.darimont at googlemail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello Juraj,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I wondered about that too a while ago - may I ask what client
>>>>>>>>>>>>>> attributes you are planning to store?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <
>>>>>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The user configuration has the possibility to
>>>>>>>>>>>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>>>>>>>>>>>> The client does not. I think, the logic and the focus is the
>>>>>>>>>>>>>>> same for both.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <
>>>>>>>>>>>>>>> sthorger at redhat.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We don't. Why would we add it though?
>>>>>>>>>>>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <
>>>>>>>>>>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> is there any plan to support for displaying of
>>>>>>>>>>>>>>>>> "attributes" from Client Representation
>>>>>>>>>>>>>>>>> (like users configuration) in Admin Console?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/ef261ff1/attachment-0001.html 

From mposolda at redhat.com  Thu Feb 25 05:24:51 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 25 Feb 2016 11:24:51 +0100
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <CAJgngAcJcNYF0vezwT0ctp0Hg3KQLvOFmXO9YEk=gxayz6xtzA@mail.gmail.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
	<CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
	<CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>
	<CAJgngAcJcNYF0vezwT0ctp0Hg3KQLvOFmXO9YEk=gxayz6xtzA@mail.gmail.com>
Message-ID: <56CED673.5060201@redhat.com>

Maybe the best chance people won't miss it, is to put the note into 
release announcement? Just something high level like "We changed 
location of themes and did some other changes XYZ. Don't forget to read 
migration guide for more details" or something like that?

Marek

On 25/02/16 10:28, Stian Thorgersen wrote:
> Bruno: No need to update theme chapter - Marc from APIMan is already 
> on the task :)
>
> "Before you get started" will that be read though? I can't see current 
> users reading that.
>
> On 25 February 2016 at 10:25, Bruno Oliveira <bruno at abstractj.org 
> <mailto:bruno at abstractj.org>> wrote:
>
>     I will review the whole theme chapter today and see if I find any
>     mismatches.
>
>     Regarding your question, I'd add a section in the very beginning
>     of our guide called "Before you get started".
>
>     On Thu, Feb 25, 2016 at 6:23 AM Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>
>         Any tips on how we can make it more obvious to users to read
>         the migration guide?
>
>         On 25 February 2016 at 10:21, Edgar Vonk - Info.nl
>         <Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>
>             ok, thanks! you are right, I should have read the
>             migration guide.
>
>>             On 25 Feb 2016, at 10:19, Stian Thorgersen
>>             <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>             Yes, it has moved. I forgot to update the themes doc, but
>>             it's included in the migration guide.
>>
>>             Always read the migration guide before upgrading! It will
>>             quite likely save you a lot of time.
>>             http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997
>>
>>             On 25 February 2016 at 10:00, Thomas Darimont
>>             <thomas.darimont at googlemail.com
>>             <mailto:thomas.darimont at googlemail.com>> wrote:
>>
>>                 This was discussed a few days ago on the dev list:
>>                 http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>>
>>                 Perhaphs there should have sent a mail to the
>>                 user-list as well...
>>
>>                 Cheers,
>>                 Thomas
>>
>>                 2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl
>>                 <http://info.nl> <Edgar at info.nl <mailto:Edgar at info.nl>>:
>>
>>                     Hi,
>>
>>                     It seems that the themes folder has moved in
>>                     Keycloak 1.9.0.Final (from 1.9.0.RC1)?
>>
>>                     The themes folder used to be:
>>                     $KEYCLOAK_HOME/standalone/configuration/themes
>>
>>                     but now it seems to be:
>>                     $KEYCLOAK_HOME/themes
>>
>>                     The documentation still mentions the old location
>>                     so I think needs to be updated?
>>                     http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>
>>                     cheers
>>
>>                     Edgar
>>                     _______________________________________________
>>                     keycloak-user mailing list
>>                     keycloak-user at lists.jboss.org
>>                     <mailto:keycloak-user at lists.jboss.org>
>>                     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>>                 _______________________________________________
>>                 keycloak-user mailing list
>>                 keycloak-user at lists.jboss.org
>>                 <mailto:keycloak-user at lists.jboss.org>
>>                 https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>
>
>         _______________________________________________
>         keycloak-user mailing list
>         keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> 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/20160225/5ba14419/attachment.html 

From Edgar at info.nl  Thu Feb 25 05:36:01 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 25 Feb 2016 10:36:01 +0000
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <56CED673.5060201@redhat.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
	<CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
	<CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>
	<CAJgngAcJcNYF0vezwT0ctp0Hg3KQLvOFmXO9YEk=gxayz6xtzA@mail.gmail.com>
	<56CED673.5060201@redhat.com>
Message-ID: <5300B1FC-4AF0-4A09-8B80-E874BD5E0998@info.nl>

that would certainly help indeed!

as an example this is how Magnolia (a Java CMS we often use in our projects) does it:
https://forums.magnolia-cms.com/forum/thread.html?threadId=5f23d559-16be-4637-b3a5-dcb8dddc24c1#41e491fa-7abf-4c92-ae97-063c75895db5

I think they removed it now but they even had a automatically generated section in their release notes with a list of people who ?contributed? by reporting issues in JIRA that were fixed in the release. A way to attach your users to your product I guess.


On 25 Feb 2016, at 11:24, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:

Maybe the best chance people won't miss it, is to put the note into release announcement? Just something high level like "We changed location of themes and did some other changes XYZ. Don't forget to read migration guide for more details" or something like that?

Marek

On 25/02/16 10:28, Stian Thorgersen wrote:
Bruno: No need to update theme chapter - Marc from APIMan is already on the task :)

"Before you get started" will that be read though? I can't see current users reading that.

On 25 February 2016 at 10:25, Bruno Oliveira <bruno at abstractj.org<mailto:bruno at abstractj.org>> wrote:
I will review the whole theme chapter today and see if I find any mismatches.

Regarding your question, I'd add a section in the very beginning of our guide called "Before you get started".

On Thu, Feb 25, 2016 at 6:23 AM Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>> wrote:
Any tips on how we can make it more obvious to users to read the migration guide?

On 25 February 2016 at 10:21, Edgar Vonk - Info.nl<http://info.nl> <<mailto:Edgar at info.nl>Edgar at info.nl<mailto:Edgar at info.nl>> wrote:
ok, thanks! you are right, I should have read the migration guide.

On 25 Feb 2016, at 10:19, Stian Thorgersen <<mailto:sthorger at redhat.com>sthorger at redhat.com<mailto:sthorger at redhat.com>> wrote:

Yes, it has moved. I forgot to update the themes doc, but it's included in the migration guide.

Always read the migration guide before upgrading! It will quite likely save you a lot of time.
http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997

On 25 February 2016 at 10:00, Thomas Darimont <<mailto:thomas.darimont at googlemail.com>thomas.darimont at googlemail.com<mailto:thomas.darimont at googlemail.com>> wrote:
This was discussed a few days ago on the dev list:
<http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html>http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html

Perhaphs there should have sent a mail to the user-list as well...

Cheers,
Thomas

2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl<http://info.nl/> <<mailto:Edgar at info.nl>Edgar at info.nl<mailto:Edgar at info.nl>>:
Hi,

It seems that the themes folder has moved in Keycloak 1.9.0.Final (from 1.9.0.RC1)?

The themes folder used to be:
$KEYCLOAK_HOME/standalone/configuration/themes

but now it seems to be:
$KEYCLOAK_HOME/themes

The documentation still mentions the old location so I think needs to be updated?
<http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431>http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431

cheers

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


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



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




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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/89f35f33/attachment-0001.html 

From sthorger at redhat.com  Thu Feb 25 06:02:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Feb 2016 12:02:12 +0100
Subject: [keycloak-user] Admin Console: Clients Configuration:
 Displaying of "attributes" from Client Representation
In-Reply-To: <CAK-7U1iGArA43jBnTOVMG-Or8k3Cm6eYabbGtPJVH64s_BjiYg@mail.gmail.com>
References: <CALQqei3J30Gi5-rPHHZZUq4bwA-qwkgP3bxEiiS3M4m+_83oAg@mail.gmail.com>
	<CAJgngAfdsGfZ5troxoghYw6WDj_0mnZUbv1DuOO5fHQcLCM3Cw@mail.gmail.com>
	<CALQqei0+zDsRZL8+zpqpaWpjLauXVV0a=4mwkTN2hk1ZZ_Vzew@mail.gmail.com>
	<CAK-7U1iPBNMGin6RoFLagb0QFbBjWEvGkLrtSmvs-+xLU2P0dQ@mail.gmail.com>
	<CALQqei1-OfH8Ai3VW_OmGwEgwk515cRnk5rcdh0JaO7_8XaOFw@mail.gmail.com>
	<CAK-7U1gZ943xzadsSm0VHtOBnmpx_4pcJhAuc5h==G1Z2n01KA@mail.gmail.com>
	<CADjGaaeT4RW+XBqdEQ7hX4Ece_SgphV3NrVnj7AOz-7=7WNGFA@mail.gmail.com>
	<CALQqei3u2sXvnwY=tvpXBqTG5CdQ4EZucRpXRgGJ-aPQwsG_9g@mail.gmail.com>
	<CAJgngAdLyk=O8DY5go+m+B6+tJzbj0wnF362FG+=HOGQPYH81A@mail.gmail.com>
	<CADjGaacaf+3tAPocJdsPno=X221UgRRd_X+yMkoH=91HLp8F8w@mail.gmail.com>
	<CAJgngAdmjMyMUSw6LG_5y_WaB+PPEsZb1WqQ3N_uMJcq3Kh-tw@mail.gmail.com>
	<CADjGaafD9p=jzOVnBEMwpvJKS7VzMYTpQD1Ujgr+Vnj5A=xpUA@mail.gmail.com>
	<CAJgngAdD6_iA_cFob0dKU+vJm84BfY8K-woUjaHJr=20gAXjSA@mail.gmail.com>
	<CAK-7U1hqdiqQjeTfCp_nUeehQdrDsPb1Qptqf+oWOPE9Ghc07g@mail.gmail.com>
	<CADjGaadXezH5kURnkP87c8g6opKnkb0Zzek3P-W2TwnV42-mng@mail.gmail.com>
	<CAK-7U1jG6kN5zpJ9YQi154ajm0Lii4KQ5W+a0HmGjm7rPFFJcA@mail.gmail.com>
	<CAJgngAeyfBhvp+XZb9B9Fs0UKeOiUOc9n6H6jf4C7d7faAuSMQ@mail.gmail.com>
	<CAK-7U1iGArA43jBnTOVMG-Or8k3Cm6eYabbGtPJVH64s_BjiYg@mail.gmail.com>
Message-ID: <CAJgngAdLhUqg2Dx_fxoEkybWzbzUdi-yFBLQNvXzELtn3nhGGw@mail.gmail.com>

True, it's relevant to our discussion about a "client" service as well.

A lot of that is something we should add support for directly. In 2.x I'd
like to introduce the "client" landing page and "client" details endpoint
we discussed before. Also, we are planning on completely revamping the self
service console (it's pretty rubbish and we know it!).

Having an option to control the order of applications as well as a grouping
mechanism sounds like something we could introduce ootb. I'm not sure what
you mean about whether or not the application can be accessed or not, but
wouldn't enabled/disabled do the job, or are you talking about a ping
mechanism or something?

I'm not convinced about introducing a generic attributes table for clients,
but let's keep the discussion on it open ;)

On 25 February 2016 at 11:10, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Thanks for the quick response :)
>
> Well, one example would be the applications listing in the self-service
> account UI:
>
> * I want to control the order of application items in the list
> * I want to show whether the application can be currently accessed or not
> (at least I want to give a hint)
> * I want to group certain applications (HR, Finance, Customers) etc. based
> on tags
>
> Other areas would be a mobile app that presents the "service-portfolio"
> with the apps currently available for a user.
> (this would be provided by a intermediate service though but the data
> would be read from client attributes).
>
> Cheers,
> Thomas
>
>
> 2016-02-25 10:26 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> I can see those details are things that you may want to add to a client,
>> but I don't see how you're going to utilize that information?
>>
>> On 25 February 2016 at 09:55, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> FYI, back to the original question of allowing edit of client attributes
>>> from admin console...
>>>
>>> Some use cases where client attributes would be very handy:
>>> * additional metadata for applications
>>> * display-order for application listing
>>> * icon name in application listing (more flexible than deriving from
>>> client id)
>>> * tagging of clients as internal, public etc.
>>> * application version
>>> * url for checking application status (health check endpoint) - ok,
>>> maintenance, offline
>>>
>>> Would be happy to send a PR for editing of client attributes in the
>>> admin console.
>>>
>>> Cheers,
>>> Thomas
>>>
>>> 2016-02-22 13:58 GMT+01:00 Bystrik Horvath <bystrik.horvath at gmail.com>:
>>>
>>>> Thank you guys for the answers, I think you & Stian directed me to the
>>>> right way, so it should solve my requirements.
>>>>
>>>> Best regards,
>>>> Bystrik
>>>>
>>>>
>>>>
>>>> On Mon, Feb 22, 2016 at 1:48 PM, Thomas Darimont <
>>>> thomas.darimont at googlemail.com> wrote:
>>>>
>>>>> You could define the set of secret questions on the authenticator -
>>>>> you could either hardcode them or make them configurable by implementing
>>>>> ConfiguredProvider see [0].
>>>>> Then you could store a reference to the selected secret question and
>>>>> the answer as a custom user-attribute.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Thomas
>>>>>
>>>>> [0] -
>>>>> https://github.com/keycloak/keycloak/blob/60f9f73c4ca2ddf4ad49ff53a03a63dca8148ea9/server-spi/src/main/java/org/keycloak/provider/ConfiguredProvider.java#L26
>>>>>
>>>>> Stian Thorgersen <sthorger at redhat.com> schrieb am Mo., 22. Feb. 2016,
>>>>> 13:40:
>>>>>
>>>>>> I thought the example did allow configuring the security question on
>>>>>> the authenticator, but you can create your own that does it. Then the
>>>>>> security questions are configured on the authenticator itself.
>>>>>>
>>>>>> On 22 February 2016 at 13:24, Bystrik Horvath <
>>>>>> bystrik.horvath at gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I went through the example (
>>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator).
>>>>>>> The security questions are written in secret-question.ftl
>>>>>>> and secret-question-config.ftl files. From my point of view, the security
>>>>>>> questions are know in advance and they can be "hardcoded" in ftl files. My
>>>>>>> case is that security questions are defined during the runtime (preferably
>>>>>>> via  admin REST API). The admin REST API does not provide the functionality
>>>>>>> to store attributes on realm level. I agree that security questions belongs
>>>>>>> to realm, but how to provision them - *.ftl files are not an option for me.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Bystrik
>>>>>>>
>>>>>>> On Mon, Feb 22, 2016 at 12:55 PM, Stian Thorgersen <
>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>> If you look at our security questions example it stores the
>>>>>>>> configuration on the authenticator itself.
>>>>>>>>
>>>>>>>> On 22 February 2016 at 12:46, Bystrik Horvath <
>>>>>>>> bystrik.horvath at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> what would be a recommended way to provision a security question
>>>>>>>>> on realm base if the question is not known in advance? May be it is an
>>>>>>>>> misuse of client representation for provisioning that.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Bystrik
>>>>>>>>>
>>>>>>>>> On Mon, Feb 22, 2016 at 12:28 PM, Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> I don't understand how you can have security questions that are
>>>>>>>>>> particular to a client. A user logs-in to a realm, not a client.
>>>>>>>>>>
>>>>>>>>>> On 22 February 2016 at 10:20, Juraj Janosik <
>>>>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> @ Stian:
>>>>>>>>>>> generally said, I did not find any description, that the client
>>>>>>>>>>> attributes are for internal use only.
>>>>>>>>>>> Parameter "attributes" is propagated in ClientRepresentation in
>>>>>>>>>>> the REST Admin API,
>>>>>>>>>>> therefore should be used for CRUD admin operations.
>>>>>>>>>>> We plan to attach Security Answers to the user (Security
>>>>>>>>>>> questions are common for particular client).
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Juraj
>>>>>>>>>>>
>>>>>>>>>>> 2016-02-22 10:18 GMT+01:00 Bystrik Horvath <
>>>>>>>>>>> bystrik.horvath at gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I think the case here is to provision the text of security
>>>>>>>>>>>> question to the client attributes when it is not known in advance.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Bystrik
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Feb 22, 2016 at 10:06 AM, Thomas Darimont <
>>>>>>>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Interesting - do you need client specific security questions?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The keycloak examples contain a custom provider for user
>>>>>>>>>>>>> specific security questions - perhaps this would suit your needs better.
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/keycloak/keycloak/tree/master/examples/providers/authenticator
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2016-02-22 10:02 GMT+01:00 Juraj Janosik <
>>>>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Thomas,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> for example security questions.... :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2016-02-22 9:12 GMT+01:00 Thomas Darimont <
>>>>>>>>>>>>>> thomas.darimont at googlemail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello Juraj,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I wondered about that too a while ago - may I ask what
>>>>>>>>>>>>>>> client attributes you are planning to store?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2016-02-22 8:17 GMT+01:00 Juraj Janosik <
>>>>>>>>>>>>>>> juraj.janosik77 at gmail.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The user configuration has the possibility to
>>>>>>>>>>>>>>>> Create/Read/Update/Delete of "custom" attributes in the Admin Console.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (/auth/admin/master/console/#/realms/demo/users/{uid}/user-attributes)
>>>>>>>>>>>>>>>> The client does not. I think, the logic and the focus is
>>>>>>>>>>>>>>>> the same for both.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2016-02-19 15:40 GMT+01:00 Stian Thorgersen <
>>>>>>>>>>>>>>>> sthorger at redhat.com>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We don't. Why would we add it though?
>>>>>>>>>>>>>>>>> On 18 Feb 2016 12:43, "Juraj Janosik" <
>>>>>>>>>>>>>>>>> juraj.janosik77 at gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> is there any plan to support for displaying of
>>>>>>>>>>>>>>>>>> "attributes" from Client Representation
>>>>>>>>>>>>>>>>>> (like users configuration) in Admin Console?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>> Juraj
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/6622df97/attachment-0001.html 

From sthorger at redhat.com  Thu Feb 25 06:05:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Feb 2016 12:05:49 +0100
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <5300B1FC-4AF0-4A09-8B80-E874BD5E0998@info.nl>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
	<CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
	<CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>
	<CAJgngAcJcNYF0vezwT0ctp0Hg3KQLvOFmXO9YEk=gxayz6xtzA@mail.gmail.com>
	<56CED673.5060201@redhat.com>
	<5300B1FC-4AF0-4A09-8B80-E874BD5E0998@info.nl>
Message-ID: <CAJgngAeZ6Jjc06N3hvbs0O-xSxwzuOWgzDYiwRVWgWrXKiyAbg@mail.gmail.com>

What I'm going to do is:

* Short term - start mentioning important migration issues in release
announcement and link to migration doc
* Long term - start creating proper release notes and include in
documentation, release announcement in the future will just be highlights
and link to this

Comments?

On 25 February 2016 at 11:36, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:

> that would certainly help indeed!
>
> as an example this is how Magnolia (a Java CMS we often use in our
> projects) does it:
>
> https://forums.magnolia-cms.com/forum/thread.html?threadId=5f23d559-16be-4637-b3a5-dcb8dddc24c1#41e491fa-7abf-4c92-ae97-063c75895db5
>
> I think they removed it now but they even had a automatically generated
> section in their release notes with a list of people who ?contributed? by
> reporting issues in JIRA that were fixed in the release. A way to attach
> your users to your product I guess.
>
>
> On 25 Feb 2016, at 11:24, Marek Posolda <mposolda at redhat.com> wrote:
>
> Maybe the best chance people won't miss it, is to put the note into
> release announcement? Just something high level like "We changed location
> of themes and did some other changes XYZ. Don't forget to read migration
> guide for more details" or something like that?
>
> Marek
>
> On 25/02/16 10:28, Stian Thorgersen wrote:
>
> Bruno: No need to update theme chapter - Marc from APIMan is already on
> the task :)
>
> "Before you get started" will that be read though? I can't see current
> users reading that.
>
> On 25 February 2016 at 10:25, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> I will review the whole theme chapter today and see if I find any
>> mismatches.
>>
>> Regarding your question, I'd add a section in the very beginning of our
>> guide called "Before you get started".
>>
>> On Thu, Feb 25, 2016 at 6:23 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Any tips on how we can make it more obvious to users to read the
>>> migration guide?
>>>
>>> On 25 February 2016 at 10:21, Edgar Vonk - Info.nl <http://info.nl> <
>>> <Edgar at info.nl>Edgar at info.nl> wrote:
>>>
>>>> ok, thanks! you are right, I should have read the migration guide.
>>>>
>>>> On 25 Feb 2016, at 10:19, Stian Thorgersen < <sthorger at redhat.com>
>>>> sthorger at redhat.com> wrote:
>>>>
>>>> Yes, it has moved. I forgot to update the themes doc, but it's included
>>>> in the migration guide.
>>>>
>>>> Always read the migration guide before upgrading! It will quite likely
>>>> save you a lot of time.
>>>>
>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997
>>>>
>>>> On 25 February 2016 at 10:00, Thomas Darimont <
>>>> <thomas.darimont at googlemail.com>thomas.darimont at googlemail.com> wrote:
>>>>
>>>>> This was discussed a few days ago on the dev list:
>>>>>
>>>>> <http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html>
>>>>> http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>>>>>
>>>>> Perhaphs there should have sent a mail to the user-list as well...
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>>
>>>>> 2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl <http://info.nl/> <
>>>>> <Edgar at info.nl>Edgar at info.nl>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It seems that the themes folder has moved in Keycloak 1.9.0.Final
>>>>>> (from 1.9.0.RC1)?
>>>>>>
>>>>>> The themes folder used to be:
>>>>>> $KEYCLOAK_HOME/standalone/configuration/themes
>>>>>>
>>>>>> but now it seems to be:
>>>>>> $KEYCLOAK_HOME/themes
>>>>>>
>>>>>> The documentation still mentions the old location so I think needs to
>>>>>> be updated?
>>>>>>
>>>>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431>
>>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>>>>>
>>>>>> cheers
>>>>>>
>>>>>> Edgar
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> <keycloak-user at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>
>
> _______________________________________________
> keycloak-user mailing 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/20160225/fcd47376/attachment.html 

From bruno at abstractj.org  Thu Feb 25 06:45:05 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 25 Feb 2016 11:45:05 +0000
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <CAJgngAeZ6Jjc06N3hvbs0O-xSxwzuOWgzDYiwRVWgWrXKiyAbg@mail.gmail.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
	<CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
	<CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>
	<CAJgngAcJcNYF0vezwT0ctp0Hg3KQLvOFmXO9YEk=gxayz6xtzA@mail.gmail.com>
	<56CED673.5060201@redhat.com>
	<5300B1FC-4AF0-4A09-8B80-E874BD5E0998@info.nl>
	<CAJgngAeZ6Jjc06N3hvbs0O-xSxwzuOWgzDYiwRVWgWrXKiyAbg@mail.gmail.com>
Message-ID: <CAM5SUC4DvtU3FK2iRCmapPYpvikZXK2S2XdAG2im7kG22NKKEQ@mail.gmail.com>

+1

On Thu, Feb 25, 2016 at 8:05 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> What I'm going to do is:
>
> * Short term - start mentioning important migration issues in release
> announcement and link to migration doc
> * Long term - start creating proper release notes and include in
> documentation, release announcement in the future will just be highlights
> and link to this
>
> Comments?
>
> On 25 February 2016 at 11:36, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:
>
>> that would certainly help indeed!
>>
>> as an example this is how Magnolia (a Java CMS we often use in our
>> projects) does it:
>>
>> https://forums.magnolia-cms.com/forum/thread.html?threadId=5f23d559-16be-4637-b3a5-dcb8dddc24c1#41e491fa-7abf-4c92-ae97-063c75895db5
>>
>> I think they removed it now but they even had a automatically generated
>> section in their release notes with a list of people who ?contributed? by
>> reporting issues in JIRA that were fixed in the release. A way to attach
>> your users to your product I guess.
>>
>>
>> On 25 Feb 2016, at 11:24, Marek Posolda <mposolda at redhat.com> wrote:
>>
>> Maybe the best chance people won't miss it, is to put the note into
>> release announcement? Just something high level like "We changed location
>> of themes and did some other changes XYZ. Don't forget to read migration
>> guide for more details" or something like that?
>>
>> Marek
>>
>> On 25/02/16 10:28, Stian Thorgersen wrote:
>>
>> Bruno: No need to update theme chapter - Marc from APIMan is already on
>> the task :)
>>
>> "Before you get started" will that be read though? I can't see current
>> users reading that.
>>
>> On 25 February 2016 at 10:25, Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>>> I will review the whole theme chapter today and see if I find any
>>> mismatches.
>>>
>>> Regarding your question, I'd add a section in the very beginning of our
>>> guide called "Before you get started".
>>>
>>> On Thu, Feb 25, 2016 at 6:23 AM Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Any tips on how we can make it more obvious to users to read the
>>>> migration guide?
>>>>
>>>> On 25 February 2016 at 10:21, Edgar Vonk - Info.nl <http://info.nl> <
>>>> <Edgar at info.nl>Edgar at info.nl> wrote:
>>>>
>>>>> ok, thanks! you are right, I should have read the migration guide.
>>>>>
>>>>> On 25 Feb 2016, at 10:19, Stian Thorgersen < <sthorger at redhat.com>
>>>>> sthorger at redhat.com> wrote:
>>>>>
>>>>> Yes, it has moved. I forgot to update the themes doc, but it's
>>>>> included in the migration guide.
>>>>>
>>>>> Always read the migration guide before upgrading! It will quite likely
>>>>> save you a lot of time.
>>>>>
>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997
>>>>>
>>>>> On 25 February 2016 at 10:00, Thomas Darimont <
>>>>> <thomas.darimont at googlemail.com>thomas.darimont at googlemail.com> wrote:
>>>>>
>>>>>> This was discussed a few days ago on the dev list:
>>>>>>
>>>>>> <http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html>
>>>>>> http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>>>>>>
>>>>>> Perhaphs there should have sent a mail to the user-list as well...
>>>>>>
>>>>>> Cheers,
>>>>>> Thomas
>>>>>>
>>>>>> 2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl <http://info.nl/> <
>>>>>> <Edgar at info.nl>Edgar at info.nl>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It seems that the themes folder has moved in Keycloak 1.9.0.Final
>>>>>>> (from 1.9.0.RC1)?
>>>>>>>
>>>>>>> The themes folder used to be:
>>>>>>> $KEYCLOAK_HOME/standalone/configuration/themes
>>>>>>>
>>>>>>> but now it seems to be:
>>>>>>> $KEYCLOAK_HOME/themes
>>>>>>>
>>>>>>> The documentation still mentions the old location so I think needs
>>>>>>> to be updated?
>>>>>>>
>>>>>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431>
>>>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>>>>>>
>>>>>>> cheers
>>>>>>>
>>>>>>> Edgar
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> <keycloak-user at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing 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/20160225/13782469/attachment-0001.html 

From mstrukel at redhat.com  Thu Feb 25 07:50:31 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Thu, 25 Feb 2016 13:50:31 +0100
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <CAM5SUC4DvtU3FK2iRCmapPYpvikZXK2S2XdAG2im7kG22NKKEQ@mail.gmail.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
	<CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
	<CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>
	<CAJgngAcJcNYF0vezwT0ctp0Hg3KQLvOFmXO9YEk=gxayz6xtzA@mail.gmail.com>
	<56CED673.5060201@redhat.com>
	<5300B1FC-4AF0-4A09-8B80-E874BD5E0998@info.nl>
	<CAJgngAeZ6Jjc06N3hvbs0O-xSxwzuOWgzDYiwRVWgWrXKiyAbg@mail.gmail.com>
	<CAM5SUC4DvtU3FK2iRCmapPYpvikZXK2S2XdAG2im7kG22NKKEQ@mail.gmail.com>
Message-ID: <CA+1OW+jiG3AfkzXkkZYbd3hGXwGMb89z6t2eUU6=xukz0pzvWw@mail.gmail.com>

Maybe it would be good to use GitHub's Releases for release notes as that's
a standard place people are used to look at - e.g.:
https://github.com/openshift/origin/releases.

But it could also be next to any download link -
http://keycloak.jboss.org/downloads could contain a README.TXT with link to
GitHub's Releases, for example.

On Thu, Feb 25, 2016 at 12:45 PM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> +1
>
> On Thu, Feb 25, 2016 at 8:05 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> What I'm going to do is:
>>
>> * Short term - start mentioning important migration issues in release
>> announcement and link to migration doc
>> * Long term - start creating proper release notes and include in
>> documentation, release announcement in the future will just be highlights
>> and link to this
>>
>> Comments?
>>
>> On 25 February 2016 at 11:36, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:
>>
>>> that would certainly help indeed!
>>>
>>> as an example this is how Magnolia (a Java CMS we often use in our
>>> projects) does it:
>>>
>>> https://forums.magnolia-cms.com/forum/thread.html?threadId=5f23d559-16be-4637-b3a5-dcb8dddc24c1#41e491fa-7abf-4c92-ae97-063c75895db5
>>>
>>> I think they removed it now but they even had a automatically generated
>>> section in their release notes with a list of people who ?contributed? by
>>> reporting issues in JIRA that were fixed in the release. A way to attach
>>> your users to your product I guess.
>>>
>>>
>>> On 25 Feb 2016, at 11:24, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>> Maybe the best chance people won't miss it, is to put the note into
>>> release announcement? Just something high level like "We changed location
>>> of themes and did some other changes XYZ. Don't forget to read migration
>>> guide for more details" or something like that?
>>>
>>> Marek
>>>
>>> On 25/02/16 10:28, Stian Thorgersen wrote:
>>>
>>> Bruno: No need to update theme chapter - Marc from APIMan is already on
>>> the task :)
>>>
>>> "Before you get started" will that be read though? I can't see current
>>> users reading that.
>>>
>>> On 25 February 2016 at 10:25, Bruno Oliveira <bruno at abstractj.org>
>>> wrote:
>>>
>>>> I will review the whole theme chapter today and see if I find any
>>>> mismatches.
>>>>
>>>> Regarding your question, I'd add a section in the very beginning of our
>>>> guide called "Before you get started".
>>>>
>>>> On Thu, Feb 25, 2016 at 6:23 AM Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Any tips on how we can make it more obvious to users to read the
>>>>> migration guide?
>>>>>
>>>>> On 25 February 2016 at 10:21, Edgar Vonk - Info.nl <http://info.nl> <
>>>>> <Edgar at info.nl>Edgar at info.nl> wrote:
>>>>>
>>>>>> ok, thanks! you are right, I should have read the migration guide.
>>>>>>
>>>>>> On 25 Feb 2016, at 10:19, Stian Thorgersen < <sthorger at redhat.com>
>>>>>> sthorger at redhat.com> wrote:
>>>>>>
>>>>>> Yes, it has moved. I forgot to update the themes doc, but it's
>>>>>> included in the migration guide.
>>>>>>
>>>>>> Always read the migration guide before upgrading! It will quite
>>>>>> likely save you a lot of time.
>>>>>>
>>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997
>>>>>>
>>>>>> On 25 February 2016 at 10:00, Thomas Darimont <
>>>>>> <thomas.darimont at googlemail.com>thomas.darimont at googlemail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This was discussed a few days ago on the dev list:
>>>>>>>
>>>>>>> <http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html>
>>>>>>> http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>>>>>>>
>>>>>>> Perhaphs there should have sent a mail to the user-list as well...
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Thomas
>>>>>>>
>>>>>>> 2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl <http://info.nl/> <
>>>>>>> <Edgar at info.nl>Edgar at info.nl>:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> It seems that the themes folder has moved in Keycloak 1.9.0.Final
>>>>>>>> (from 1.9.0.RC1)?
>>>>>>>>
>>>>>>>> The themes folder used to be:
>>>>>>>> $KEYCLOAK_HOME/standalone/configuration/themes
>>>>>>>>
>>>>>>>> but now it seems to be:
>>>>>>>> $KEYCLOAK_HOME/themes
>>>>>>>>
>>>>>>>> The documentation still mentions the old location so I think needs
>>>>>>>> to be updated?
>>>>>>>>
>>>>>>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431>
>>>>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>>>>>>>
>>>>>>>> cheers
>>>>>>>>
>>>>>>>> Edgar
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> <keycloak-user at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> keycloak-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160225/c179b84f/attachment.html 

From sthorger at redhat.com  Thu Feb 25 08:58:20 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Feb 2016 14:58:20 +0100
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <CA+1OW+jiG3AfkzXkkZYbd3hGXwGMb89z6t2eUU6=xukz0pzvWw@mail.gmail.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
	<CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
	<CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>
	<CAJgngAcJcNYF0vezwT0ctp0Hg3KQLvOFmXO9YEk=gxayz6xtzA@mail.gmail.com>
	<56CED673.5060201@redhat.com>
	<5300B1FC-4AF0-4A09-8B80-E874BD5E0998@info.nl>
	<CAJgngAeZ6Jjc06N3hvbs0O-xSxwzuOWgzDYiwRVWgWrXKiyAbg@mail.gmail.com>
	<CAM5SUC4DvtU3FK2iRCmapPYpvikZXK2S2XdAG2im7kG22NKKEQ@mail.gmail.com>
	<CA+1OW+jiG3AfkzXkkZYbd3hGXwGMb89z6t2eUU6=xukz0pzvWw@mail.gmail.com>
Message-ID: <CAJgngAcH5LD=ajdALC2+Ta9FK-L1F5DJ25JOO1tOa4EuxYYysw@mail.gmail.com>

I'd rather just add it to our documentation, which is available at
keycloak.org/docs so don't see any reason to use yet another thing.

On 25 February 2016 at 13:50, Marko Strukelj <mstrukel at redhat.com> wrote:

> Maybe it would be good to use GitHub's Releases for release notes as
> that's a standard place people are used to look at - e.g.:
> https://github.com/openshift/origin/releases.
>
> But it could also be next to any download link -
> http://keycloak.jboss.org/downloads could contain a README.TXT with link
> to GitHub's Releases, for example.
>
> On Thu, Feb 25, 2016 at 12:45 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> +1
>>
>> On Thu, Feb 25, 2016 at 8:05 AM Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> What I'm going to do is:
>>>
>>> * Short term - start mentioning important migration issues in release
>>> announcement and link to migration doc
>>> * Long term - start creating proper release notes and include in
>>> documentation, release announcement in the future will just be highlights
>>> and link to this
>>>
>>> Comments?
>>>
>>> On 25 February 2016 at 11:36, Edgar Vonk - Info.nl <Edgar at info.nl>
>>> wrote:
>>>
>>>> that would certainly help indeed!
>>>>
>>>> as an example this is how Magnolia (a Java CMS we often use in our
>>>> projects) does it:
>>>>
>>>> https://forums.magnolia-cms.com/forum/thread.html?threadId=5f23d559-16be-4637-b3a5-dcb8dddc24c1#41e491fa-7abf-4c92-ae97-063c75895db5
>>>>
>>>> I think they removed it now but they even had a automatically generated
>>>> section in their release notes with a list of people who ?contributed? by
>>>> reporting issues in JIRA that were fixed in the release. A way to attach
>>>> your users to your product I guess.
>>>>
>>>>
>>>> On 25 Feb 2016, at 11:24, Marek Posolda <mposolda at redhat.com> wrote:
>>>>
>>>> Maybe the best chance people won't miss it, is to put the note into
>>>> release announcement? Just something high level like "We changed location
>>>> of themes and did some other changes XYZ. Don't forget to read migration
>>>> guide for more details" or something like that?
>>>>
>>>> Marek
>>>>
>>>> On 25/02/16 10:28, Stian Thorgersen wrote:
>>>>
>>>> Bruno: No need to update theme chapter - Marc from APIMan is already on
>>>> the task :)
>>>>
>>>> "Before you get started" will that be read though? I can't see current
>>>> users reading that.
>>>>
>>>> On 25 February 2016 at 10:25, Bruno Oliveira <bruno at abstractj.org>
>>>> wrote:
>>>>
>>>>> I will review the whole theme chapter today and see if I find any
>>>>> mismatches.
>>>>>
>>>>> Regarding your question, I'd add a section in the very beginning of
>>>>> our guide called "Before you get started".
>>>>>
>>>>> On Thu, Feb 25, 2016 at 6:23 AM Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Any tips on how we can make it more obvious to users to read the
>>>>>> migration guide?
>>>>>>
>>>>>> On 25 February 2016 at 10:21, Edgar Vonk - Info.nl <http://info.nl> <
>>>>>> <Edgar at info.nl>Edgar at info.nl> wrote:
>>>>>>
>>>>>>> ok, thanks! you are right, I should have read the migration guide.
>>>>>>>
>>>>>>> On 25 Feb 2016, at 10:19, Stian Thorgersen < <sthorger at redhat.com>
>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>> Yes, it has moved. I forgot to update the themes doc, but it's
>>>>>>> included in the migration guide.
>>>>>>>
>>>>>>> Always read the migration guide before upgrading! It will quite
>>>>>>> likely save you a lot of time.
>>>>>>>
>>>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997
>>>>>>>
>>>>>>> On 25 February 2016 at 10:00, Thomas Darimont <
>>>>>>> <thomas.darimont at googlemail.com>thomas.darimont at googlemail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This was discussed a few days ago on the dev list:
>>>>>>>>
>>>>>>>> <http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html>
>>>>>>>> http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>>>>>>>>
>>>>>>>> Perhaphs there should have sent a mail to the user-list as well...
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>> 2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl <http://info.nl/> <
>>>>>>>> <Edgar at info.nl>Edgar at info.nl>:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> It seems that the themes folder has moved in Keycloak 1.9.0.Final
>>>>>>>>> (from 1.9.0.RC1)?
>>>>>>>>>
>>>>>>>>> The themes folder used to be:
>>>>>>>>> $KEYCLOAK_HOME/standalone/configuration/themes
>>>>>>>>>
>>>>>>>>> but now it seems to be:
>>>>>>>>> $KEYCLOAK_HOME/themes
>>>>>>>>>
>>>>>>>>> The documentation still mentions the old location so I think needs
>>>>>>>>> to be updated?
>>>>>>>>>
>>>>>>>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431>
>>>>>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>>>>>>>>
>>>>>>>>> cheers
>>>>>>>>>
>>>>>>>>> Edgar
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing list
>>>>>>>>> <keycloak-user at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://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/20160225/04dd68ff/attachment-0001.html 

From bburke at redhat.com  Thu Feb 25 09:46:20 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 25 Feb 2016 09:46:20 -0500
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <CAJgngAeZ6Jjc06N3hvbs0O-xSxwzuOWgzDYiwRVWgWrXKiyAbg@mail.gmail.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
	<CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
	<CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>
	<CAJgngAcJcNYF0vezwT0ctp0Hg3KQLvOFmXO9YEk=gxayz6xtzA@mail.gmail.com>
	<56CED673.5060201@redhat.com>
	<5300B1FC-4AF0-4A09-8B80-E874BD5E0998@info.nl>
	<CAJgngAeZ6Jjc06N3hvbs0O-xSxwzuOWgzDYiwRVWgWrXKiyAbg@mail.gmail.com>
Message-ID: <56CF13BC.30201@redhat.com>

Jira already generates "proper" release notes.  We still need the 
migration guide.

On 2/25/2016 6:05 AM, Stian Thorgersen wrote:
> What I'm going to do is:
>
> * Short term - start mentioning important migration issues in release 
> announcement and link to migration doc
> * Long term - start creating proper release notes and include in 
> documentation, release announcement in the future will just be 
> highlights and link to this
>
> Comments?
>
> On 25 February 2016 at 11:36, Edgar Vonk - Info.nl <Edgar at info.nl 
> <mailto:Edgar at info.nl>> wrote:
>
>     that would certainly help indeed!
>
>     as an example this is how Magnolia (a Java CMS we often use in our
>     projects) does it:
>     https://forums.magnolia-cms.com/forum/thread.html?threadId=5f23d559-16be-4637-b3a5-dcb8dddc24c1#41e491fa-7abf-4c92-ae97-063c75895db5
>
>     I think they removed it now but they even had a automatically
>     generated section in their release notes with a list of people who
>     ?contributed? by reporting issues in JIRA that were fixed in the
>     release. A way to attach your users to your product I guess.
>
>>     On 25 Feb 2016, at 11:24, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>     Maybe the best chance people won't miss it, is to put the note
>>     into release announcement? Just something high level like "We
>>     changed location of themes and did some other changes XYZ. Don't
>>     forget to read migration guide for more details" or something
>>     like that?
>>
>>     Marek
>>
>>     On 25/02/16 10:28, Stian Thorgersen wrote:
>>>     Bruno: No need to update theme chapter - Marc from APIMan is
>>>     already on the task :)
>>>
>>>     "Before you get started" will that be read though? I can't see
>>>     current users reading that.
>>>
>>>     On 25 February 2016 at 10:25, Bruno Oliveira
>>>     <bruno at abstractj.org <mailto:bruno at abstractj.org>> wrote:
>>>
>>>         I will review the whole theme chapter today and see if I
>>>         find any mismatches.
>>>
>>>         Regarding your question, I'd add a section in the very
>>>         beginning of our guide called "Before you get started".
>>>
>>>         On Thu, Feb 25, 2016 at 6:23 AM Stian Thorgersen
>>>         <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>
>>>             Any tips on how we can make it more obvious to users to
>>>             read the migration guide?
>>>
>>>             On 25 February 2016 at 10:21, Edgar Vonk - Info.nl
>>>             <http://info.nl> <Edgar at info.nl <mailto:Edgar at info.nl>>
>>>             wrote:
>>>
>>>                 ok, thanks! you are right, I should have read the
>>>                 migration guide.
>>>
>>>>                 On 25 Feb 2016, at 10:19, Stian Thorgersen
>>>>                 <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>>>                 wrote:
>>>>
>>>>                 Yes, it has moved. I forgot to update the themes
>>>>                 doc, but it's included in the migration guide.
>>>>
>>>>                 Always read the migration guide before upgrading!
>>>>                 It will quite likely save you a lot of time.
>>>>                 http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997
>>>>
>>>>                 On 25 February 2016 at 10:00, Thomas Darimont
>>>>                 <thomas.darimont at googlemail.com
>>>>                 <mailto:thomas.darimont at googlemail.com>> wrote:
>>>>
>>>>                     This was discussed a few days ago on the dev list:
>>>>                     http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>>>>
>>>>                     Perhaphs there should have sent a mail to the
>>>>                     user-list as well...
>>>>
>>>>                     Cheers,
>>>>                     Thomas
>>>>
>>>>                     2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl
>>>>                     <http://info.nl/> <Edgar at info.nl
>>>>                     <mailto:Edgar at info.nl>>:
>>>>
>>>>                         Hi,
>>>>
>>>>                         It seems that the themes folder has moved
>>>>                         in Keycloak 1.9.0.Final (from 1.9.0.RC1)?
>>>>
>>>>                         The themes folder used to be:
>>>>                         $KEYCLOAK_HOME/standalone/configuration/themes
>>>>
>>>>                         but now it seems to be:
>>>>                         $KEYCLOAK_HOME/themes
>>>>
>>>>                         The documentation still mentions the old
>>>>                         location so I think needs to be updated?
>>>>                         http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>>>
>>>>                         cheers
>>>>
>>>>                         Edgar
>>>>                         _______________________________________________
>>>>                         keycloak-user mailing list
>>>>                         keycloak-user at lists.jboss.org
>>>>                         <mailto:keycloak-user at lists.jboss.org>
>>>>                         https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>>
>>>>                     _______________________________________________
>>>>                     keycloak-user mailing list
>>>>                     keycloak-user at lists.jboss.org
>>>>                     <mailto:keycloak-user at lists.jboss.org>
>>>>                     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>
>>>
>>>             _______________________________________________
>>>             keycloak-user mailing list
>>>             keycloak-user at lists.jboss.org
>>>             <mailto:keycloak-user at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     keycloak-user mailing list
>>>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/0e54acc7/attachment-0001.html 

From sthorger at redhat.com  Thu Feb 25 10:04:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 25 Feb 2016 16:04:16 +0100
Subject: [keycloak-user] Themes folder has moved in Keycloak 1.9.0.Final?
In-Reply-To: <56CF13BC.30201@redhat.com>
References: <99AA3915-07CB-4598-B982-2C6BF0CF4A09@info.nl>
	<CAK-7U1gQhB9-Kpu6fogA05z3J2XCDwF4tAQdL_4=7rw4n+rhzw@mail.gmail.com>
	<CAJgngAfRbiQhEteC1W0svtkeLRRHfYJfbgRXLrU4iPy6OCri-Q@mail.gmail.com>
	<B25B695E-A13A-4592-9CF8-F68EB2C223EF@info.nl>
	<CAJgngAfRW1bguhkae_c0BWt6JmYbV8BwWTFq+JnW-xTQw98xhw@mail.gmail.com>
	<CAM5SUC42bzEo9yg6RYSM6EMsUqQyWH266dFcs_z+HhA0jb5U=A@mail.gmail.com>
	<CAJgngAcJcNYF0vezwT0ctp0Hg3KQLvOFmXO9YEk=gxayz6xtzA@mail.gmail.com>
	<56CED673.5060201@redhat.com>
	<5300B1FC-4AF0-4A09-8B80-E874BD5E0998@info.nl>
	<CAJgngAeZ6Jjc06N3hvbs0O-xSxwzuOWgzDYiwRVWgWrXKiyAbg@mail.gmail.com>
	<56CF13BC.30201@redhat.com>
Message-ID: <CAJgngAc6mKvs88xub1EU1AMpenpo2OVKQP5sf2E5-EJ-3sWr9Q@mail.gmail.com>

JIRA generates a lot of stuff. It's worth creating a quick list of what new
features and significant changes that where done in a release.

No one suggested removing the migration guide.

On 25 February 2016 at 15:46, Bill Burke <bburke at redhat.com> wrote:

> Jira already generates "proper" release notes.  We still need the
> migration guide.
>
>
> On 2/25/2016 6:05 AM, Stian Thorgersen wrote:
>
> What I'm going to do is:
>
> * Short term - start mentioning important migration issues in release
> announcement and link to migration doc
> * Long term - start creating proper release notes and include in
> documentation, release announcement in the future will just be highlights
> and link to this
>
> Comments?
>
> On 25 February 2016 at 11:36, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:
>
>> that would certainly help indeed!
>>
>> as an example this is how Magnolia (a Java CMS we often use in our
>> projects) does it:
>>
>> https://forums.magnolia-cms.com/forum/thread.html?threadId=5f23d559-16be-4637-b3a5-dcb8dddc24c1#41e491fa-7abf-4c92-ae97-063c75895db5
>>
>> I think they removed it now but they even had a automatically generated
>> section in their release notes with a list of people who ?contributed? by
>> reporting issues in JIRA that were fixed in the release. A way to attach
>> your users to your product I guess.
>>
>>
>> On 25 Feb 2016, at 11:24, Marek Posolda <mposolda at redhat.com> wrote:
>>
>> Maybe the best chance people won't miss it, is to put the note into
>> release announcement? Just something high level like "We changed location
>> of themes and did some other changes XYZ. Don't forget to read migration
>> guide for more details" or something like that?
>>
>> Marek
>>
>> On 25/02/16 10:28, Stian Thorgersen wrote:
>>
>> Bruno: No need to update theme chapter - Marc from APIMan is already on
>> the task :)
>>
>> "Before you get started" will that be read though? I can't see current
>> users reading that.
>>
>> On 25 February 2016 at 10:25, Bruno Oliveira <bruno at abstractj.org> wrote:
>>
>>> I will review the whole theme chapter today and see if I find any
>>> mismatches.
>>>
>>> Regarding your question, I'd add a section in the very beginning of our
>>> guide called "Before you get started".
>>>
>>> On Thu, Feb 25, 2016 at 6:23 AM Stian Thorgersen < <sthorger at redhat.com>
>>> sthorger at redhat.com> wrote:
>>>
>>>> Any tips on how we can make it more obvious to users to read the
>>>> migration guide?
>>>>
>>>> On 25 February 2016 at 10:21, Edgar Vonk - Info.nl <http://info.nl> <
>>>> <Edgar at info.nl>Edgar at info.nl> wrote:
>>>>
>>>>> ok, thanks! you are right, I should have read the migration guide.
>>>>>
>>>>> On 25 Feb 2016, at 10:19, Stian Thorgersen < <sthorger at redhat.com>
>>>>> sthorger at redhat.com> wrote:
>>>>>
>>>>> Yes, it has moved. I forgot to update the themes doc, but it's
>>>>> included in the migration guide.
>>>>>
>>>>> Always read the migration guide before upgrading! It will quite likely
>>>>> save you a lot of time.
>>>>>
>>>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997>
>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e3997
>>>>>
>>>>> On 25 February 2016 at 10:00, Thomas Darimont <
>>>>> <thomas.darimont at googlemail.com>thomas.darimont at googlemail.com> wrote:
>>>>>
>>>>>> This was discussed a few days ago on the dev list:
>>>>>>
>>>>>> <http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html>
>>>>>> http://lists.jboss.org/pipermail/keycloak-dev/2016-February/006638.html
>>>>>>
>>>>>> Perhaphs there should have sent a mail to the user-list as well...
>>>>>>
>>>>>> Cheers,
>>>>>> Thomas
>>>>>>
>>>>>> 2016-02-25 9:31 GMT+01:00 Edgar Vonk - Info.nl <http://info.nl/> <
>>>>>> <Edgar at info.nl>Edgar at info.nl>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> It seems that the themes folder has moved in Keycloak 1.9.0.Final
>>>>>>> (from 1.9.0.RC1)?
>>>>>>>
>>>>>>> The themes folder used to be:
>>>>>>> $KEYCLOAK_HOME/standalone/configuration/themes
>>>>>>>
>>>>>>> but now it seems to be:
>>>>>>> $KEYCLOAK_HOME/themes
>>>>>>>
>>>>>>> The documentation still mentions the old location so I think needs
>>>>>>> to be updated?
>>>>>>>
>>>>>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431>
>>>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html#d4e2431
>>>>>>>
>>>>>>> cheers
>>>>>>>
>>>>>>> Edgar
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> <keycloak-user at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> <keycloak-user at lists.jboss.org>keycloak-user at lists.jboss.org
>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>>> 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 listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>>
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160225/57315c33/attachment-0001.html 

From RLewis at carbonite.com  Thu Feb 25 10:44:03 2016
From: RLewis at carbonite.com (Reed Lewis)
Date: Thu, 25 Feb 2016 15:44:03 +0000
Subject: [keycloak-user] Additional additional parameters and processing them
Message-ID: <B8F15415-5872-4572-8105-5DF739FE56A6@carbonite.com>

First, I want to thank all the Keycloak developers for your great help.   This is by far one of the best supported and documented open source products I have used in a long time.

My next question:

Say I have the redirect to login using the following URI:


https://<server>/auth/realms/<realm>/protocol/openid-connect/auth?response_type=code&client_id=broker&redirect_uri=http://localhost:5000/oauth2callback&scope=offline_access&nonce=fa7757e5-697c-4f3a-9760-610a6d19893b-d5c888df-3dd3-4a06-8ea0-7525fc9894de


And I wish to add additional parameters to the request which I can put into the JWT, or use the values as session attributes or the like.


How do I do that?


Thank you,


Reed Lewis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/9ff68bd7/attachment.html 

From rsang at carelogistics.com  Thu Feb 25 10:50:20 2016
From: rsang at carelogistics.com (Rong Sang (CL-ATL))
Date: Thu, 25 Feb 2016 15:50:20 +0000
Subject: [keycloak-user] "Client was not identified by any client
	authenticator"
Message-ID: <BB71CD86-F37E-4E6B-AF23-9A6FE69B85C9@carelogistics.com>

Hi,

I just downloaded the 1.9.0 final release, started the standalone server, created the initial admin user account and then tried to log in the admin console. I got the following error at that point:

Failed client authentication: org.keycloak.authentication.AuthenticationFlowException: Client was not identified by any client authenticator

The web page kept loading and the server had a lot of instance of the error above. I couldn?t go any further. What did I miss?

Thanks,

Rong


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160225/9d403d71/attachment.html 

From siva.b at knowledgeflux.com  Thu Feb 25 20:01:15 2016
From: siva.b at knowledgeflux.com (Siva)
Date: Fri, 26 Feb 2016 11:01:15 +1000
Subject: [keycloak-user] REST(MicroServices) authentication through SAML 2.0
Message-ID: <15a24101d17031$35c052c0$a140f840$@knowledgeflux.com>

Hi Experts,

 

I've got scenario, seeking your valuable inputs to take this in right
direction.

 

My application is complete server side solution which has 6 different
modules and it expose only the REST(Microservices) end points(5 modules are
hosted in tomcat 8 container and 1 is hosted in Apache Karaf [OSGI bundle] )
to the external world ; which will be accessed by different enterprise and
they need to integrate their SAML 2.0 IDP for authentication. 

 

These Microservices end points could be integrated with their existing
portals or could be integrated with their existing mobile app applications,
in some scenario's it could be an exclusive client application built to
consume our REST end points which could potentially be a browser based and
Mobile app.

 

The challenge here is, for now we could use only SAML 2.0 based
authentication since not all the organizations support OIDC/OAuth2.0 and as
well our application could be flexible enough to be integrated with the
existing client portals which uses SAML 2.0 authentication.

 

We are planning to use keycloak as IDP broker to secure our endpoints.

 

Questions :

 

1)      Can this be achieved in keycloak? If yes, could you please provide
some inputs on architectural directions in keycloak; like should all the
modules need to be configured under 1 relam and need to have a separate
brokering relam?

2)      Does keycloak support Apache karaf container? I couldn't find any
adapter for this under SAML adapter category.

3)      For REST style endpoints, how should the user credential/Token
details need to shared? Any example links? kerberos is not a complete
solution here, since it need to work on all the devices(Desktop,Laptop &
handheld). 

4)      For the REST based solution, can the application completely rely on
keycloak for the session management, after the first time the user is
authenticated? 

 

Any inputs on this will be highly valued.

 

Regards,

Siva.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/27339b62/attachment.html 

From mposolda at redhat.com  Fri Feb 26 00:26:16 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 26 Feb 2016 06:26:16 +0100
Subject: [keycloak-user] "Client was not identified by any client
 authenticator"
In-Reply-To: <BB71CD86-F37E-4E6B-AF23-9A6FE69B85C9@carelogistics.com>
References: <BB71CD86-F37E-4E6B-AF23-9A6FE69B85C9@carelogistics.com>
Message-ID: <56CFE1F8.5090200@redhat.com>

Were there any other exceptions in server.log at startup? Did you 
migrate from previous version or started from clean DB? If migrated from 
previous version, could you try with clean DB?

Thanks,
Marek

On 25/02/16 16:50, Rong Sang (CL-ATL) wrote:
> Hi,
>
> I just downloaded the 1.9.0 final release, started the standalone 
> server, created the initial admin user account and then tried to log 
> in the admin console. I got the following error at that point:
>
> Failed client authentication: 
> org.keycloak.authentication.AuthenticationFlowException: Client was 
> not identified by any client authenticator
>
> The web page kept loading and the server had a lot of instance of the 
> error above. I couldn?t go any further. What did I miss?
>
> Thanks,
>
> Rong
>
>
>
>
> _______________________________________________
> 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/20160226/d77a3cc9/attachment-0001.html 

From mposolda at redhat.com  Fri Feb 26 00:35:46 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 26 Feb 2016 06:35:46 +0100
Subject: [keycloak-user] Additional additional parameters and processing
 them
In-Reply-To: <B8F15415-5872-4572-8105-5DF739FE56A6@carbonite.com>
References: <B8F15415-5872-4572-8105-5DF739FE56A6@carbonite.com>
Message-ID: <56CFE432.7050103@redhat.com>

Hi,

On 25/02/16 16:44, Reed Lewis wrote:
> First, I want to thank all the Keycloak developers for your great 
> help.   This is by far one of the best supported and documented open 
> source products I have used in a long time.
>
> My next question:
>
> Say I have the redirect to login using the following URI:
>
>
> https://<server>/auth/realms/<realm>/protocol/openid-connect/auth?response_type=code&client_id=broker&redirect_uri=http://localhost:5000/oauth2callback&scope=offline_access&nonce=fa7757e5-697c-4f3a-9760-610a6d19893b-d5c888df-3dd3-4a06-8ea0-7525fc9894de
>
Keycloak understands just OIDC related parameters, which are send to 
this endpoint. However if you mean to add additional parameters to 
redirectUri, you can do that. You can create protocol mapper to put some 
custom claims into JWT. The value of redirectUri parameter is available 
as clientSession note in Keycloak, so you can theoretically parse it and 
put some claims into JWT based on that.

Marek
>
>
> And I wish to add additional parameters to the request which I can put 
> into the JWT, or use the values as session attributes or the like.
>
>
> How do I do that?
>
>
> Thank you,
>
>
> Reed Lewis
>
>
>
>
> _______________________________________________
> 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/20160226/cd097bbb/attachment.html 

From Edgar at info.nl  Fri Feb 26 04:42:11 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Fri, 26 Feb 2016 09:42:11 +0000
Subject: [keycloak-user] Change the default max nr of users shown in the
 users overview screen in the base Keycloak admin theme?
Message-ID: <4D4470CE-31F4-445C-BB01-CBF923687D65@info.nl>

Hi,

I was wondering if there would be an objection to change the default max number of users shown in the users overview screen in the base Keycloak admin theme? Manage - Users now shows a maximum number of 5 users per ?page?. I think this is really low and hard to work with if, like us, you will have thousands of users in the system. We would like to have this default max number set to something, which I think seems more sensible, like 20.

It is set in the users.js JS (UserListCtrl) in the base Keycloak admin theme so I know that we can override this file and set our own default but we really do not want to do this as we want to use the default Keycloak admin console at this stage.

Ok if I create a JIRA feature request issue for this?

cheers

Edgar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/f97e1ede/attachment.bin 

From Matthias_Mueller at tu-dresden.de  Fri Feb 26 06:53:02 2016
From: Matthias_Mueller at tu-dresden.de (=?UTF-8?Q?Matthias_M=c3=bcller?=)
Date: Fri, 26 Feb 2016 12:53:02 +0100
Subject: [keycloak-user] Keycloak 1.9 behind Apache2 reverse proxy not
	working properly
Message-ID: <56D03C9E.3000004@tu-dresden.de>

Does anyone have experiences with Keycloak 1.9 in an Apache2 reverse 
proxy configuration?

In my test setup I am running Keycloak as a standalone service on port 
8080. It is proxied behind an Apache HTTP Server that manages the SSL 
communication and forwards requests to localhost:8080. The Apache side 
of the proxy is working. However, the administration console web page 
(auth/admin/master/console/) still contains plain http://... links 
(should be: https://) to the JS components which, of course, is invalid. 
Obviously the Keycloak service does not see (or ignores) the X-Forwarded 
headers.

Am I missing something here?

Cheers,
Matthias

[1]: 
http://auth.domain.org/auth/resources/1.9.0.final/admin/keycloak/lib/select2-3.4.1/select2.js

From sthorger at redhat.com  Fri Feb 26 07:36:28 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 26 Feb 2016 13:36:28 +0100
Subject: [keycloak-user] Keycloak 1.9 behind Apache2 reverse proxy not
 working properly
In-Reply-To: <56D03C9E.3000004@tu-dresden.de>
References: <56D03C9E.3000004@tu-dresden.de>
Message-ID: <CAJgngAcLCi1Th+XA8MbH1aRVxMnaEec-U2toRyBD7Yy165y8vg@mail.gmail.com>

DId you follow documentation at
http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e394

On 26 February 2016 at 12:53, Matthias M?ller <
Matthias_Mueller at tu-dresden.de> wrote:

> Does anyone have experiences with Keycloak 1.9 in an Apache2 reverse
> proxy configuration?
>
> In my test setup I am running Keycloak as a standalone service on port
> 8080. It is proxied behind an Apache HTTP Server that manages the SSL
> communication and forwards requests to localhost:8080. The Apache side
> of the proxy is working. However, the administration console web page
> (auth/admin/master/console/) still contains plain http://... links
> (should be: https://) to the JS components which, of course, is invalid.
> Obviously the Keycloak service does not see (or ignores) the X-Forwarded
> headers.
>
> Am I missing something here?
>
> Cheers,
> Matthias
>
> [1]:
>
> http://auth.domain.org/auth/resources/1.9.0.final/admin/keycloak/lib/select2-3.4.1/select2.js
> _______________________________________________
> 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/20160226/98ccefe4/attachment.html 

From sthorger at redhat.com  Fri Feb 26 07:37:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 26 Feb 2016 13:37:49 +0100
Subject: [keycloak-user] Change the default max nr of users shown in the
 users overview screen in the base Keycloak admin theme?
In-Reply-To: <4D4470CE-31F4-445C-BB01-CBF923687D65@info.nl>
References: <4D4470CE-31F4-445C-BB01-CBF923687D65@info.nl>
Message-ID: <CAJgngAdXg7rQh6PKfnEq72FeHWqOCm_ETXFrWAyZ0fzupvq2pQ@mail.gmail.com>

We have scheduled this work. It's going to be part of updating tables to
align with PatternFly recommendations. See
https://issues.jboss.org/browse/KEYCLOAK-1429

On 26 February 2016 at 10:42, Edgar Vonk - Info.nl <Edgar at info.nl> wrote:

> Hi,
>
> I was wondering if there would be an objection to change the default max
> number of users shown in the users overview screen in the base Keycloak
> admin theme? Manage - Users now shows a maximum number of 5 users per
> ?page?. I think this is really low and hard to work with if, like us, you
> will have thousands of users in the system. We would like to have this
> default max number set to something, which I think seems more sensible,
> like 20.
>
> It is set in the users.js JS (UserListCtrl) in the base Keycloak admin
> theme so I know that we can override this file and set our own default but
> we really do not want to do this as we want to use the default Keycloak
> admin console at this stage.
>
> Ok if I create a JIRA feature request issue for this?
>
> cheers
>
> Edgar
>
> _______________________________________________
> 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/20160226/4b84a6f9/attachment.html 

From srossillo at smartling.com  Fri Feb 26 08:30:03 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Fri, 26 Feb 2016 13:30:03 +0000
Subject: [keycloak-user] Keycloak starting before Infinispan jndi ready?
Message-ID: <CALAqdu-fswbi8w3KhG5AQH2dmRgAqDO3fE6=8oXXSQRbMmfCFA@mail.gmail.com>

Has anyone else has a random issue where Keycloak code is started before
Inifinspan subsystem is ready? Even with the cache declared eager?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/1ab47f56/attachment-0001.html 

From psilva at redhat.com  Fri Feb 26 08:45:03 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 26 Feb 2016 08:45:03 -0500 (EST)
Subject: [keycloak-user] REST(MicroServices) authentication through SAML
 2.0
In-Reply-To: <15a24101d17031$35c052c0$a140f840$@knowledgeflux.com>
References: <15a24101d17031$35c052c0$a140f840$@knowledgeflux.com>
Message-ID: <330317876.30771350.1456494303748.JavaMail.zimbra@redhat.com>

Hi Siva, 

    Some comments inline.


----- Original Message -----
> From: "Siva" <siva.b at knowledgeflux.com>
> To: keycloak-user at lists.jboss.org
> Sent: Thursday, February 25, 2016 10:01:15 PM
> Subject: [keycloak-user] REST(MicroServices) authentication through SAML 2.0
> 
> 
> 
> Hi Experts,
> 
> 
> 
> I?ve got scenario, seeking your valuable inputs to take this in right
> direction.
> 
> 
> 
> My application is complete server side solution which has 6 different modules
> and it expose only the REST(Microservices) end points(5 modules are hosted
> in tomcat 8 container and 1 is hosted in Apache Karaf [OSGI bundle] ) to the
> external world ; which will be accessed by different enterprise and they
> need to integrate their SAML 2.0 IDP for authentication.
> 
> 
> 
> These Microservices end points could be integrated with their existing
> portals or could be integrated with their existing mobile app applications,
> in some scenario?s it could be an exclusive client application built to
> consume our REST end points which could potentially be a browser based and
> Mobile app.
> 
> 
> 
> The challenge here is, for now we could use only SAML 2.0 based
> authentication since not all the organizations support OIDC/OAuth2.0 and as
> well our application could be flexible enough to be integrated with the
> existing client portals which uses SAML 2.0 authentication.
> 
> 
> 
> We are planning to use keycloak as IDP broker to secure our endpoints.
> 
> 
> 
> Questions :
> 
> 
> 
> 1) Can this be achieved in keycloak? If yes, could you please provide some
> inputs on architectural directions in keycloak; like should all the modules
> need to be configured under 1 relam and need to have a separate brokering
> relam?

I don't think that brokering is the best solution to address your requirements. If I understood your problem correctly, the clients trying to access your APIs belong to your partners and not you. Brokering is useful when you own the clients and want to create an indirection layer in order to integrate with external identity providers (pretty much the inverse of your use case). Or even during a migration plan when you already have some investments on SAML and want to gradually adopt OpenID Connect for new deployments.

In your case, what you need is something that can utilize an existing trust relationship in order to give to your clients the proper security token to access your APIs.

> 
> 2) Does keycloak support Apache karaf container? I couldn?t find any adapter
> for this under SAML adapter category.

I don't think so, but someone can give you more input on that.

> 
> 3) For REST style endpoints, how should the user credential/Token details
> need to shared? Any example links? kerberos is not a complete solution here,
> since it need to work on all the devices(Desktop,Laptop & handheld).

Well, there is no sharing of user credentials, but security tokens.

> 
> 4) For the REST based solution, can the application completely rely on
> keycloak for the session management, after the first time the user is
> authenticated?
> 
> 
> 
> Any inputs on this will be highly valued.
>

An interesting solution would be the Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants [1]. Very useful when a client wishes to utilize an existing trust relationship, expressed through the semantics of the SAML Assertion, without a direct user approval step at the authorization server.

But, IIRC, that spec is not yet supported in KC.

I've also seem some people using SAML assertions to access RESTful resources. Personally, I don't think it is a good approach, since there is no SAML binding (standard) targeting RESTful resources.

There is also the SAML ECP profile, which we added recently. However, it is targeted for specific use cases where you need to issue a SAML Assertion based on some user credentials (so you must own the users, not your case I think). It also provides some very basic support for the SP side of things, but I don't think it can help you either.

[1] https://tools.ietf.org/html/rfc7522

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


From sthorger at redhat.com  Fri Feb 26 08:46:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 26 Feb 2016 14:46:47 +0100
Subject: [keycloak-user] Keycloak starting before Infinispan jndi ready?
In-Reply-To: <CALAqdu-fswbi8w3KhG5AQH2dmRgAqDO3fE6=8oXXSQRbMmfCFA@mail.gmail.com>
References: <CALAqdu-fswbi8w3KhG5AQH2dmRgAqDO3fE6=8oXXSQRbMmfCFA@mail.gmail.com>
Message-ID: <CAJgngAdLp3L5nXi+RGz_5uwnM081xWRrB8wZpqRzBw=XbokuPQ@mail.gmail.com>

What cache and what version of Keycloak?

The eager flag was removed from the Infinispan subsystem in WF9, so we
added a dependency at the MSC level (WF subsystem stuff) to make sure the
caches are ready before Keycloak starts.

On 26 February 2016 at 14:30, Scott Rossillo <srossillo at smartling.com>
wrote:

> Has anyone else has a random issue where Keycloak code is started before
> Inifinspan subsystem is ready? Even with the cache declared eager?
>
> _______________________________________________
> 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/20160226/7e92de07/attachment.html 

From matthias_mueller at tu-dresden.de  Fri Feb 26 08:54:42 2016
From: matthias_mueller at tu-dresden.de (=?UTF-8?Q?Matthias_M=C3=BCller?=)
Date: Fri, 26 Feb 2016 14:54:42 +0100
Subject: [keycloak-user] Keycloak 1.9 behind Apache2 reverse proxy not
	working properly
In-Reply-To: <CAJgngAcLCi1Th+XA8MbH1aRVxMnaEec-U2toRyBD7Yy165y8vg@mail.gmail.com>
References: <56D03C9E.3000004@tu-dresden.de>
	<CAJgngAcLCi1Th+XA8MbH1aRVxMnaEec-U2toRyBD7Yy165y8vg@mail.gmail.com>
Message-ID: <004e01d1709d$3ec43f00$bc4cbd00$@tu-dresden.de>

Yes. I?ve set up an HTTPS reverse proxy in Apache as usual with and added the required header:

 

RequestHeader set X-Forwarded-Proto "https" env=HTTPS

 

Then I edited /usr/local/keycloak/standalone/configuration/standalone.xml according to these instructions.

 

>From what I?ve seen there?s no difference in the responses between:

 

a)      Configuring reverse proxy in Apache only

b)      Configuring reverse proxy in Apache AND editing standalone.xml

 

In both cases the hostname is properly resolved, but not the protocol part.

 

Cheers,

Matthias

 

p.s.: The documentation shows a configuration for an old release (1.1) of the undertow subsystem. Current is 3.0, which is also part of Keycloak distro. Is the configuration identical for both versions?

 

 

From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
Sent: Friday, February 26, 2016 1:36 PM
To: Matthias M?ller
Cc: keycloak-user
Subject: Re: [keycloak-user] Keycloak 1.9 behind Apache2 reverse proxy not working properly

 

DId you follow documentation at http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e394

 

On 26 February 2016 at 12:53, Matthias M?ller <Matthias_Mueller at tu-dresden.de> wrote:

Does anyone have experiences with Keycloak 1.9 in an Apache2 reverse
proxy configuration?

In my test setup I am running Keycloak as a standalone service on port
8080. It is proxied behind an Apache HTTP Server that manages the SSL
communication and forwards requests to localhost:8080. The Apache side
of the proxy is working. However, the administration console web page
(auth/admin/master/console/) still contains plain http://... links
(should be: https://) to the JS components which, of course, is invalid.
Obviously the Keycloak service does not see (or ignores) the X-Forwarded
headers.

Am I missing something here?

Cheers,
Matthias

[1]:
http://auth.domain.org/auth/resources/1.9.0.final/admin/keycloak/lib/select2-3.4.1/select2.js
_______________________________________________
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/20160226/1242b76e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6116 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/1242b76e/attachment-0001.bin 

From bbazian at mbopartners.com  Fri Feb 26 09:38:46 2016
From: bbazian at mbopartners.com (Ben Bazian)
Date: Fri, 26 Feb 2016 14:38:46 +0000
Subject: [keycloak-user] SAML issue
Message-ID: <860E8DAFFC76794694CFF405F8A1E71F02AA2ABC@416429-EXCH1.mbopartners.com>

I am having an issue with setting up a SAML connection.  Here are the screens.  When I try to do an IDP initiated login,

https://sso2-dev.mbopartners.com/realms/dev/protocol/saml/clients/timeoffmanager

I am getting a 404 error.

If I do an SP initiated at https://www.timeoffmanager.com/cpanel/sso/?id=MB41115 I get an invalid request error.  It is not picking up the clientid.



21:32:15,253 WARN  [org.keycloak.events] (default task-16) type=LOGIN_ERROR, realmId=(removed by me), clientId=null, userId=null, ipAddress=10.7.3.154, error=invalid_token



I also tried to make the Valid Redirect URI to be https://www.timeoffmanager.com/*



What have I missed?  Any help is appreciated.



[cid:image001.png at 01D16FEA.C198EBF0]



Here is the SP's setup.



[cid:image003.png at 01D17079.7B1D3340]

[cid:image004.png at 01D17079.7B1D3340]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/43371153/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 71474 bytes
Desc: image001.png
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/43371153/attachment-0003.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 14895 bytes
Desc: image003.png
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/43371153/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 18407 bytes
Desc: image004.png
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/43371153/attachment-0005.png 

From rsang at carelogistics.com  Fri Feb 26 09:42:16 2016
From: rsang at carelogistics.com (Rong Sang (CL-ATL))
Date: Fri, 26 Feb 2016 14:42:16 +0000
Subject: [keycloak-user] "Client was not identified by any client
 authenticator"
In-Reply-To: <56CFE1F8.5090200@redhat.com>
References: <BB71CD86-F37E-4E6B-AF23-9A6FE69B85C9@carelogistics.com>
	<56CFE1F8.5090200@redhat.com>
Message-ID: <33C997F9-AEB6-409C-9551-F4B8CAD872A9@carelogistics.com>

Hi Marek,

That?s the first error I found in the server.log. There were many instances of the same error. I didn?t find any other error.

I was testing the product on a mac. It was a clean install, no migration. I didn?t configure SSL. According to 1.9.0 documents, it should work with localhost. The only configuration I did was creating the initial admin user.

Thanks,

Rong

From: Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>>
Date: Friday, February 26, 2016 at 12:26 AM
To: rongsang <rsang at carelogistics.com<mailto:rsang at carelogistics.com>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] "Client was not identified by any client authenticator"

Were there any other exceptions in server.log at startup? Did you migrate from previous version or started from clean DB? If migrated from previous version, could you try with clean DB?

Thanks,
Marek

On 25/02/16 16:50, Rong Sang (CL-ATL) wrote:
Hi,

I just downloaded the 1.9.0 final release, started the standalone server, created the initial admin user account and then tried to log in the admin console. I got the following error at that point:

Failed client authentication: org.keycloak.authentication.AuthenticationFlowException: Client was not identified by any client authenticator

The web page kept loading and the server had a lot of instance of the error above. I couldn?t go any further. What did I miss?

Thanks,

Rong





_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/keycloak-user<http://cp.mcafee.com/d/avndxMwcy1J5xZNxNxAsqejtPqdPhO-OOZtAsrhhhjpKUyYOrhKqenSmnHIL6QkkkSkknDSjsqr0y2Hr7PWApkDaRendSSfDR8OFelGsKr8eE-XpN_HYevKehu7tuVteVEVuV5xZAQsCzBdXG8FHnjlKUzOEuvkzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxYGjFMygHiD00s4RtxxYGjB1SK5vbmfHFkKTjUCRlGQGuxEazW1fpYKrod7bXxI5-Aq83iSlYJo-KBiXtfyqnjh0q8x8-nMCq836Qd44aPd44AfxejILgd410Iq8dwmd45zVv2pEwRKpfUjBrpRyq8zoVYTOmewtduNP0J>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/890b2b42/attachment.html 

From bbazian at mbopartners.com  Fri Feb 26 10:32:45 2016
From: bbazian at mbopartners.com (Ben Bazian)
Date: Fri, 26 Feb 2016 15:32:45 +0000
Subject: [keycloak-user] SAML question
Message-ID: <860E8DAFFC76794694CFF405F8A1E71F02AA332B@416429-EXCH1.mbopartners.com>

I need to add Active Directory attributes to the SAML assertion.  Is there documentation on how to do this?  Specifically I need to add givenName and sn to the assertion that already has the email attribute.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/299377b6/attachment.html 

From glaissard at axway.com  Fri Feb 26 11:03:59 2016
From: glaissard at axway.com (Gerard Laissard)
Date: Fri, 26 Feb 2016 16:03:59 +0000
Subject: [keycloak-user] user Attribute error
Message-ID: <4AC8C602867B3A4CB6F9F6BA4528DEE477B45E2F@WPHXMAIL1.phx.axway.int>

Hi,

I'm using user Federation LDAP. The LDAP is read-only.
When I add a user Attribute, I get 'Error! user is read-only!'

How can I add specific user attributes?

Thanks
Gerard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/792cb0bd/attachment.html 

From srossillo at smartling.com  Fri Feb 26 11:26:12 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Fri, 26 Feb 2016 16:26:12 +0000
Subject: [keycloak-user] Keycloak starting before Infinispan jndi ready?
In-Reply-To: <CAJgngAdLp3L5nXi+RGz_5uwnM081xWRrB8wZpqRzBw=XbokuPQ@mail.gmail.com>
References: <CALAqdu-fswbi8w3KhG5AQH2dmRgAqDO3fE6=8oXXSQRbMmfCFA@mail.gmail.com>
	<CAJgngAdLp3L5nXi+RGz_5uwnM081xWRrB8wZpqRzBw=XbokuPQ@mail.gmail.com>
Message-ID: <CALAqdu-FhhFPEYetXP1GZPv2Viq=dW6XkHBagwgPbpYddffo6g@mail.gmail.com>

Wildfly 8. Keycloak 1.2.0.
On Fri, Feb 26, 2016 at 8:46 AM Stian Thorgersen <sthorger at redhat.com>
wrote:

> What cache and what version of Keycloak?
>
> The eager flag was removed from the Infinispan subsystem in WF9, so we
> added a dependency at the MSC level (WF subsystem stuff) to make sure the
> caches are ready before Keycloak starts.
>
> On 26 February 2016 at 14:30, Scott Rossillo <srossillo at smartling.com>
> wrote:
>
>> Has anyone else has a random issue where Keycloak code is started before
>> Inifinspan subsystem is ready? Even with the cache declared eager?
>>
>> _______________________________________________
>> 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/20160226/0b394b52/attachment.html 

From RLewis at carbonite.com  Fri Feb 26 12:49:33 2016
From: RLewis at carbonite.com (Reed Lewis)
Date: Fri, 26 Feb 2016 17:49:33 +0000
Subject: [keycloak-user] Client Mappers. Can I define mappers
 programmatically?
In-Reply-To: <CAK-7U1gJ=7H9ULu90fRTK0wEBObKL_Dzmcco-50KmVd7gL7a1g@mail.gmail.com>
References: <2697F06A-E3A8-408E-B949-AC25194BFAD9@carbonite.com>
	<CAK-7U1gJ=7H9ULu90fRTK0wEBObKL_Dzmcco-50KmVd7gL7a1g@mail.gmail.com>
Message-ID: <56AE8D52-DEB6-4000-BF2B-600124C4AE3C@carbonite.com>

Can someone provide (if there is one out there) of an example of adding an additional OIDC mapper to Keycloak?   I have tried to compile and load a module to add an additional mapper, and cannot seem to get it working.   My new mapper does not appear as a choice for modifying the clJWT claim.

Or do I need to add it to the main source tree and recompile the whole Keycloak project?

Thanks,

Reed

From: Thomas Darimont <thomas.darimont at googlemail.com<mailto:thomas.darimont at googlemail.com>>
Date: Wednesday, February 24, 2016 at 4:31 PM
To: Reed Lewis <RLewis at carbonite.com<mailto:RLewis at carbonite.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Client Mappers. Can I define mappers programmatically?

Hello Reed,

yes you should be able to do that via the:
org.keycloak.protocol.ProtocolMapperSpi

You can provide your own org.keycloak.protocol.ProtocolMapper
(org.keycloak.protocol.oidc.mappers.OIDCAccessTokenMapper) to introduce
computed attributes to the access tokens.

You can find the predefined mappers in the package:
org/keycloak/protocol/oidc/mappers within the keycloak-services project.

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/95bd89d0/attachment-0001.html 

From mposolda at redhat.com  Fri Feb 26 15:10:55 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 26 Feb 2016 21:10:55 +0100
Subject: [keycloak-user] "Client was not identified by any client
 authenticator"
In-Reply-To: <33C997F9-AEB6-409C-9551-F4B8CAD872A9@carelogistics.com>
References: <BB71CD86-F37E-4E6B-AF23-9A6FE69B85C9@carelogistics.com>
	<56CFE1F8.5090200@redhat.com>
	<33C997F9-AEB6-409C-9551-F4B8CAD872A9@carelogistics.com>
Message-ID: <56D0B14F.9000205@redhat.com>

Hmm.... So you just unpacked the ZIP, start the server, set the admin 
password and then saw that error?

I didn't see it before tbh. Any chance to share whole stacktrace? And 
what's your java version?

Marek


On 26/02/16 15:42, Rong Sang (CL-ATL) wrote:
> Hi Marek,
>
> That?s the first error I found in the server.log. There were many 
> instances of the same error. I didn?t find any other error.
>
> I was testing the product on a mac. It was a clean install, no 
> migration. I didn?t configure SSL. According to 1.9.0 documents, it 
> should work with localhost. The only configuration I did was creating 
> the initial admin user.
>
> Thanks,
>
> Rong
>
> From: Marek Posolda <mposolda at redhat.com <mailto:mposolda at redhat.com>>
> Date: Friday, February 26, 2016 at 12:26 AM
> To: rongsang <rsang at carelogistics.com 
> <mailto:rsang at carelogistics.com>>, "keycloak-user at lists.jboss.org 
> <mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org 
> <mailto:keycloak-user at lists.jboss.org>>
> Subject: Re: [keycloak-user] "Client was not identified by any client 
> authenticator"
>
> Were there any other exceptions in server.log at startup? Did you 
> migrate from previous version or started from clean DB? If migrated 
> from previous version, could you try with clean DB?
>
> Thanks,
> Marek
>
> On 25/02/16 16:50, Rong Sang (CL-ATL) wrote:
>> Hi,
>>
>> I just downloaded the 1.9.0 final release, started the standalone 
>> server, created the initial admin user account and then tried to log 
>> in the admin console. I got the following error at that point:
>>
>> Failed client authentication: 
>> org.keycloak.authentication.AuthenticationFlowException: Client was 
>> not identified by any client authenticator
>>
>> The web page kept loading and the server had a lot of instance of the 
>> error above. I couldn?t go any further. What did I miss?
>>
>> Thanks,
>>
>> Rong
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-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/20160226/17eb6470/attachment.html 

From mposolda at redhat.com  Fri Feb 26 15:30:13 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 26 Feb 2016 21:30:13 +0100
Subject: [keycloak-user] SAML question
In-Reply-To: <860E8DAFFC76794694CFF405F8A1E71F02AA332B@416429-EXCH1.mbopartners.com>
References: <860E8DAFFC76794694CFF405F8A1E71F02AA332B@416429-EXCH1.mbopartners.com>
Message-ID: <56D0B5D5.9000406@redhat.com>

There are 2 things you need:
1) Configure LDAP mappers for the "givenName" and "sn" attribute, so 
Keycloak see them as attributes of user. After this, you should be able 
to see those attributes in the "attributes" tab in admin console for 
particular user from AD. If this works, step 1 is done :)

2) Configure protocol mapper for your client to map user attributes from 
LDAP (mapped in step 1) to the SAML assertion.

Marek

On 26/02/16 16:32, Ben Bazian wrote:
>
> I need to add Active Directory attributes to the SAML assertion.  Is 
> there documentation on how to do this?  Specifically I need to add 
> givenName and sn to the assertion that already has the email attribute.
>
>
>
> _______________________________________________
> 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/20160226/c5f81e82/attachment.html 

From mposolda at redhat.com  Fri Feb 26 15:37:17 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 26 Feb 2016 21:37:17 +0100
Subject: [keycloak-user] REST(MicroServices) authentication through SAML
 2.0
In-Reply-To: <330317876.30771350.1456494303748.JavaMail.zimbra@redhat.com>
References: <15a24101d17031$35c052c0$a140f840$@knowledgeflux.com>
	<330317876.30771350.1456494303748.JavaMail.zimbra@redhat.com>
Message-ID: <56D0B77D.9050801@redhat.com>

On 26/02/16 14:45, Pedro Igor Silva wrote:
>> >2) Does keycloak support Apache karaf container? I couldn?t find any adapter
>> >for this under SAML adapter category.
> I don't think so, but someone can give you more input on that.
>
We have Fuse/karaf adapters and also the examples for them, but that's 
all related to OIDC. It mostly leverages our OIDC Jetty adapter. See 
docs [1] and examples distribution (examples in "fuse" folder).

We have SAML Jetty adapter, so there might be a possibility to inject 
the SAML adapter to jetty in similar ways like we're doing for OIDC...

[1] 
http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#fuse-adapter

Marek

From alexander.schwartz at gmx.net  Fri Feb 26 15:50:05 2016
From: alexander.schwartz at gmx.net (Alexander Schwartz)
Date: Fri, 26 Feb 2016 21:50:05 +0100
Subject: [keycloak-user] Keycloak 1.9 behind Apache2 reverse proxy not
 working properly
In-Reply-To: <004e01d1709d$3ec43f00$bc4cbd00$@tu-dresden.de>
References: <56D03C9E.3000004@tu-dresden.de>
	<CAJgngAcLCi1Th+XA8MbH1aRVxMnaEec-U2toRyBD7Yy165y8vg@mail.gmail.com>,
	<004e01d1709d$3ec43f00$bc4cbd00$@tu-dresden.de>
Message-ID: <trinity-ec84d8ce-a0ce-49d3-ba91-4bb781d14817-1456519805305@3capp-gmx-bs07>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/e7e85d39/attachment-0001.html 

From bburke at redhat.com  Fri Feb 26 16:00:58 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 26 Feb 2016 16:00:58 -0500
Subject: [keycloak-user] user Attribute error
In-Reply-To: <4AC8C602867B3A4CB6F9F6BA4528DEE477B45E2F@WPHXMAIL1.phx.axway.int>
References: <4AC8C602867B3A4CB6F9F6BA4528DEE477B45E2F@WPHXMAIL1.phx.axway.int>
Message-ID: <56D0BD0A.7030204@redhat.com>

Why do you expect to be able to add an attribute on a read-only LDAP?  
I'm confused...

On 2/26/2016 11:03 AM, Gerard Laissard wrote:
>
> Hi,
>
> I?m using user Federation LDAP. The LDAP is read-only.
>
> When I add a user Attribute, I get ?Error! user is read-only!?
>
> How can I add specific user attributes?
>
> Thanks
>
> Gerard
>
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/29fa9fba/attachment.html 

From rsang at carelogistics.com  Fri Feb 26 17:04:23 2016
From: rsang at carelogistics.com (Rong Sang (CL-ATL))
Date: Fri, 26 Feb 2016 22:04:23 +0000
Subject: [keycloak-user] "Client was not identified by any client
 authenticator"
In-Reply-To: <56D0B14F.9000205@redhat.com>
References: <BB71CD86-F37E-4E6B-AF23-9A6FE69B85C9@carelogistics.com>
	<56CFE1F8.5090200@redhat.com>
	<33C997F9-AEB6-409C-9551-F4B8CAD872A9@carelogistics.com>
	<56D0B14F.9000205@redhat.com>
Message-ID: <ECA77CBB-87E7-4EB6-9210-E87935F5B0DB@carelogistics.com>

I?m using Java 8.

Here is the stacktrace of the error. Thanks!

2016-02-25 10:15:00,909 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Keycloak 1.9.0.Final (WildFly Core 2.0.10.Final) started in 13660ms - Started 416 of 782 services (526 services are lazy, passive or on-demand)
2016-02-25 10:15:31,939 INFO  [org.keycloak.services] (default task-2) KC-SERVICES0077: Created initial admin user with username admin
2016-02-25 10:15:43,537 ERROR [org.keycloak.services] (default task-10) KC-SERVICES0014: Failed client authentication: org.keycloak.authentication.AuthenticationFlowException: Client was not identified by any client authenticator
at org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101)
at org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673)
at org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42)
at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163)
at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117)
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:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

2016-02-25 10:15:43,539 WARN  [org.keycloak.events] (default task-10) type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, ipAddress=127.0.0.1, error=invalid_client_credentials, grant_type=authorization_code
2016-02-25 10:15:44,344 ERROR [org.keycloak.services] (default task-42) KC-SERVICES0014: Failed client authentication: org.keycloak.authentication.AuthenticationFlowException: Client was not identified by any client authenticator
at org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101)
at org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673)
at org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42)
at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163)
at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117)
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:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78)
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)



From: Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>>
Date: Friday, February 26, 2016 at 3:10 PM
To: rongsang <rsang at carelogistics.com<mailto:rsang at carelogistics.com>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] "Client was not identified by any client authenticator"

Hmm.... So you just unpacked the ZIP, start the server, set the admin password and then saw that error?

I didn't see it before tbh. Any chance to share whole stacktrace? And what's your java version?

Marek


On 26/02/16 15:42, Rong Sang (CL-ATL) wrote:
Hi Marek,

That?s the first error I found in the server.log. There were many instances of the same error. I didn?t find any other error.

I was testing the product on a mac. It was a clean install, no migration. I didn?t configure SSL. According to 1.9.0 documents, it should work with localhost. The only configuration I did was creating the initial admin user.

Thanks,

Rong

From: Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>>
Date: Friday, February 26, 2016 at 12:26 AM
To: rongsang <<mailto:rsang at carelogistics.com>rsang at carelogistics.com<mailto:rsang at carelogistics.com>>, "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] "Client was not identified by any client authenticator"

Were there any other exceptions in server.log at startup? Did you migrate from previous version or started from clean DB? If migrated from previous version, could you try with clean DB?

Thanks,
Marek

On 25/02/16 16:50, Rong Sang (CL-ATL) wrote:
Hi,

I just downloaded the 1.9.0 final release, started the standalone server, created the initial admin user account and then tried to log in the admin console. I got the following error at that point:

Failed client authentication: org.keycloak.authentication.AuthenticationFlowException: Client was not identified by any client authenticator

The web page kept loading and the server had a lot of instance of the error above. I couldn?t go any further. What did I miss?

Thanks,

Rong





_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/keycloak-user<http://cp.mcafee.com/d/1jWVIi6h0SyM-U-yeovd79KVJ6VEVvppuKOedEEEFITshupdETd7bXbbRSnzqaaaraabPX9Kddwh1lJzVZicGjBqDbCXr7PWApkDaRendILEAbEefZvD6jhOMyeoWZOWqrzD8FKnuvj7th5dqWqJQkul3PWApmU6CQjq9K_8I3DATbL3HCXCM0tBKlJHL_O-8pFC20udCb5Ag8v3M91wu30YgEbu8P2MIw5yoobxwc0jcgF4Cj9yaM51cI1MN4C1gJY1xm0n3gGU0VkGl62Fm0sc2d1qdOOonye2M2y2NkeQ5_10o67gU5L1wnYY9k0GbTzhs1Bwoaxs3-p0HOroWropDUp6wOS6nMY2h01W2gEcE0c4DxsbM4jMa2oE61FIOl5d1dM762Qiq093bUuw6gfgIdygJUzcbbvg5x8QsH1U72gybzpoy5V1RXQo1sMYf0Ui4hB4o0FYOglt2UKl0E4y8j4wmu4w72joudqa0ayWI1Mazl0sg0of3nOUwbfcO63Me15iU53cw6CWm5E29eUIY7L5U3oAbfcK0ewMNEmgoo47g_N4d2F51x6Uqbf865k67NgcCkRxEM2Mamt2oycNm1pomu5axA3wAca-oCwS30Js23qGRqlfgQ5hZ0DI-ndCzAttYS2_id41Fra-mIvniFtKDNdbFEwd4gAvbUjd41zq6y25pCy2i7MD9SnE6y0wmd46Mb6y2NYLxcQgqTcDY9OJIWNd4hIs-rO4O3>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/4a145134/attachment-0001.html 

From jaxley at expedia.com  Fri Feb 26 19:03:44 2016
From: jaxley at expedia.com (Jason Axley)
Date: Sat, 27 Feb 2016 00:03:44 +0000
Subject: [keycloak-user] user Attribute error
In-Reply-To: <56D0BD0A.7030204@redhat.com>
References: <4AC8C602867B3A4CB6F9F6BA4528DEE477B45E2F@WPHXMAIL1.phx.axway.int>
	<56D0BD0A.7030204@redhat.com>
Message-ID: <E9B6789B-6D4A-4CD4-B4A9-4E9251411AE9@expedia.com>

Some Idm products provide a virtual-directory-like capability where you can manage derived attributes for users regardless of the origin data store.  I could see it be advantageous to be able to layer metadata or other derived data on identities to make things easier to consume in downstream systems.  Would that be feasible in Keycloak?

-Jason

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>>
Date: Friday, February 26, 2016 at 1:00 PM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] user Attribute error

Why do you expect to be able to add an attribute on a read-only LDAP?  I'm confused...

On 2/26/2016 11:03 AM, Gerard Laissard wrote:
Hi,

I?m using user Federation LDAP. The LDAP is read-only.
When I add a user Attribute, I get ?Error! user is read-only!?

How can I add specific user attributes?

Thanks
Gerard



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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160227/e4037419/attachment.html 

From bburke at redhat.com  Fri Feb 26 19:07:10 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 26 Feb 2016 19:07:10 -0500
Subject: [keycloak-user] user Attribute error
In-Reply-To: <E9B6789B-6D4A-4CD4-B4A9-4E9251411AE9@expedia.com>
References: <4AC8C602867B3A4CB6F9F6BA4528DEE477B45E2F@WPHXMAIL1.phx.axway.int>
	<56D0BD0A.7030204@redhat.com>
	<E9B6789B-6D4A-4CD4-B4A9-4E9251411AE9@expedia.com>
Message-ID: <56D0E8AE.7090605@redhat.com>

You have to code it yourself.  Not sure if our ldap adapter is 
documented to do that or not.

On 2/26/2016 7:03 PM, Jason Axley wrote:
> Some Idm products provide a virtual-directory-like capability where 
> you can manage derived attributes for users regardless of the origin 
> data store.  I could see it be advantageous to be able to layer 
> metadata or other derived data on identities to make things easier to 
> consume in downstream systems.  Would that be feasible in Keycloak?
>
> -Jason
>
> From: <keycloak-user-bounces at lists.jboss.org 
> <mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Bill 
> Burke <bburke at redhat.com <mailto:bburke at redhat.com>>
> Date: Friday, February 26, 2016 at 1:00 PM
> To: "keycloak-user at lists.jboss.org 
> <mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org 
> <mailto:keycloak-user at lists.jboss.org>>
> Subject: Re: [keycloak-user] user Attribute error
>
> Why do you expect to be able to add an attribute on a read-only LDAP?  
> I'm confused...
>
> On 2/26/2016 11:03 AM, Gerard Laissard wrote:
>>
>> Hi,
>>
>> I?m using user Federation LDAP. The LDAP is read-only.
>>
>> When I add a user Attribute, I get ?Error! user is read-only!?
>>
>> How can I add specific user attributes?
>>
>> Thanks
>>
>> Gerard
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160226/3bbd4ab1/attachment.html 

From siva.b at knowledgeflux.com  Fri Feb 26 23:36:42 2016
From: siva.b at knowledgeflux.com (Siva)
Date: Sat, 27 Feb 2016 14:36:42 +1000
Subject: [keycloak-user] REST(MicroServices) authentication through SAML
	2.0
In-Reply-To: <330317876.30771350.1456494303748.JavaMail.zimbra@redhat.com>
References: <15a24101d17031$35c052c0$a140f840$@knowledgeflux.com>
	<330317876.30771350.1456494303748.JavaMail.zimbra@redhat.com>
Message-ID: <834401d17118$7c6f5580$754e0080$@knowledgeflux.com>

Thanks Pedro & Marek for your valuable inputs.

More questions:

Based on your response for question 1 in the below mail chain, I'm 100% with you on the brokering scenario if we own the client layer. I think I've not explained my scenario and questions very well in the previous mail; let me try to rearticulate my challenges here. 

As I specified in the below mail ,we completely own the business systems(Server side) which will have a client UI. But the UI layer is loosely coupled through REST(microservice) for the server and client interaction to support dynamic client interaction(Our own[Primary]  client UI or through business partners[Secondary] portal UI).

Here there are 2 cases, 

Case 1: 
	We bind our client UI in KC for authentication process through SAML 2.0(using IDP brokering). I'm clear on this process implementation ( since I've tested this approach in KC for simple web application).
Case 2:
	My challenge here is encapsulating the REST endpoints of our server side services for the authentication & authorization process;  irrespective of whether the request is coming from our own UI client or from business partner client; it's going to bring the token for authentication & authorization process (if we assume the client has received the SAML 2.0 tokens from their respective IDP[authorization server]). when the clients are sharing the SAML 2.0 tokens to the REST end points how exactly this request need to be handled or how this token should be validated through the SAML 2.0 broker IDP configured in KC?  This is where I'm puzzled at and I'm looking for your support to crack this issue.

As you have mentioned, even I'm not personally positive on using the SAML 2.0 for REST security; but unfortunately the enterprises which we work with doesn't support any other protocols and we are left with no choice here.

Your comment in the below mail chain : " An interesting solution would be the Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants [1]." If this is the only solution for case 2, do we have any plan on when exactly this will be implemented in KC?
 
Regards,
Siva.
-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: 27 February 2016 06:37
To: Pedro Igor Silva; Siva
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] REST(MicroServices) authentication through SAML 2.0

On 26/02/16 14:45, Pedro Igor Silva wrote:
>> >2) Does keycloak support Apache karaf container? I couldn?t find any 
>> >adapter for this under SAML adapter category.
> I don't think so, but someone can give you more input on that.
>
We have Fuse/karaf adapters and also the examples for them, but that's all related to OIDC. It mostly leverages our OIDC Jetty adapter. See docs [1] and examples distribution (examples in "fuse" folder).

We have SAML Jetty adapter, so there might be a possibility to inject the SAML adapter to jetty in similar ways like we're doing for OIDC...

[1]
http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#fuse-adapter

Marek
=================================================================================================
-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com] 
Sent: 26 February 2016 23:45
To: Siva
Cc: keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] REST(MicroServices) authentication through SAML 2.0

Hi Siva, 

    Some comments inline.


----- Original Message -----
> From: "Siva" <siva.b at knowledgeflux.com>
> To: keycloak-user at lists.jboss.org
> Sent: Thursday, February 25, 2016 10:01:15 PM
> Subject: [keycloak-user] REST(MicroServices) authentication through 
> SAML 2.0
> 
> 
> 
> Hi Experts,
> 
> 
> 
> I?ve got scenario, seeking your valuable inputs to take this in right 
> direction.
> 
> 
> 
> My application is complete server side solution which has 6 different 
> modules and it expose only the REST(Microservices) end points(5 
> modules are hosted in tomcat 8 container and 1 is hosted in Apache 
> Karaf [OSGI bundle] ) to the external world ; which will be accessed 
> by different enterprise and they need to integrate their SAML 2.0 IDP for authentication.
> 
> 
> 
> These Microservices end points could be integrated with their existing 
> portals or could be integrated with their existing mobile app 
> applications, in some scenario?s it could be an exclusive client 
> application built to consume our REST end points which could 
> potentially be a browser based and Mobile app.
> 
> 
> 
> The challenge here is, for now we could use only SAML 2.0 based 
> authentication since not all the organizations support OIDC/OAuth2.0 
> and as well our application could be flexible enough to be integrated 
> with the existing client portals which uses SAML 2.0 authentication.
> 
> 
> 
> We are planning to use keycloak as IDP broker to secure our endpoints.
> 
> 
> 
> Questions :
> 
> 
> 
> 1) Can this be achieved in keycloak? If yes, could you please provide 
> some inputs on architectural directions in keycloak; like should all 
> the modules need to be configured under 1 relam and need to have a 
> separate brokering relam?

I don't think that brokering is the best solution to address your requirements. If I understood your problem correctly, the clients trying to access your APIs belong to your partners and not you. Brokering is useful when you own the clients and want to create an indirection layer in order to integrate with external identity providers (pretty much the inverse of your use case). Or even during a migration plan when you already have some investments on SAML and want to gradually adopt OpenID Connect for new deployments.

In your case, what you need is something that can utilize an existing trust relationship in order to give to your clients the proper security token to access your APIs.

> 
> 2) Does keycloak support Apache karaf container? I couldn?t find any 
> adapter for this under SAML adapter category.

I don't think so, but someone can give you more input on that.

> 
> 3) For REST style endpoints, how should the user credential/Token 
> details need to shared? Any example links? kerberos is not a complete 
> solution here, since it need to work on all the devices(Desktop,Laptop & handheld).

Well, there is no sharing of user credentials, but security tokens.

> 
> 4) For the REST based solution, can the application completely rely on 
> keycloak for the session management, after the first time the user is 
> authenticated?
> 
> 
> 
> Any inputs on this will be highly valued.
>

An interesting solution would be the Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants [1]. Very useful when a client wishes to utilize an existing trust relationship, expressed through the semantics of the SAML Assertion, without a direct user approval step at the authorization server.

But, IIRC, that spec is not yet supported in KC.

I've also seem some people using SAML assertions to access RESTful resources. Personally, I don't think it is a good approach, since there is no SAML binding (standard) targeting RESTful resources.

There is also the SAML ECP profile, which we added recently. However, it is targeted for specific use cases where you need to issue a SAML Assertion based on some user credentials (so you must own the users, not your case I think). It also provides some very basic support for the SP side of things, but I don't think it can help you either.

[1] https://tools.ietf.org/html/rfc7522

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



From matthias_mueller at tu-dresden.de  Sat Feb 27 10:57:09 2016
From: matthias_mueller at tu-dresden.de (=?utf-8?Q?Matthias_M=C3=BCller?=)
Date: Sat, 27 Feb 2016 16:57:09 +0100
Subject: [keycloak-user] Keycloak 1.9 behind Apache2 reverse proxy not
	working properly
In-Reply-To: <trinity-ec84d8ce-a0ce-49d3-ba91-4bb781d14817-1456519805305@3capp-gmx-bs07>
References: <56D03C9E.3000004@tu-dresden.de>	<CAJgngAcLCi1Th+XA8MbH1aRVxMnaEec-U2toRyBD7Yy165y8vg@mail.gmail.com>,
	<004e01d1709d$3ec43f00$bc4cbd00$@tu-dresden.de>
	<trinity-ec84d8ce-a0ce-49d3-ba91-4bb781d14817-1456519805305@3capp-gmx-bs07>
Message-ID: <015601d17177$83df6e40$8b9e4ac0$@tu-dresden.de>

Hi Alexander,

 

thanks a lot for the debug hint which put me on the right track. Though the "env=HTTPS" condition was not the issue here, I could clearly see, that ?X-Forwarded-Proto? was not set in the HTTP headers. ? Surely a mistake in my Apache setup that did not properly include the statement. It is now fixed and Keycloak works as expected.

 

Cheers,

Matthias

 

 

From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Alexander Schwartz
Sent: Friday, February 26, 2016 9:50 PM
To: 'keycloak-user'
Subject: Re: [keycloak-user] Keycloak 1.9 behind Apache2 reverse proxy not working properly

 

Hello Matthias,

 

we're running Keycloak 1.8 in similar setup, and this should would. But we don't have the "env=HTTPS" condition, as we set it up the headers as part of the SSL part.

 

Could you verify that the headers are sent by Apache correctly? You could try the following: instead of starting keycloak on port 8080 you could start netcat:

 

nc -l 8080

 

This will print the request headers of the first request to your console.

 

Best regards,

Alexander.

 

--
Alexander Schwartz (alexander.schwartz at gmx.net)
http://www.ahus1.de

  

  

Gesendet: Freitag, 26. Februar 2016 um 14:54 Uhr
Von: "Matthias M?ller" <matthias_mueller at tu-dresden.de>
An: 'keycloak-user' <keycloak-user at lists.jboss.org>
Betreff: Re: [keycloak-user] Keycloak 1.9 behind Apache2 reverse proxy not working properly

Yes. I?ve set up an HTTPS reverse proxy in Apache as usual with and added the required header:

 

RequestHeader set X-Forwarded-Proto "https" env=HTTPS

 

Then I edited /usr/local/keycloak/standalone/configuration/standalone.xml according to these instructions.

 

>From what I?ve seen there?s no difference in the responses between:

 

a)      Configuring reverse proxy in Apache only

b)      Configuring reverse proxy in Apache AND editing standalone.xml

 

In both cases the hostname is properly resolved, but not the protocol part.

 

Cheers,

Matthias

 

p.s.: The documentation shows a configuration for an old release (1.1) of the undertow subsystem. Current is 3.0, which is also part of Keycloak distro. Is the configuration identical for both versions?

 

 

From:  <mailto:keycloak-user-bounces at lists.jboss.org> keycloak-user-bounces at lists.jboss.org [ <mailto:keycloak-user-bounces at lists.jboss.org> mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
Sent: Friday, February 26, 2016 1:36 PM
To: Matthias M?ller
Cc: keycloak-user
Subject: Re: [keycloak-user] Keycloak 1.9 behind Apache2 reverse proxy not working properly

 

DId you follow documentation at http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e394

 

On 26 February 2016 at 12:53, Matthias M?ller <Matthias_Mueller at tu-dresden.de> wrote:

Does anyone have experiences with Keycloak 1.9 in an Apache2 reverse
proxy configuration?

In my test setup I am running Keycloak as a standalone service on port
8080. It is proxied behind an Apache HTTP Server that manages the SSL
communication and forwards requests to localhost:8080. The Apache side
of the proxy is working. However, the administration console web page
(auth/admin/master/console/) still contains plain http://... links
(should be: https://) to the JS components which, of course, is invalid.
Obviously the Keycloak service does not see (or ignores) the X-Forwarded
headers.

Am I missing something here?

Cheers,
Matthias

[1]:
http://auth.domain.org/auth/resources/1.9.0.final/admin/keycloak/lib/select2-3.4.1/select2.js
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user

 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160227/8e199066/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6116 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160227/8e199066/attachment-0001.bin 

From darcy_welsh at yahoo.com  Sun Feb 28 00:00:39 2016
From: darcy_welsh at yahoo.com (Darcy Welsh)
Date: Sat, 27 Feb 2016 23:00:39 -0600
Subject: [keycloak-user] Upgrade error - 1.8.0 to 1.8.1
Message-ID: <E074F712-1D84-48CA-AB9A-A6B16441D699@yahoo.com>

Hi,

I successfully upgraded from 1.7.0 to 1.8.0, however, seeing the following error when attempting to upgrade from 1.8.0 to either 1.8.1 or 1.9.0:

22:45:48,803 ERROR [org.keycloak.services.resources.KeycloakApplication] (ServerService Thread Pool -- 51) Failed to migrate datamodel: 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:153)
	at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)
	at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)
	at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
	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:103)
	at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)
	at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)
	at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)
	at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:139)
	at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:82)
	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:408)
	at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
	at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
	at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
	at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
	at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
	at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
	at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: liquibase.exception.DatabaseException: Incorrect database name '' [Failed SQL: CREATE TABLE ``.DATABASECHANGELOG (ID VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL, FILENAME VARCHAR(255) NOT NULL, DATEEXECUTED datetime NOT NULL, ORDEREXECUTED INT NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35) NULL, DESCRIPTION VARCHAR(255) NULL, COMMENTS VARCHAR(255) NULL, TAG VARCHAR(255) NULL, LIQUIBASE VARCHAR(20) NULL, CONTEXTS VARCHAR(255) NULL, LABELS VARCHAR(255) NULL)]
	at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:316)
	at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:55)
	at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:122)
	at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:112)
	at liquibase.changelog.StandardChangeLogHistoryService.init(StandardChangeLogHistoryService.java:214)
	at liquibase.Liquibase.checkLiquibaseTables(Liquibase.java:1074)
	at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1136)
	at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1126)
	at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1122)
	at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:63)
	... 36 more
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Incorrect database name ''
	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:408)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:377)
	at com.mysql.jdbc.Util.getInstance(Util.java:360)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:978)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3887)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3823)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435)
	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582)
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2526)
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2484)
	at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:848)
	at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:742)
	at org.jboss.jca.adapters.jdbc.WrappedStatement.execute(WrappedStatement.java:198)
	at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:314)
	... 45 more

Any ideas as to the potential cause/resolution?  

The MySQL datasource is configured as follows:

                <datasource jta="true" jndi-name="java:jboss/datasources/KeycloakDS" pool-name="KeycloakDS" enabled="true" use-java-context="true">
                    <connection-url>jdbc:mysql://localhost:3306/keycloak</connection-url>
                    <connection-property name="defaultFetchSize">
                        1000
                    </connection-property>
                    <driver>mysql</driver>
                    <pool>
                        <max-pool-size>20</max-pool-size>
                    </pool>
                    <security>
                        <user-name>keycloak</user-name>
                        <password>keycloakrocks!</password>
                    </security>
                    <timeout>
                        <set-tx-query-timeout>true</set-tx-query-timeout>
                    </timeout>
                    <statement>
                        <prepared-statement-cache-size>100</prepared-statement-cache-size>
                        <share-prepared-statements>true</share-prepared-statements>
                    </statement>
                </datasource>
                <drivers>
                    <driver name="mysql" module="com.mysql.jdbc">
                        <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
                        <datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlDataSource</datasource-class>
                    </driver>
                    .
                    .
                    .
                </drivers>



Any help would be much appreciated.

Thank-you in advance,
Darcy Welsh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160227/47e65037/attachment-0001.html 

From sthorger at redhat.com  Mon Feb 29 02:36:10 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 29 Feb 2016 08:36:10 +0100
Subject: [keycloak-user] Keycloak starting before Infinispan jndi ready?
In-Reply-To: <CALAqdu-FhhFPEYetXP1GZPv2Viq=dW6XkHBagwgPbpYddffo6g@mail.gmail.com>
References: <CALAqdu-fswbi8w3KhG5AQH2dmRgAqDO3fE6=8oXXSQRbMmfCFA@mail.gmail.com>
	<CAJgngAdLp3L5nXi+RGz_5uwnM081xWRrB8wZpqRzBw=XbokuPQ@mail.gmail.com>
	<CALAqdu-FhhFPEYetXP1GZPv2Viq=dW6XkHBagwgPbpYddffo6g@mail.gmail.com>
Message-ID: <CAJgngAens=JF4Sssv9tJr6jYob=FoggFjLNGdBDx-k8S7x12mA@mail.gmail.com>

Dude! You need to upgrade.

AFAIK we never saw that issue on WF8 and eager worked fine.

On 26 February 2016 at 17:26, Scott Rossillo <srossillo at smartling.com>
wrote:

> Wildfly 8. Keycloak 1.2.0.
> On Fri, Feb 26, 2016 at 8:46 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> What cache and what version of Keycloak?
>>
>> The eager flag was removed from the Infinispan subsystem in WF9, so we
>> added a dependency at the MSC level (WF subsystem stuff) to make sure the
>> caches are ready before Keycloak starts.
>>
>> On 26 February 2016 at 14:30, Scott Rossillo <srossillo at smartling.com>
>> wrote:
>>
>>> Has anyone else has a random issue where Keycloak code is started before
>>> Inifinspan subsystem is ready? Even with the cache declared eager?
>>>
>>> _______________________________________________
>>> 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/20160229/8e8cece8/attachment.html 

From mposolda at redhat.com  Mon Feb 29 03:16:54 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 29 Feb 2016 09:16:54 +0100
Subject: [keycloak-user] Upgrade error - 1.8.0 to 1.8.1
In-Reply-To: <E074F712-1D84-48CA-AB9A-A6B16441D699@yahoo.com>
References: <E074F712-1D84-48CA-AB9A-A6B16441D699@yahoo.com>
Message-ID: <56D3FE76.40809@redhat.com>

Which JDBC driver and DB version are you using? Just found this thread 
during googling: 
http://liquibase-user.narkive.com/njIDqyEC/incorrect-database-name-on-generatechangelog 
. Wonder if it can be related to your issue...

I am testing MySQL with JDBC driver version 5.1.29 and never saw the 
issue like this.

Marek

On 28/02/16 06:00, Darcy Welsh wrote:
> Hi,
>
> I successfully upgraded from 1.7.0 to 1.8.0, however, seeing the 
> following error when attempting to upgrade from 1.8.0 to either 1.8.1 
> or 1.9.0:
>
> 22:45:48,803 ERROR 
> [org.keycloak.services.resources.KeycloakApplication] (ServerService 
> Thread Pool -- 51) Failed to migrate datamodel: 
> 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:153)
> at 
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)
> at 
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)
> at 
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
> 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:103)
> at 
> org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)
> at 
> org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)
> at 
> org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)
> at 
> org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:139)
> at 
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:82)
> 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:408)
> at 
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
> at 
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
> at 
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
> at 
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
> at 
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
> at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> at 
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
> at 
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
> at 
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
> at 
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
> at 
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
> at 
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
> at 
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
> at 
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: liquibase.exception.DatabaseException: Incorrect database 
> name '' [Failed SQL: CREATE TABLE ``.DATABASECHANGELOG (ID 
> VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL, FILENAME 
> VARCHAR(255) NOT NULL, DATEEXECUTED datetime NOT NULL, ORDEREXECUTED 
> INT NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35) NULL, 
> DESCRIPTION VARCHAR(255) NULL, COMMENTS VARCHAR(255) NULL, TAG 
> VARCHAR(255) NULL, LIQUIBASE VARCHAR(20) NULL, CONTEXTS VARCHAR(255) 
> NULL, LABELS VARCHAR(255) NULL)]
> at 
> liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:316)
> at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:55)
> at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:122)
> at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:112)
> at 
> liquibase.changelog.StandardChangeLogHistoryService.init(StandardChangeLogHistoryService.java:214)
> at liquibase.Liquibase.checkLiquibaseTables(Liquibase.java:1074)
> at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1136)
> at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1126)
> at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1122)
> at 
> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:63)
> ... 36 more
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: 
> Incorrect database name ''
> 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:408)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:377)
> at com.mysql.jdbc.Util.getInstance(Util.java:360)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:978)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3887)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3823)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2526)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2484)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:848)
> at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:742)
> at 
> org.jboss.jca.adapters.jdbc.WrappedStatement.execute(WrappedStatement.java:198)
> at 
> liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:314)
> ... 45 more
>
> Any ideas as to the potential cause/resolution?
>
> The MySQL datasource is configured as follows:
>
>                 <datasource jta="true" 
> jndi-name="java:jboss/datasources/KeycloakDS" pool-name="KeycloakDS" 
> enabled="true" use-java-context="true">
> <connection-url>jdbc:mysql://localhost:3306/keycloak</connection-url>
>                     <connection-property name="defaultFetchSize">
>                         1000
>                     </connection-property>
> <driver>mysql</driver>
>                     <pool>
> <max-pool-size>20</max-pool-size>
>                     </pool>
>                     <security>
> <user-name>keycloak</user-name>
> <password>keycloakrocks!</password>
>                     </security>
>                     <timeout>
> <set-tx-query-timeout>true</set-tx-query-timeout>
>                     </timeout>
>                     <statement>
> <prepared-statement-cache-size>100</prepared-statement-cache-size>
> <share-prepared-statements>true</share-prepared-statements>
>                     </statement>
>                 </datasource>
>           <drivers>
>                     <driver name="mysql" module="com.mysql.jdbc">
> <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
> <datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlDataSource</datasource-class>
>                     </driver>
>                     .
>                     .
>                     .
>                 </drivers>
>
>
>
> Any help would be much appreciated.
>
> Thank-you in advance,
> Darcy Welsh
>
>
>
> _______________________________________________
> 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/20160229/1f90e86a/attachment-0001.html 

From mposolda at redhat.com  Mon Feb 29 03:32:40 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 29 Feb 2016 09:32:40 +0100
Subject: [keycloak-user] user Attribute error
In-Reply-To: <56D0E8AE.7090605@redhat.com>
References: <4AC8C602867B3A4CB6F9F6BA4528DEE477B45E2F@WPHXMAIL1.phx.axway.int>
	<56D0BD0A.7030204@redhat.com>
	<E9B6789B-6D4A-4CD4-B4A9-4E9251411AE9@expedia.com>
	<56D0E8AE.7090605@redhat.com>
Message-ID: <56D40228.2010800@redhat.com>

You can do this already though. You need to setup like:
- LDAP federation provider must have edit mode UNSYNCED
- LDAP mapper for your attribute must have "readOnly" to "on" and 
"alwaysReadValueFromLDAP" to "off". But this is default settings for the 
mapper for UNSYNCED edit mode anyway, so you don't need to explicitly 
configure anything in the mapper (you can just doublecheck if mapper is 
really set like this)

With setup like this, the attribute of user is read from LDAP during 
initial import of user from LDAP. But when you change attribute to some 
other value, the value is updated just to Keycloak DB (not to LDAP). And 
for all next reads of user, keycloak will see the value from the DB (not 
the one from LDAP).

Also you can add any new attribute to the user too. This will be always 
saved to Keycloak DB and never to LDAP.

Marek

On 27/02/16 01:07, Bill Burke wrote:
> You have to code it yourself.  Not sure if our ldap adapter is 
> documented to do that or not.
>
> On 2/26/2016 7:03 PM, Jason Axley wrote:
>> Some Idm products provide a virtual-directory-like capability where 
>> you can manage derived attributes for users regardless of the origin 
>> data store.  I could see it be advantageous to be able to layer 
>> metadata or other derived data on identities to make things easier to 
>> consume in downstream systems.  Would that be feasible in Keycloak?
>>
>> -Jason
>>
>> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Bill Burke 
>> <bburke at redhat.com <mailto:bburke at redhat.com>>
>> Date: Friday, February 26, 2016 at 1:00 PM
>> To: "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org 
>> <mailto:keycloak-user at lists.jboss.org>>
>> Subject: Re: [keycloak-user] user Attribute error
>>
>> Why do you expect to be able to add an attribute on a read-only 
>> LDAP?  I'm confused...
>>
>> On 2/26/2016 11:03 AM, Gerard Laissard wrote:
>>>
>>> Hi,
>>>
>>> I?m using user Federation LDAP. The LDAP is read-only.
>>>
>>> When I add a user Attribute, I get ?Error! user is read-only!?
>>>
>>> How can I add specific user attributes?
>>>
>>> Thanks
>>>
>>> Gerard
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
> -- 
> 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/20160229/77e55be0/attachment.html 

From yelata at blulogix.com  Mon Feb 29 03:55:18 2016
From: yelata at blulogix.com (Yasser El-ata)
Date: Mon, 29 Feb 2016 10:55:18 +0200
Subject: [keycloak-user] CRUD Using KeyCloak
Message-ID: <CAHnbcZhYW0qGR_tMuAgXOac0ZmaoqzQV4vADhdMjNNa1G++WiQ@mail.gmail.com>

Hello , i wan't to create CRUD using KeyCloak , i have an angularJS
application and it's use KeyCloak

My case is : i have screens in my application that contain sub screens and
every sub screen contain CRUD roles (CREATE , READ , UPDATE , DELETE) ,
it's may contain multi levels

the screenshot may make the case more clear

the normal client roles is not enough for me or maybe i miss understand
some thing

could you please help me how to create these roles in KeyCloak , or if
KeyCloak is support roles like this or if there is any other way to create
them ?

Thanks

-- 
Yasser El-Ata
Java Developer
BluLogix
737 Walker Rd Ste 3, Great Falls, VA 22066
t: 443.333.4100 | f: 443.333.4101
*www.blulogix.com <http://www.blueoss.com/>*

The information transmitted is intended only for the person(s) to whom it
is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any
action in reliance upon, this information by persons or entities other than
the intended recipient is prohibited. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160229/21a80e5d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ACCESS LEVELS - New Page.png
Type: image/png
Size: 32777 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160229/21a80e5d/attachment-0001.png 

From adrianmatei at gmail.com  Mon Feb 29 04:58:26 2016
From: adrianmatei at gmail.com (Adrian Matei)
Date: Mon, 29 Feb 2016 10:58:26 +0100
Subject: [keycloak-user] LDAP Query Failed - AD connection reset
Message-ID: <CAG=THF0tQ=qX2FUsTaZKHjPm4rg4Qn10aWUP-26R-SnMfmsnqg@mail.gmail.com>

Hi everyone,

>From time to time we are experiencing the following error :
"LDAP Query Failed" (connection resets) for example by user registration,
but by the second try it usually works....

Connection to AD takes place via ldaps and keycloak (1.7.0.Final) running
on a JBoss EAP 6.4 with Java 8 installed.

The complete stacktrace from server.log:
08:47:05,029 ERROR [org.keycloak.services.resources.ModelExceptionMapper]
(http-/159.232.186.74:8443-7) LDAP Query failed:
org.keycloak.models.ModelException: LDAP Query failed
 at
org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:153)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getFirstResult(LDAPQuery.java:160)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.federation.ldap.LDAPFederationProvider.loadLDAPUserByUsername(LDAPFederationProvider.java:440)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.federation.ldap.LDAPFederationProvider.loadAndValidateUser(LDAPFederationProvider.java:230)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.federation.ldap.LDAPFederationProvider.validateAndProxy(LDAPFederationProvider.java:89)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.models.UserFederationManager.validateAndProxyUser(UserFederationManager.java:130)
[keycloak-model-api-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.models.UserFederationManager.getUserById(UserFederationManager.java:163)
[keycloak-model-api-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.models.sessions.infinispan.compat.UserSessionAdapter.getUser(UserSessionAdapter.java:62)
[keycloak-model-sessions-infinispan-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.services.resources.LoginActionsService.initEvent(LoginActionsService.java:732)
[keycloak-services-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.services.resources.LoginActionsService.processRequireAction(LoginActionsService.java:798)
[keycloak-services-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.services.resources.LoginActionsService.requiredActionPOST(LoginActionsService.java:750)
[keycloak-services-1.7.0.Final.jar:1.7.0.Final]
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.8.0_66]
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[rt.jar:1.8.0_66]
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_66]
 at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
 at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at
org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at
org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:158)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at
org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:561)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:543)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:128)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
[resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
[keycloak-services-1.7.0.Final.jar:1.7.0.Final]
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
[jboss-as-web-7.5.5.Final-redhat-3.jar:7.5.5.Final-redhat-3]
 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
[jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
 at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
 Caused by: org.keycloak.models.ModelException: Querying of LDAP failed
org.keycloak.federation.ldap.idm.query.internal.LDAPQuery at 7434dc3b
 at
org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:158)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:149)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 ... 42 more
 Caused by: javax.naming.CommunicationException: simple bind failed:
ldaps.AD_hostname:636 [Root exception is java.net.SocketException:
Connection reset]
 at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
[rt.jar:1.8.0_66]
 at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788) [rt.jar:1.8.0_66]
 at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) [rt.jar:1.8.0_66]
 at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
[rt.jar:1.8.0_66]
 at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
[rt.jar:1.8.0_66]
 at
com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
[rt.jar:1.8.0_66]
 at
com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
[rt.jar:1.8.0_66]
 at
org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:122)
 at org.jboss.as.naming.InitialContext.init(InitialContext.java:107)
 at
javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
[rt.jar:1.8.0_66]
 at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:98)
 at
org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
 at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
[rt.jar:1.8.0_66]
 at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
[rt.jar:1.8.0_66]
 at javax.naming.InitialContext.init(InitialContext.java:244)
[rt.jar:1.8.0_66]
 at
javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
[rt.jar:1.8.0_66]
 at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.createLdapContext(LDAPOperationManager.java:453)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:518)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.search(LDAPOperationManager.java:148)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 at
org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:149)
[keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
 ... 43 more
 Caused by: java.net.SocketException: Connection reset
 at java.net.SocketInputStream.read(SocketInputStream.java:209)
[rt.jar:1.8.0_66]
 at java.net.SocketInputStream.read(SocketInputStream.java:141)
[rt.jar:1.8.0_66]
 at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
[jsse.jar:1.8.0_66]
 at sun.security.ssl.InputRecord.read(InputRecord.java:503)
[jsse.jar:1.8.0_66]
 at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
[jsse.jar:1.8.0_66]
 at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
[jsse.jar:1.8.0_66]
 at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
[jsse.jar:1.8.0_66]
 at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
[jsse.jar:1.8.0_66]
 at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
[rt.jar:1.8.0_66]
 at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
[rt.jar:1.8.0_66]
 at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:426)
[rt.jar:1.8.0_66]
 at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:399)
[rt.jar:1.8.0_66]
 at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
[rt.jar:1.8.0_66]
 at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
[rt.jar:1.8.0_66]
 ... 62 more

Anybody else experienced and fixed this?

Thanks,
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160229/7f39d3a2/attachment.html 

From glaissard at axway.com  Mon Feb 29 05:04:34 2016
From: glaissard at axway.com (Gerard Laissard)
Date: Mon, 29 Feb 2016 10:04:34 +0000
Subject: [keycloak-user] user Attribute error
In-Reply-To: <56D40228.2010800@redhat.com>
References: <4AC8C602867B3A4CB6F9F6BA4528DEE477B45E2F@WPHXMAIL1.phx.axway.int>
	<56D0BD0A.7030204@redhat.com>
	<E9B6789B-6D4A-4CD4-B4A9-4E9251411AE9@expedia.com>
	<56D0E8AE.7090605@redhat.com> <56D40228.2010800@redhat.com>
Message-ID: <4AC8C602867B3A4CB6F9F6BA4528DEE477B46130@WPHXMAIL1.phx.axway.int>

Many thanks Marek!
By using: - LDAP federation provider with edit mode = UNSYNCED
A first test shows it works!

To be more precise my use case is:
Keycloak is the IDP for our products. Some customers have an LDAP, but their do not want we add our products(clients) roles/attributes in their LDAP.

We configured 'LDAP Federation provider' as read-only (+ edit mode=UNSYNCED)
We configured user/group/client with our specific products user roles+attributes.
On client mappers we map attributes we needs on tokens.

Gerard


From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Marek Posolda
Sent: lundi 29 f?vrier 2016 09:33
To: Bill Burke; Jason Axley; keycloak-user at lists.jboss.org
Subject: Re: [keycloak-user] user Attribute error

You can do this already though. You need to setup like:
- LDAP federation provider must have edit mode UNSYNCED
- LDAP mapper for your attribute must have "readOnly" to "on" and "alwaysReadValueFromLDAP" to "off". But this is default settings for the mapper for UNSYNCED edit mode anyway, so you don't need to explicitly configure anything in the mapper (you can just doublecheck if mapper is really set like this)

With setup like this, the attribute of user is read from LDAP during initial import of user from LDAP. But when you change attribute to some other value, the value is updated just to Keycloak DB (not to LDAP). And for all next reads of user, keycloak will see the value from the DB (not the one from LDAP).

Also you can add any new attribute to the user too. This will be always saved to Keycloak DB and never to LDAP.

Marek

On 27/02/16 01:07, Bill Burke wrote:
You have to code it yourself.  Not sure if our ldap adapter is documented to do that or not.
On 2/26/2016 7:03 PM, Jason Axley wrote:
Some Idm products provide a virtual-directory-like capability where you can manage derived attributes for users regardless of the origin data store.  I could see it be advantageous to be able to layer metadata or other derived data on identities to make things easier to consume in downstream systems.  Would that be feasible in Keycloak?

-Jason

From: <keycloak-user-bounces at lists.jboss.org<mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of Bill Burke <bburke at redhat.com<mailto:bburke at redhat.com>>
Date: Friday, February 26, 2016 at 1:00 PM
To: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] user Attribute error

Why do you expect to be able to add an attribute on a read-only LDAP?  I'm confused...
On 2/26/2016 11:03 AM, Gerard Laissard wrote:
Hi,

I'm using user Federation LDAP. The LDAP is read-only.
When I add a user Attribute, I get 'Error! user is read-only!'

How can I add specific user attributes?

Thanks
Gerard




_______________________________________________

keycloak-user mailing list

keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/keycloak-user



--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com



--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com




_______________________________________________

keycloak-user mailing list

keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>

https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160229/cb08d33a/attachment-0001.html 

From cmoulliard at redhat.com  Mon Feb 29 05:32:13 2016
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Mon, 29 Feb 2016 11:32:13 +0100
Subject: [keycloak-user] XACML support ?
Message-ID: <56D41E2D.9020603@redhat.com>

Hi,

The project picketlink provides a servlet able to that can read SOAP 
messages that contain an XACML query in saml payload
https://github.com/picketlink/picketlink/blob/master/modules/federation/src/main/java/org/picketlink/identity/federation/web/servlets/saml/SOAPSAMLXACMLServlet.java#L56-L62

https://developer.jboss.org/wiki/XACMLPDPSOAPService

As the project picketlink is going to be merged with Keycloak, I'm 
wondering if XACML will be supported with Keycloak or not ?

Regards,

Charles

From sthorger at redhat.com  Mon Feb 29 05:56:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 29 Feb 2016 11:56:45 +0100
Subject: [keycloak-user] XACML support ?
In-Reply-To: <56D41E2D.9020603@redhat.com>
References: <56D41E2D.9020603@redhat.com>
Message-ID: <CAJgngAe-DgvLGVzgHzUpHLFyzrfcy4pK8q1q6LZXFdS=9aCf=w@mail.gmail.com>

The functionality that was going to be merged from PicketLink was mainly
SAML support, which has been merged.

For XACML we are considering adding support for that in the future by
adding authorization services to Keycloak. It'll be a while until that is
ready though.

On 29 February 2016 at 11:32, Charles Moulliard <cmoulliard at redhat.com>
wrote:

> Hi,
>
> The project picketlink provides a servlet able to that can read SOAP
> messages that contain an XACML query in saml payload
>
> https://github.com/picketlink/picketlink/blob/master/modules/federation/src/main/java/org/picketlink/identity/federation/web/servlets/saml/SOAPSAMLXACMLServlet.java#L56-L62
>
> https://developer.jboss.org/wiki/XACMLPDPSOAPService
>
> As the project picketlink is going to be merged with Keycloak, I'm
> wondering if XACML will be supported with Keycloak or not ?
>
> Regards,
>
> Charles
> _______________________________________________
> 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/20160229/8c3c0e7a/attachment.html 

From cmoulliard at redhat.com  Mon Feb 29 06:49:37 2016
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Mon, 29 Feb 2016 12:49:37 +0100
Subject: [keycloak-user] XACML support ?
In-Reply-To: <CAJgngAe-DgvLGVzgHzUpHLFyzrfcy4pK8q1q6LZXFdS=9aCf=w@mail.gmail.com>
References: <56D41E2D.9020603@redhat.com>
	<CAJgngAe-DgvLGVzgHzUpHLFyzrfcy4pK8q1q6LZXFdS=9aCf=w@mail.gmail.com>
Message-ID: <56D43051.80204@redhat.com>

Is there a jira ticket opened in Keycloak for that ("adding 
authorization services to Keycloak") ?

On 29/02/16 11:56, Stian Thorgersen wrote:
> The functionality that was going to be merged from PicketLink was 
> mainly SAML support, which has been merged.
>
> For XACML we are considering adding support for that in the future by 
> adding authorization services to Keycloak. It'll be a while until that 
> is ready though.
>
> On 29 February 2016 at 11:32, Charles Moulliard <cmoulliard at redhat.com 
> <mailto:cmoulliard at redhat.com>> wrote:
>
>     Hi,
>
>     The project picketlink provides a servlet able to that can read SOAP
>     messages that contain an XACML query in saml payload
>     https://github.com/picketlink/picketlink/blob/master/modules/federation/src/main/java/org/picketlink/identity/federation/web/servlets/saml/SOAPSAMLXACMLServlet.java#L56-L62
>
>     https://developer.jboss.org/wiki/XACMLPDPSOAPService
>
>     As the project picketlink is going to be merged with Keycloak, I'm
>     wondering if XACML will be supported with Keycloak or not ?
>
>     Regards,
>
>     Charles
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160229/a84b6a73/attachment.html 

From psilva at redhat.com  Mon Feb 29 07:04:04 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 29 Feb 2016 07:04:04 -0500 (EST)
Subject: [keycloak-user] REST(MicroServices) authentication through SAML
 2.0
In-Reply-To: <834401d17118$7c6f5580$754e0080$@knowledgeflux.com>
References: <15a24101d17031$35c052c0$a140f840$@knowledgeflux.com>
	<330317876.30771350.1456494303748.JavaMail.zimbra@redhat.com>
	<834401d17118$7c6f5580$754e0080$@knowledgeflux.com>
Message-ID: <1943685689.31440514.1456747444352.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Siva" <siva.b at knowledgeflux.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, mposolda at redhat.com
> Cc: keycloak-user at lists.jboss.org
> Sent: Saturday, February 27, 2016 1:36:42 AM
> Subject: RE: [keycloak-user] REST(MicroServices) authentication through SAML 2.0
> 
> Thanks Pedro & Marek for your valuable inputs.
> 
> More questions:
> 
> Based on your response for question 1 in the below mail chain, I'm 100% with
> you on the brokering scenario if we own the client layer. I think I've not
> explained my scenario and questions very well in the previous mail; let me
> try to rearticulate my challenges here.
> 
> As I specified in the below mail ,we completely own the business
> systems(Server side) which will have a client UI. But the UI layer is
> loosely coupled through REST(microservice) for the server and client
> interaction to support dynamic client interaction(Our own[Primary]  client
> UI or through business partners[Secondary] portal UI).
> 
> Here there are 2 cases,
> 
> Case 1:
> 	We bind our client UI in KC for authentication process through SAML
> 	2.0(using IDP brokering). I'm clear on this process implementation ( since
> 	I've tested this approach in KC for simple web application).

+1, that makes sense. Now your clients can access your service layer using OAuth2.

> Case 2:
> 	My challenge here is encapsulating the REST endpoints of our server side
> 	services for the authentication & authorization process;  irrespective of
> 	whether the request is coming from our own UI client or from business
> 	partner client; it's going to bring the token for authentication &
> 	authorization process (if we assume the client has received the SAML 2.0
> 	tokens from their respective IDP[authorization server]). when the clients
> 	are sharing the SAML 2.0 tokens to the REST end points how exactly this
> 	request need to be handled or how this token should be validated through
> 	the SAML 2.0 broker IDP configured in KC?  This is where I'm puzzled at and
> 	I'm looking for your support to crack this issue.
> 
> As you have mentioned, even I'm not personally positive on using the SAML 2.0
> for REST security; but unfortunately the enterprises which we work with
> doesn't support any other protocols and we are left with no choice here.

The broker can't help you here. Case #2 is more about authorization, where you need to build a security context based on an existing token and use that to access your protected resources (business layer).

Like I said, there is that SAML 2.0 profile, which would provide a better an standardized security design. In this case, your protected resources would be protected by a single bearer token format, eg.: access_token.

Another thing you can do is customize the KC adapter to support both types of bearer tokens: SAML assertion or OAuth2 access_token. In this case, you would need to implement the necessary validations around the SAML assertions that you trust and keep the contract with your application intact regarding how you obtain the necessary claims to perform authorization checks.

> 
> Your comment in the below mail chain : " An interesting solution would be the
> Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client
> Authentication and Authorization Grants [1]." If this is the only solution
> for case 2, do we have any plan on when exactly this will be implemented in
> KC?

That I'll leave to Stian :) He is the best person to answer that.

>  
> Regards,
> Siva.
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: 27 February 2016 06:37
> To: Pedro Igor Silva; Siva
> Cc: keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] REST(MicroServices) authentication through SAML
> 2.0
> 
> On 26/02/16 14:45, Pedro Igor Silva wrote:
> >> >2) Does keycloak support Apache karaf container? I couldn?t find any
> >> >adapter for this under SAML adapter category.
> > I don't think so, but someone can give you more input on that.
> >
> We have Fuse/karaf adapters and also the examples for them, but that's all
> related to OIDC. It mostly leverages our OIDC Jetty adapter. See docs [1]
> and examples distribution (examples in "fuse" folder).
> 
> We have SAML Jetty adapter, so there might be a possibility to inject the
> SAML adapter to jetty in similar ways like we're doing for OIDC...
> 
> [1]
> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#fuse-adapter
> 
> Marek
> =================================================================================================
> -----Original Message-----
> From: Pedro Igor Silva [mailto:psilva at redhat.com]
> Sent: 26 February 2016 23:45
> To: Siva
> Cc: keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] REST(MicroServices) authentication through SAML
> 2.0
> 
> Hi Siva,
> 
>     Some comments inline.
> 
> 
> ----- Original Message -----
> > From: "Siva" <siva.b at knowledgeflux.com>
> > To: keycloak-user at lists.jboss.org
> > Sent: Thursday, February 25, 2016 10:01:15 PM
> > Subject: [keycloak-user] REST(MicroServices) authentication through
> > SAML 2.0
> > 
> > 
> > 
> > Hi Experts,
> > 
> > 
> > 
> > I?ve got scenario, seeking your valuable inputs to take this in right
> > direction.
> > 
> > 
> > 
> > My application is complete server side solution which has 6 different
> > modules and it expose only the REST(Microservices) end points(5
> > modules are hosted in tomcat 8 container and 1 is hosted in Apache
> > Karaf [OSGI bundle] ) to the external world ; which will be accessed
> > by different enterprise and they need to integrate their SAML 2.0 IDP for
> > authentication.
> > 
> > 
> > 
> > These Microservices end points could be integrated with their existing
> > portals or could be integrated with their existing mobile app
> > applications, in some scenario?s it could be an exclusive client
> > application built to consume our REST end points which could
> > potentially be a browser based and Mobile app.
> > 
> > 
> > 
> > The challenge here is, for now we could use only SAML 2.0 based
> > authentication since not all the organizations support OIDC/OAuth2.0
> > and as well our application could be flexible enough to be integrated
> > with the existing client portals which uses SAML 2.0 authentication.
> > 
> > 
> > 
> > We are planning to use keycloak as IDP broker to secure our endpoints.
> > 
> > 
> > 
> > Questions :
> > 
> > 
> > 
> > 1) Can this be achieved in keycloak? If yes, could you please provide
> > some inputs on architectural directions in keycloak; like should all
> > the modules need to be configured under 1 relam and need to have a
> > separate brokering relam?
> 
> I don't think that brokering is the best solution to address your
> requirements. If I understood your problem correctly, the clients trying to
> access your APIs belong to your partners and not you. Brokering is useful
> when you own the clients and want to create an indirection layer in order to
> integrate with external identity providers (pretty much the inverse of your
> use case). Or even during a migration plan when you already have some
> investments on SAML and want to gradually adopt OpenID Connect for new
> deployments.
> 
> In your case, what you need is something that can utilize an existing trust
> relationship in order to give to your clients the proper security token to
> access your APIs.
> 
> > 
> > 2) Does keycloak support Apache karaf container? I couldn?t find any
> > adapter for this under SAML adapter category.
> 
> I don't think so, but someone can give you more input on that.
> 
> > 
> > 3) For REST style endpoints, how should the user credential/Token
> > details need to shared? Any example links? kerberos is not a complete
> > solution here, since it need to work on all the devices(Desktop,Laptop &
> > handheld).
> 
> Well, there is no sharing of user credentials, but security tokens.
> 
> > 
> > 4) For the REST based solution, can the application completely rely on
> > keycloak for the session management, after the first time the user is
> > authenticated?
> > 
> > 
> > 
> > Any inputs on this will be highly valued.
> >
> 
> An interesting solution would be the Security Assertion Markup Language
> (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization
> Grants [1]. Very useful when a client wishes to utilize an existing trust
> relationship, expressed through the semantics of the SAML Assertion, without
> a direct user approval step at the authorization server.
> 
> But, IIRC, that spec is not yet supported in KC.
> 
> I've also seem some people using SAML assertions to access RESTful resources.
> Personally, I don't think it is a good approach, since there is no SAML
> binding (standard) targeting RESTful resources.
> 
> There is also the SAML ECP profile, which we added recently. However, it is
> targeted for specific use cases where you need to issue a SAML Assertion
> based on some user credentials (so you must own the users, not your case I
> think). It also provides some very basic support for the SP side of things,
> but I don't think it can help you either.
> 
> [1] https://tools.ietf.org/html/rfc7522
> 
> > 
> > 
> > Regards,
> > 
> > Siva.
> > 
> > 
> > 
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
>


From m.hayen at first8.nl  Mon Feb 29 07:57:33 2016
From: m.hayen at first8.nl (Mark Hayen)
Date: Mon, 29 Feb 2016 13:57:33 +0100
Subject: [keycloak-user] Keycloak on Openshift with custom domain and SSL
	certificate
Message-ID: <56D4403D.2000002@first8.nl>

Hi,

We're running our application on Openshift Online.
Of course it is secured by keycloak running in the same gear.

The openshift webconsole offers the possibility to import the 
certificate etc.
but when trying to access the application it throws the following error.

ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default 
task-48) failed to turn code into token: 
javax.net.ssl.SSLHandshakeException: 
sun.security.validator.ValidatorException: PKIX path building failed:
  sun.security.provider.certpath.SunCertPathBuilderException: unable to 
find valid certification path to requested target

What do I have to do to enable keycloak to find the stuf it needs?

Thank you
Mark Hayen
first8.nl


From darcy_welsh at yahoo.com  Mon Feb 29 08:57:39 2016
From: darcy_welsh at yahoo.com (Darcy Welsh)
Date: Mon, 29 Feb 2016 07:57:39 -0600
Subject: [keycloak-user] Upgrade error - 1.8.0 to 1.8.1
In-Reply-To: <56D3FE76.40809@redhat.com>
References: <E074F712-1D84-48CA-AB9A-A6B16441D699@yahoo.com>
	<56D3FE76.40809@redhat.com>
Message-ID: <EB860BCB-63B3-4D6A-ACEB-D067F4F99F57@yahoo.com>

Hey Marek,

I am using MySQL 5.6.23 with JDBC driver version 5.1.33.

Darcy


> On Feb 29, 2016, at 2:16 AM, Marek Posolda <mposolda at redhat.com> wrote:
> 
> Which JDBC driver and DB version are you using? Just found this thread during googling: http://liquibase-user.narkive.com/njIDqyEC/incorrect-database-name-on-generatechangelog <http://liquibase-user.narkive.com/njIDqyEC/incorrect-database-name-on-generatechangelog> . Wonder if it can be related to your issue...
> 
> I am testing MySQL with JDBC driver version 5.1.29 and never saw the issue like this.
> 
> Marek
> 
> On 28/02/16 06:00, Darcy Welsh wrote:
>> Hi,
>> 
>> I successfully upgraded from 1.7.0 to 1.8.0, however, seeing the following error when attempting to upgrade from 1.8.0 to either 1.8.1 or 1.9.0:
>> 
>> 22:45:48,803 ERROR [org.keycloak.services.resources.KeycloakApplication] (ServerService Thread Pool -- 51) Failed to migrate datamodel: 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:153)
>> 	at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)
>> 	at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)
>> 	at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
>> 	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:103)
>> 	at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)
>> 	at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)
>> 	at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)
>> 	at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:139)
>> 	at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:82)
>> 	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:408)
>> 	at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>> 	at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>> 	at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>> 	at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>> 	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>> 	at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>> 	at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>> 	at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>> 	at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>> 	at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> 	at java.lang.Thread.run(Thread.java:745)
>> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>> Caused by: liquibase.exception.DatabaseException: Incorrect database name '' [Failed SQL: CREATE TABLE ``.DATABASECHANGELOG (ID VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL, FILENAME VARCHAR(255) NOT NULL, DATEEXECUTED datetime NOT NULL, ORDEREXECUTED INT NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35) NULL, DESCRIPTION VARCHAR(255) NULL, COMMENTS VARCHAR(255) NULL, TAG VARCHAR(255) NULL, LIQUIBASE VARCHAR(20) NULL, CONTEXTS VARCHAR(255) NULL, LABELS VARCHAR(255) NULL)]
>> 	at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:316)
>> 	at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:55)
>> 	at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:122)
>> 	at liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:112)
>> 	at liquibase.changelog.StandardChangeLogHistoryService.init(StandardChangeLogHistoryService.java:214)
>> 	at liquibase.Liquibase.checkLiquibaseTables(Liquibase.java:1074)
>> 	at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1136)
>> 	at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1126)
>> 	at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1122)
>> 	at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:63)
>> 	... 36 more
>> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Incorrect database name ''
>> 	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:408)
>> 	at com.mysql.jdbc.Util.handleNewInstance(Util.java:377)
>> 	at com.mysql.jdbc.Util.getInstance(Util.java:360)
>> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:978)
>> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3887)
>> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3823)
>> 	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435)
>> 	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582)
>> 	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2526)
>> 	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2484)
>> 	at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:848)
>> 	at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:742)
>> 	at org.jboss.jca.adapters.jdbc.WrappedStatement.execute(WrappedStatement.java:198)
>> 	at liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:314)
>> 	... 45 more
>> 
>> Any ideas as to the potential cause/resolution?  
>> 
>> The MySQL datasource is configured as follows:
>> 
>>                 <datasource jta="true" jndi-name="java:jboss/datasources/KeycloakDS" pool-name="KeycloakDS" enabled="true" use-java-context="true">
>>                     <connection-url>jdbc:mysql://localhost:3306/keycloak</connection-url>
>>                     <connection-property name="defaultFetchSize">
>>                         1000
>>                     </connection-property>
>>                     <driver>mysql</driver>
>>                     <pool>
>>                         <max-pool-size>20</max-pool-size>
>>                     </pool>
>>                     <security>
>>                         <user-name>keycloak</user-name>
>>                         <password>keycloakrocks!</password>
>>                     </security>
>>                     <timeout>
>>                         <set-tx-query-timeout>true</set-tx-query-timeout>
>>                     </timeout>
>>                     <statement>
>>                         <prepared-statement-cache-size>100</prepared-statement-cache-size>
>>                         <share-prepared-statements>true</share-prepared-statements>
>>                     </statement>
>>                 </datasource>
>>                 <drivers>
>>                     <driver name="mysql" module="com.mysql.jdbc">
>>                         <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
>>                         <datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlDataSource</datasource-class>
>>                     </driver>
>>                     .
>>                     .
>>                     .
>>                 </drivers>
>> 
>> 
>> 
>> Any help would be much appreciated.
>> 
>> Thank-you in advance,
>> Darcy Welsh
>> 
>> 
>> 
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160229/6f61134b/attachment-0001.html 

From Edgar at info.nl  Mon Feb 29 09:17:54 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Mon, 29 Feb 2016 14:17:54 +0000
Subject: [keycloak-user] LDAP Query Failed - AD connection reset
In-Reply-To: <CAG=THF0tQ=qX2FUsTaZKHjPm4rg4Qn10aWUP-26R-SnMfmsnqg@mail.gmail.com>
References: <CAG=THF0tQ=qX2FUsTaZKHjPm4rg4Qn10aWUP-26R-SnMfmsnqg@mail.gmail.com>
Message-ID: <BF5C7BB3-2356-4C2E-8D4D-7ACC349AA108@info.nl>

Yes, we had the same issue. For us the solution was: http://lists.jboss.org/pipermail/keycloak-user/2016-February/004961.html

cheers

Edgar


> On 29 Feb 2016, at 10:58, Adrian Matei <adrianmatei at gmail.com> wrote:
> 
> Hi everyone,
> 
> From time to time we are experiencing the following error :
> "LDAP Query Failed" (connection resets) for example by user registration, but by the second try it usually works....
> 
> Connection to AD takes place via ldaps and keycloak (1.7.0.Final) running on a JBoss EAP 6.4 with Java 8 installed.
> 
> The complete stacktrace from server.log:
> 08:47:05,029 ERROR [org.keycloak.services.resources.ModelExceptionMapper] (http-/159.232.186.74:8443-7) LDAP Query failed: org.keycloak.models.ModelException: LDAP Query failed
>  at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:153) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getFirstResult(LDAPQuery.java:160) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.federation.ldap.LDAPFederationProvider.loadLDAPUserByUsername(LDAPFederationProvider.java:440) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.federation.ldap.LDAPFederationProvider.loadAndValidateUser(LDAPFederationProvider.java:230) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.federation.ldap.LDAPFederationProvider.validateAndProxy(LDAPFederationProvider.java:89) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.models.UserFederationManager.validateAndProxyUser(UserFederationManager.java:130) [keycloak-model-api-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.models.UserFederationManager.getUserById(UserFederationManager.java:163) [keycloak-model-api-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.models.sessions.infinispan.compat.UserSessionAdapter.getUser(UserSessionAdapter.java:62) [keycloak-model-sessions-infinispan-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.services.resources.LoginActionsService.initEvent(LoginActionsService.java:732) [keycloak-services-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.services.resources.LoginActionsService.processRequireAction(LoginActionsService.java:798) [keycloak-services-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.services.resources.LoginActionsService.requiredActionPOST(LoginActionsService.java:750) [keycloak-services-1.7.0.Final.jar:1.7.0.Final]
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_66]
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_66]
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_66]
>  at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_66]
>  at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:158) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:561) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:543) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:128) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.12.Final-redhat-1.jar:]
>  at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
>  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61) [keycloak-services-1.7.0.Final.jar:1.7.0.Final]
>  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.5.Final-redhat-3.jar:7.5.5.Final-redhat-3]
>  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.12.Final-redhat-1.jar:7.5.12.Final-redhat-1]
>  at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
>  Caused by: org.keycloak.models.ModelException: Querying of LDAP failed org.keycloak.federation.ldap.idm.query.internal.LDAPQuery at 7434dc3b
>  at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:158) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.federation.ldap.idm.query.internal.LDAPQuery.getResultList(LDAPQuery.java:149) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  ... 42 more
>  Caused by: javax.naming.CommunicationException: simple bind failed: ldaps.AD_hostname:636 [Root exception is java.net.SocketException: Connection reset]
>  at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219) [rt.jar:1.8.0_66]
>  at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788) [rt.jar:1.8.0_66]
>  at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) [rt.jar:1.8.0_66]
>  at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) [rt.jar:1.8.0_66]
>  at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) [rt.jar:1.8.0_66]
>  at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) [rt.jar:1.8.0_66]
>  at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) [rt.jar:1.8.0_66]
>  at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:122)
>  at org.jboss.as.naming.InitialContext.init(InitialContext.java:107)
>  at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) [rt.jar:1.8.0_66]
>  at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:98)
>  at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44)
>  at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.8.0_66]
>  at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) [rt.jar:1.8.0_66]
>  at javax.naming.InitialContext.init(InitialContext.java:244) [rt.jar:1.8.0_66]
>  at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) [rt.jar:1.8.0_66]
>  at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.createLdapContext(LDAPOperationManager.java:453) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:518) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.search(LDAPOperationManager.java:148) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  at org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.fetchQueryResults(LDAPIdentityStore.java:149) [keycloak-ldap-federation-1.7.0.Final.jar:1.7.0.Final]
>  ... 43 more
>  Caused by: java.net.SocketException: Connection reset
>  at java.net.SocketInputStream.read(SocketInputStream.java:209) [rt.jar:1.8.0_66]
>  at java.net.SocketInputStream.read(SocketInputStream.java:141) [rt.jar:1.8.0_66]
>  at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) [jsse.jar:1.8.0_66]
>  at sun.security.ssl.InputRecord.read(InputRecord.java:503) [jsse.jar:1.8.0_66]
>  at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973) [jsse.jar:1.8.0_66]
>  at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) [jsse.jar:1.8.0_66]
>  at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747) [jsse.jar:1.8.0_66]
>  at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123) [jsse.jar:1.8.0_66]
>  at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) [rt.jar:1.8.0_66]
>  at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) [rt.jar:1.8.0_66]
>  at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:426) [rt.jar:1.8.0_66]
>  at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:399) [rt.jar:1.8.0_66]
>  at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359) [rt.jar:1.8.0_66]
>  at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214) [rt.jar:1.8.0_66]
>  ... 62 more
> 
> Anybody else experienced and fixed this?
> 
> Thanks,
> Adrian
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



From Edgar at info.nl  Mon Feb 29 10:34:29 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Mon, 29 Feb 2016 15:34:29 +0000
Subject: [keycloak-user] Client Mappers. Can I define mappers
 programmatically?
In-Reply-To: <56AE8D52-DEB6-4000-BF2B-600124C4AE3C@carbonite.com>
References: <2697F06A-E3A8-408E-B949-AC25194BFAD9@carbonite.com>
	<CAK-7U1gJ=7H9ULu90fRTK0wEBObKL_Dzmcco-50KmVd7gL7a1g@mail.gmail.com>
	<56AE8D52-DEB6-4000-BF2B-600124C4AE3C@carbonite.com>
Message-ID: <F894600B-3B7C-4ECE-9690-BC3F57EF3E89@info.nl>

Hi Reed,

You also need to expose your mapper in a org.keycloak.protocol.ProtocolMapper file in META-INF/resources. See the one in the services project of the Keycloak Github source code.

cheers

On 26 Feb 2016, at 18:49, Reed Lewis <RLewis at carbonite.com<mailto:RLewis at carbonite.com>> wrote:

Can someone provide (if there is one out there) of an example of adding an additional OIDC mapper to Keycloak?   I have tried to compile and load a module to add an additional mapper, and cannot seem to get it working.   My new mapper does not appear as a choice for modifying the clJWT claim.

Or do I need to add it to the main source tree and recompile the whole Keycloak project?

Thanks,

Reed

From: Thomas Darimont <thomas.darimont at googlemail.com<mailto:thomas.darimont at googlemail.com>>
Date: Wednesday, February 24, 2016 at 4:31 PM
To: Reed Lewis <RLewis at carbonite.com<mailto:RLewis at carbonite.com>>
Cc: "keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>" <keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>>
Subject: Re: [keycloak-user] Client Mappers. Can I define mappers programmatically?

Hello Reed,

yes you should be able to do that via the:
org.keycloak.protocol.ProtocolMapperSpi

You can provide your own org.keycloak.protocol.ProtocolMapper
(org.keycloak.protocol.oidc.mappers.OIDCAccessTokenMapper) to introduce
computed attributes to the access tokens.

You can find the predefined mappers in the package:
org/keycloak/protocol/oidc/mappers within the keycloak-services project.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160229/3d09c625/attachment.html 

From Edgar at info.nl  Mon Feb 29 11:52:51 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Mon, 29 Feb 2016 16:52:51 +0000
Subject: [keycloak-user] Update account - login action tokens - how to make
	them persistent
Message-ID: <07136B17-275D-4949-8C94-28C62EED1FC5@info.nl>

Hi,

See if I understand this correctly: in the default set up of Keycloak sessions and temporary tokens are not persisted in the Keycloak database? So consider this scenario:

1/ login as admin to master realm
2/ go to Users - Credentials and send a ?Update Password? reset action email
3/ user receives an email with a link with a unique token to update his/her password in Keycloak
4/ Keycloak server is restarted for whatever reason
5/ the temporary ?login action token? no longer exists and the link from 3/ no longer works

Is this correct and expected behaviour?

And if so, can somebody maybe point us in the direction to solve this? I.e. by making sessions/tokens by persistent I guess.

cheers

Edgar


From bbazian at mbopartners.com  Mon Feb 29 13:40:00 2016
From: bbazian at mbopartners.com (Ben Bazian)
Date: Mon, 29 Feb 2016 18:40:00 +0000
Subject: [keycloak-user] SAML Mapper for ObjectGUID
Message-ID: <860E8DAFFC76794694CFF405F8A1E71F02AB2827@416429-EXCH1.mbopartners.com>

I need to pass the objectGUID from Active Directory in a SAML assertion.  Anyone know where to point me to setting up this mapper?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160229/8b1cd704/attachment.html 

From bbazian at mbopartners.com  Mon Feb 29 13:59:51 2016
From: bbazian at mbopartners.com (Ben Bazian)
Date: Mon, 29 Feb 2016 18:59:51 +0000
Subject: [keycloak-user] SAML Mapper for ObjectGUID
In-Reply-To: <860E8DAFFC76794694CFF405F8A1E71F02AB2827@416429-EXCH1.mbopartners.com>
References: <860E8DAFFC76794694CFF405F8A1E71F02AB2827@416429-EXCH1.mbopartners.com>
Message-ID: <860E8DAFFC76794694CFF405F8A1E71F02AB2BB1@416429-EXCH1.mbopartners.com>

I should have been a bit more specific.  Sorry for the added email.  I am able to get the objectGUID but need to present it in the SAML assertion between {} brackets.  I am getting the string I need without the brackets.  How can I setup the mapper to append the brackets.


From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Ben Bazian
Sent: Monday, February 29, 2016 1:40 PM
To: 'keycloak-user at lists.jboss.org' <keycloak-user at lists.jboss.org>
Subject: [keycloak-user] SAML Mapper for ObjectGUID


I need to pass the objectGUID from Active Directory in a SAML assertion.  Anyone know where to point me to setting up this mapper?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160229/b3d1ae3e/attachment.html 

From RRathod at carbonite.com  Mon Feb 29 23:13:50 2016
From: RRathod at carbonite.com (Riddhi Rathod)
Date: Tue, 1 Mar 2016 04:13:50 +0000
Subject: [keycloak-user] Multiple security Q&As for a user
Message-ID: <3B545404-0DBB-4495-8F36-F434FA4A4513@carboniteinc.com>

Hi all,

If security question option is enabled in the login flow, then the user has to save answer to it (Default question: ?What is your mother?s name??). This question is asked to user in the event of ?forget password? for additional level of security. However, in the current system, there is provision of storing only one security Q&A. I am looking to modify this to include the following:

Could this functionality be extended to include 3 security Q&As which is popular practice. I modified the keycloak secret-question.ftl to include 2 more questions. But there is no way to store the additional questions and answers extracted from the ui form in the UserCredentialValueModel (SecretQuestionRequiredAction.java).
The security questions are not fixed i.e. a dropdown menu of questions will be displayed to users and they will be able to select whichever questions they want to.

Does keycloak support storing of multiple security Q&As for a user? Has anyone tried this before?


Thank you,
Riddhi Rathod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160301/4e476134/attachment.html