From sthorger at redhat.com Thu Oct 1 02:49:04 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 1 Oct 2015 08:49:04 +0200 Subject: [keycloak-dev] Admin REST - User Roles In-Reply-To: References: <560BB7AC.6040501@redhat.com> Message-ID: Sorry, I meant does it include the "roles" field? On 30 September 2015 at 16:24, Remi Cartier wrote: > The JSON response (string) does NOT contain any roles. > > ------------------------------ > *From:* Stian Thorgersen [sthorger at redhat.com] > *Sent:* Wednesday, September 30, 2015 7:39 AM > *To:* Remi Cartier > *Cc:* Marek Posolda; keycloak-dev at lists.jboss.org > > *Subject:* Re: [keycloak-dev] Admin REST - User Roles > > Does the response actually contain the roles though? You're parsing to UserRepresentation > then printing it out afterwards. > > On 30 September 2015 at 13:24, Remi Cartier > wrote: > >> Marek, >> >> I see, thank you for your reply. >> >> Wouldn't it be less error/question prone if the endpoint returning all >> the users wouldn't show the *roles attributes ? >> Because they will always be null if I understood correctly. >> >> Regards. >> >> R?mi. >> >> ------------------------------ >> *From:* Marek Posolda [mposolda at redhat.com] >> *Sent:* Wednesday, September 30, 2015 6:21 AM >> *To:* Remi Cartier; keycloak-dev at lists.jboss.org >> *Subject:* Re: [keycloak-dev] Admin REST - User Roles >> >> Hi, >> >> to retrieve realm role mappings of user, you need to use the endpoint >> like http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm >> . See the docs for details: >> http://keycloak.github.io/docs/rest-api/overview-index.html >> >> Marek >> >> On 29/09/15 19:06, Remi Cartier wrote: >> >> Hi guys, >> >> first of all, thank you for that great piece of software, it?s amazing ! >> >> Now, down to business. >> >> When I do : >> >> keycloak = Keycloak.getInstance(getKeycloakServerURL(), >> getKeycloakRealm(), getKeycloakRealmAdminUsername(), >> getKeycloakRealmAdminPassword(), getKeycloakClientId()); >> for (UserRepresentation userRepresentation : >> keycloak.realm(getKeycloakRealm()).users().search(null, 0, >> Integer.MAX_VALUE)) { >> log.info(ToStringBuilder.reflectionToString(userRepresentation, >> ToStringStyle.JSON_STYLE)); >> } >> >> The information I get does not contain any roles, all the roles related >> fields are ?null?. - >> >> {"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first >> name","lastName":"last >> name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null} >> However in the admin interface I have setup roles at each layer : realm, >> client >> >> The user I am using to do the queries has all the *realm* roles >> associated. >> >> is there anything else I need to do ? >> >> thank you for your help ! >> >> ------------------------------ >> >> >> REMI CARTIER >> B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) >> >> *IMETRIK GLOBAL INC.* >> *T :* +1 514 448-6407 x2009 >> *T :* +1 866 276-5382 (toll free) >> *F :* +1 514 904-0611 >> >> 740 Notre Dame St. West, Suite 1575 >> Montreal, Quebec, Canada H3C 3X6 >> imetrik.com >> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/804ccc96/attachment.html From sthorger at redhat.com Thu Oct 1 03:05:01 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 1 Oct 2015 09:05:01 +0200 Subject: [keycloak-dev] Testing Migration? In-Reply-To: <560C75E3.10706@redhat.com> References: <560C75E3.10706@redhat.com> Message-ID: There was a problem with the database not being updated from 1.5 to 1.6 as the latest version was still set to 1.5. Fix on its way: https://github.com/keycloak/keycloak/pull/1666 On 1 October 2015 at 01:53, Stan Silvert wrote: > I've never tested migration before and I wonder if I'm doing it right. > Keycloak 1.6 server dies before the migration code is ever executed. > Here is what I did: > > Download Keycloak 1.5 > Start the server, add a couple of users and a new realm. > Build Keycloak 1.6 > Copy the database from 1.5 to 1.6 > Start Keycloak 1.6 > > I get: > > 19:40:03,411 INFO [org.hibernate.Version] (ServerService Thread Pool -- > 61) HHH000412: Hibernate Core {4.3.10.Final} > 19:40:03,413 INFO [org.hibernate.cfg.Environment] (ServerService Thread > Pool -- 61) HHH000206: hibernate.properties not found > 19:40:03,414 INFO [org.hibernate.cfg.Environment] (ServerService Thread > Pool -- 61) HHH000021: Bytecode provider name : javassist > 19:40:03,511 INFO [org.hibernate.annotations.common.Version] > (ServerService Thread Pool -- 61) HCANN000001: Hibernate Commons > Annotations {4.0.5.Final} > 19:40:03,551 INFO [org.hibernate.dialect.Dialect] (ServerService Thread > Pool -- 61) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect > 19:40:03,556 WARN [org.hibernate.dialect.H2Dialect] (ServerService > Thread Pool -- 61) HHH000431: Unable to determine H2 database version, > certain features may not work > 19:40:03,761 INFO > [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] > (ServerService Thread Pool -- 61) HHH000397: Using > ASTQueryTranslatorFactory > 19:40:03,789 INFO [org.hibernate.validator.internal.util.Version] > (ServerService Thread Pool -- 61) HV000001: Hibernate Validator 5.1.3.Final > 19:40:04,857 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] > (ServerService Thread Pool -- 61) SQL Error: 42122, SQLState: 42S22 > 19:40:04,857 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] > (ServerService Thread Pool -- 61) Column "CLIENTENTI1_.ROOT_URL" not > found; SQL statement: > select realmentit0_.ID as ID1_25_0_, realmentit0_.ACCESS_CODE_LIFESPAN > as ACCESS_C2_25_0_, realmentit0_.LOGIN_LIFESPAN as LOGIN_LI3_25_0_, > realmentit0_.USER_ACTION_LIFESP > AN as USER_ACT4_25_0_, realmentit0_.ACCESS_TOKEN_LIFESPAN as > ACCESS_T5_25_0_, realmentit0_.ACCOUNT_THEME as ACCOUNT_6_25_0_, > realmentit0_.ADMIN_EVENTS_DETAILS_ENABLED as > ADMIN_EV7_25_0_, realmentit0_.ADMIN_EVENTS_ENABLED as ADMIN_EV8_25_0_, > realmentit0_.ADMIN_THEME as ADMIN_TH9_25_0_, realmentit0_.BROWSER_FLOW > as BROWSER10_25_0_, realment > it0_.CERTIFICATE as CERTIFI11_25_0_, realmentit0_.CLIENT_AUTH_FLOW as > CLIENT_12_25_0_, realmentit0_.CODE_SECRET as CODE_SE13_25_0_, > realmentit0_.DEFAULT_LOCALE as DEFAULT > ... long SQL blah blah blah ... > 19:40:04,911 INFO > [org.hibernate.event.internal.DefaultLoadEventListener] (ServerService > Thread Pool -- 61) HHH000327: Error performing load command : > org.hibernate.exception.SQLGrammarException: could not prepare statement > 19:40:04,913 ERROR [org.jboss.msc.service.fail] (ServerService Thread > Pool -- 61) MSC000001: Failed to start service > jboss.undertow.deployment.default-server.default-host./auth: > org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth: > java.lang.RuntimeException: Failed to construct public > > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > at > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.RuntimeException: Failed to construct public > > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core > .Dispatcher) > at > > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160) > at > > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > at > > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > at > > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > at > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > at > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at > > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at > > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at > > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at > > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230) > at > > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131) > at > > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511) > at > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) > at > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > Caused by: org.keycloak.models.ModelException: > javax.persistence.PersistenceException: > org.hibernate.exception.SQLGrammarException: could not prepare statement > at > > org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) > at > > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) > at com.sun.proxy.$Proxy57.find(Unknown Source) > at > org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63) > at > > org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:150) > at > > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > at > > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > at > > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158) > at > > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:88) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > at > > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > ... 19 more > Caused by: javax.persistence.PersistenceException: > org.hibernate.exception.SQLGrammarException: could not prepare statement > at > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) > at > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694) > at > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141) > at > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068) > 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.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) > ... 31 more > Caused by: org.hibernate.exception.SQLGrammarException: could not > prepare statement > at > > org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:123) > at > > org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) > at > > org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) > at > > org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:196) > at > > org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:160) > at > > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.prepareQueryStatement(AbstractLoadPlanBasedLoader.java:257) > at > > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeQueryStatement(AbstractLoadPlanBasedLoader.java:201) > at > > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:137) > at > > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) > at > > org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) > at > > org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) > at > > org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) > at > > org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) > at > > org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) > at > > org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) > at > > org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) > at > org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1106) > at > org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) > at > > org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2587) > at org.hibernate.internal.SessionImpl.get(SessionImpl.java:991) > at > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) > ... 37 more > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/f3d1c842/attachment-0001.html From sthorger at redhat.com Thu Oct 1 03:13:59 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 1 Oct 2015 09:13:59 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> Message-ID: I don't like the query param approach as it requires somehow adding the query param to specify what authenticators to skip. This would have to be added to applications themselves and with Keycloak the whole idea is that applications shouldn't have to worry about authentication semantics. We need a generic mechanism to be able to skip any authenticators that automatically log in a user. Currently this is only Kerberos, but in the future we could add more, including an option to automatically route to external IdPs. Ignoring implementation semantics for now, but taking Kerberos as the example authenticator I can see some options (in the example below replace 'Kerberos' with any other authentication method that can automatically login a user): * If a user that was logged in using Kerberos logs out the user should not just be automatically logged-in again for the current browser session. Instead the user should be displayed with a regular username/password field, but also with an option to login with Kerberos * A variant on the above where if a user has logged-out from Kerberos the user would be displayed with a "Is this you?" when login, if the user selects yes the Kerberos authenticator would continue, if not the regular username/password form would be displayed * Implement account switcher - where a user can login to multiple accounts at a time and select which account to use Other ideas? Points for ideas that requires no hacks in applications ;) On 30 September 2015 at 15:39, Michael Gerber wrote: > Hi all, > > I would like to use kerberos as my standard authentication mechanism, but > I also want to have the possibility to log in as an admin over the login > form. > Therefore, I want to skip the kerberos authenticator after a successful > logout. > https://issues.jboss.org/browse/KEYCLOAK-1727 > > How would you solve this problem? > > I've got two solutions, one sets a logout session cookie after a logout > and then skips the kerberos authentication and another which allows users > to skip any kind of alternative authenticators with a query parameter. > > Logout Session Cookie > > https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854 > > Query Param > > https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc > > Michael > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/007637ed/attachment.html From mposolda at redhat.com Thu Oct 1 04:26:06 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 1 Oct 2015 10:26:06 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> Message-ID: <560CEE1E.8040708@redhat.com> On 01/10/15 09:13, Stian Thorgersen wrote: > I don't like the query param approach as it requires somehow adding > the query param to specify what authenticators to skip. This would > have to be added to applications themselves and with Keycloak the > whole idea is that applications shouldn't have to worry about > authentication semantics. I thing that some applications care about how was user authenticated :-\ For example when application wants to reuse Kerberos credential from the SPNEGO authentication to call some other thirdparty kerberos-secured service, it needs a way to "force" keycloak to authenticate with Kerberos. Hence it can skip other authenticators and leave just Kerberos. Similar case is, when application wants to reuse Facebook access token - in this case application wants to enforce login with Facebook. For this case, we already have kc_idp_hint parameter, which also requires support on the application side . Isn't it similar to the query parameter skip_auth_mechanisms ? I might be wrong, but maybe some Keycloak users don't care too much about SSO. The added value for them is provisioning of users and the fact, that they don't need to implement Facebook or Kerberos authentication, but Keycloak implements it for them. So they may want some control on the application side how is user authenticated. > We need a generic mechanism to be able to skip any authenticators that > automatically log in a user. Currently this is only Kerberos, but in > the future we could add more, including an option to automatically > route to external IdPs. For external IdPs, we already have "Authenticate by Default" switch on identity providers. We also have kc_idp_hint parameter as I mentioned above. > > Ignoring implementation semantics for now, but taking Kerberos as the > example authenticator I can see some options (in the example below > replace 'Kerberos' with any other authentication method that can > automatically login a user): > > * If a user that was logged in using Kerberos logs out the user should > not just be automatically logged-in again for the current browser > session. Instead the user should be displayed with a regular > username/password field, but also with an option to login with Kerberos > * A variant on the above where if a user has logged-out from Kerberos > the user would be displayed with a "Is this you?" when login, if the > user selects yes the Kerberos authenticator would continue, if not the > regular username/password form would be displayed +1 to support "Is this you" screen. However maybe this should be configurable as some deployments may not want to display the screen, but want to relogin automatically. Classic example is redhat.com. When I have kerberos ticket, I can never see the login screen on saml.redhat.com . If we enforce adding "Is this you", some employees may complain "Hey, why there is another splash screen I need to click. Why I am not logged automatically" etc. But maybe I am wrong here. Maybe good opportunity to ask IT guys on the call today as they have experience with the real world scenarios ;-) Conclusion of my point of view: Add variable support for "Is this you" screen and in addition have the support for skip_auth_mechanism Michael implemented. Marek > * Implement account switcher - where a user can login to multiple > accounts at a time and select which account to use > > Other ideas? Points for ideas that requires no hacks in applications ;) > > On 30 September 2015 at 15:39, Michael Gerber > wrote: > > Hi all, > > I would like to use kerberos as my standard authentication > mechanism, but I also want to have the possibility to log in as an > admin over the login form. > Therefore, I want to skip the kerberos authenticator after a > successful logout. > https://issues.jboss.org/browse/KEYCLOAK-1727 > > How would you solve this problem? > > I've got two solutions, one sets a logout session cookie after a > logout and then skips the kerberos authentication and another > which allows users to skip any kind of alternative authenticators > with a query parameter. > > Logout Session Cookie > https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854 > > Query Param > https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc > > Michael > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/9fd3242d/attachment.html From sthorger at redhat.com Thu Oct 1 04:59:19 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 1 Oct 2015 10:59:19 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <560CEE1E.8040708@redhat.com> References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560CEE1E.8040708@redhat.com> Message-ID: On 1 October 2015 at 10:26, Marek Posolda wrote: > On 01/10/15 09:13, Stian Thorgersen wrote: > > I don't like the query param approach as it requires somehow adding the > query param to specify what authenticators to skip. This would have to be > added to applications themselves and with Keycloak the whole idea is that > applications shouldn't have to worry about authentication semantics. > > I thing that some applications care about how was user authenticated :-\ > Maybe, but that's not the case in this use-case. In this case we simply want to use another user than the automatically logged-in user. So skip_auth_mech just becomes a work around/hack rather than a proper solution > > > For example when application wants to reuse Kerberos credential from the > SPNEGO authentication to call some other thirdparty kerberos-secured > service, it needs a way to "force" keycloak to authenticate with Kerberos. > Hence it can skip other authenticators and leave just Kerberos. > > Similar case is, when application wants to reuse Facebook access token - > in this case application wants to enforce login with Facebook. For this > case, we already have kc_idp_hint parameter, which also requires support on > the application side . Isn't it similar to the query parameter > skip_auth_mechanisms ? > Those situations are much more advanced than this use-case. In those case you'd have to have some form of a additional authenticators. For example if an app needs Facebook token they would need the user to authenticate with Facebook whether or not the user is already authenticated. This becomes quite tricky, especially if the user is already logged-in and logs in with FB as another user. But, that's not what this use case is about and we haven't had a request for this, so no need to consider it now. > > I might be wrong, but maybe some Keycloak users don't care too much about > SSO. The added value for them is provisioning of users and the fact, that > they don't need to implement Facebook or Kerberos authentication, but > Keycloak implements it for them. So they may want some control on the > application side how is user authenticated. > SSO or not, it's still the same concept of moving authentication semantics away from apps to the authentication server. > > We need a generic mechanism to be able to skip any authenticators that > automatically log in a user. Currently this is only Kerberos, but in the > future we could add more, including an option to automatically route to > external IdPs. > > For external IdPs, we already have "Authenticate by Default" switch on > identity providers. We also have kc_idp_hint parameter as I mentioned above. > > > Ignoring implementation semantics for now, but taking Kerberos as the > example authenticator I can see some options (in the example below replace > 'Kerberos' with any other authentication method that can automatically > login a user): > > * If a user that was logged in using Kerberos logs out the user should not > just be automatically logged-in again for the current browser session. > Instead the user should be displayed with a regular username/password > field, but also with an option to login with Kerberos > * A variant on the above where if a user has logged-out from Kerberos the > user would be displayed with a "Is this you?" when login, if the user > selects yes the Kerberos authenticator would continue, if not the regular > username/password form would be displayed > > +1 to support "Is this you" screen. However maybe this should be > configurable as some deployments may not want to display the screen, but > want to relogin automatically. > > Classic example is redhat.com. When I have kerberos ticket, I can never > see the login screen on saml.redhat.com . If we enforce adding "Is this > you", some employees may complain "Hey, why there is another splash screen > I need to click. Why I am not logged automatically" etc. But maybe I am > wrong here. Maybe good opportunity to ask IT guys on the call today as they > have experience with the real world scenarios ;-) > I don't see why it's a problem that the splash screen is displayed. The user has decided to log out from the Kerberos session so it makes no sense whatsoever to automatically log the user in again. That's basically disabling the log out. > > > Conclusion of my point of view: Add variable support for "Is this you" > screen and in addition have the support for skip_auth_mechanism Michael > implemented. > If we add is this you screen, then skip_auth_mechanism is not required for this use case and hence we should not add it unless specifically requested > > > Marek > > * Implement account switcher - where a user can login to multiple accounts > at a time and select which account to use > > Other ideas? Points for ideas that requires no hacks in applications ;) > > On 30 September 2015 at 15:39, Michael Gerber wrote: > >> Hi all, >> >> I would like to use kerberos as my standard authentication mechanism, but >> I also want to have the possibility to log in as an admin over the login >> form. >> Therefore, I want to skip the kerberos authenticator after a successful >> logout. >> https://issues.jboss.org/browse/KEYCLOAK-1727 >> >> How would you solve this problem? >> >> I've got two solutions, one sets a logout session cookie after a logout >> and then skips the kerberos authentication and another which allows users >> to skip any kind of alternative authenticators with a query parameter. >> >> Logout Session Cookie >> >> https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854 >> >> Query Param >> >> https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc >> >> Michael >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/9b51547c/attachment-0001.html From mposolda at redhat.com Thu Oct 1 05:42:19 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 1 Oct 2015 11:42:19 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560CEE1E.8040708@redhat.com> Message-ID: <560CFFFB.7050901@redhat.com> On 01/10/15 10:59, Stian Thorgersen wrote: > > > On 1 October 2015 at 10:26, Marek Posolda > wrote: > > On 01/10/15 09:13, Stian Thorgersen wrote: >> I don't like the query param approach as it requires somehow >> adding the query param to specify what authenticators to skip. >> This would have to be added to applications themselves and with >> Keycloak the whole idea is that applications shouldn't have to >> worry about authentication semantics. > I thing that some applications care about how was user > authenticated :-\ > > > Maybe, but that's not the case in this use-case. In this case we > simply want to use another user than the automatically logged-in user. > So skip_auth_mech just becomes a work around/hack rather than a proper > solution > > > > For example when application wants to reuse Kerberos credential > from the SPNEGO authentication to call some other thirdparty > kerberos-secured service, it needs a way to "force" keycloak to > authenticate with Kerberos. Hence it can skip other authenticators > and leave just Kerberos. > > Similar case is, when application wants to reuse Facebook access > token - in this case application wants to enforce login with > Facebook. For this case, we already have kc_idp_hint parameter, > which also requires support on the application side . Isn't it > similar to the query parameter skip_auth_mechanisms ? > > > Those situations are much more advanced than this use-case. In those > case you'd have to have some form of a additional authenticators. For > example if an app needs Facebook token they would need the user to > authenticate with Facebook whether or not the user is already > authenticated. This becomes quite tricky, especially if the user is > already logged-in and logs in with FB as another user. But, that's not > what this use case is about and we haven't had a request for this, so > no need to consider it now. > > > I might be wrong, but maybe some Keycloak users don't care too > much about SSO. The added value for them is provisioning of users > and the fact, that they don't need to implement Facebook or > Kerberos authentication, but Keycloak implements it for them. So > they may want some control on the application side how is user > authenticated. > > > SSO or not, it's still the same concept of moving authentication > semantics away from apps to the authentication server. TBH I am still not seeing why kc_idp_hint parameter support is ok, but skip_auth_mech is not. In both cases, it's the application which wants to control the behaviour somehow. Skip_auth_mech can be used to skip some mechanism, but also to enforce login with some mechanism (skip all other mechanisms besides the one required). > >> We need a generic mechanism to be able to skip any authenticators >> that automatically log in a user. Currently this is only >> Kerberos, but in the future we could add more, including an >> option to automatically route to external IdPs. > For external IdPs, we already have "Authenticate by Default" > switch on identity providers. We also have kc_idp_hint parameter > as I mentioned above. >> >> Ignoring implementation semantics for now, but taking Kerberos as >> the example authenticator I can see some options (in the example >> below replace 'Kerberos' with any other authentication method >> that can automatically login a user): >> >> * If a user that was logged in using Kerberos logs out the user >> should not just be automatically logged-in again for the current >> browser session. Instead the user should be displayed with a >> regular username/password field, but also with an option to login >> with Kerberos >> * A variant on the above where if a user has logged-out from >> Kerberos the user would be displayed with a "Is this you?" when >> login, if the user selects yes the Kerberos authenticator would >> continue, if not the regular username/password form would be >> displayed > +1 to support "Is this you" screen. However maybe this should be > configurable as some deployments may not want to display the > screen, but want to relogin automatically. > > Classic example is redhat.com . When I have > kerberos ticket, I can never see the login screen on > saml.redhat.com . If we enforce adding > "Is this you", some employees may complain "Hey, why there is > another splash screen I need to click. Why I am not logged > automatically" etc. But maybe I am wrong here. Maybe good > opportunity to ask IT guys on the call today as they have > experience with the real world scenarios ;-) > > > I don't see why it's a problem that the splash screen is displayed. > The user has decided to log out from the Kerberos session so it makes > no sense whatsoever to automatically log the user in again. That's > basically disabling the log out. I imagine I have 10 tabs opened in my browser. I want to close the tab with mojo.redhat.com and before that, I automatically click on "logout" . After few minutes, I want again to do something different for example in calendar. redhat.com and now I will see the splash screen when I want to relogin. For me, splash screen is not an issue. Not sure about all other employees... Maybe we can add splash screen automatically and add support for a flag to not display splash screen just when someone requests it. Again, I can be wrong, but I bet this request will come earlier or later :-) Marek > > > > Conclusion of my point of view: Add variable support for "Is this > you" screen and in addition have the support for > skip_auth_mechanism Michael implemented. > > > If we add is this you screen, then skip_auth_mechanism is not required > for this use case and hence we should not add it unless specifically > requested > > > > Marek > >> * Implement account switcher - where a user can login to multiple >> accounts at a time and select which account to use >> >> Other ideas? Points for ideas that requires no hacks in >> applications ;) >> >> On 30 September 2015 at 15:39, Michael Gerber > > wrote: >> >> Hi all, >> >> I would like to use kerberos as my standard authentication >> mechanism, but I also want to have the possibility to log in >> as an admin over the login form. >> Therefore, I want to skip the kerberos authenticator after a >> successful logout. >> https://issues.jboss.org/browse/KEYCLOAK-1727 >> >> How would you solve this problem? >> >> I've got two solutions, one sets a logout session cookie >> after a logout and then skips the kerberos authentication and >> another which allows users to skip any kind of alternative >> authenticators with a query parameter. >> >> Logout Session Cookie >> https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854 >> >> Query Param >> https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc >> >> Michael >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/b858e89c/attachment.html From sthorger at redhat.com Thu Oct 1 06:04:38 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 1 Oct 2015 12:04:38 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <560CFFFB.7050901@redhat.com> References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560CEE1E.8040708@redhat.com> <560CFFFB.7050901@redhat.com> Message-ID: On 1 October 2015 at 11:42, Marek Posolda wrote: > On 01/10/15 10:59, Stian Thorgersen wrote: > > > > On 1 October 2015 at 10:26, Marek Posolda wrote: > >> On 01/10/15 09:13, Stian Thorgersen wrote: >> >> I don't like the query param approach as it requires somehow adding the >> query param to specify what authenticators to skip. This would have to be >> added to applications themselves and with Keycloak the whole idea is that >> applications shouldn't have to worry about authentication semantics. >> >> I thing that some applications care about how was user authenticated :-\ >> > > Maybe, but that's not the case in this use-case. In this case we simply > want to use another user than the automatically logged-in user. So > skip_auth_mech just becomes a work around/hack rather than a proper solution > > >> >> >> For example when application wants to reuse Kerberos credential from the >> SPNEGO authentication to call some other thirdparty kerberos-secured >> service, it needs a way to "force" keycloak to authenticate with Kerberos. >> Hence it can skip other authenticators and leave just Kerberos. >> >> Similar case is, when application wants to reuse Facebook access token - >> in this case application wants to enforce login with Facebook. For this >> case, we already have kc_idp_hint parameter, which also requires support on >> the application side . Isn't it similar to the query parameter >> skip_auth_mechanisms ? >> > > Those situations are much more advanced than this use-case. In those case > you'd have to have some form of a additional authenticators. For example if > an app needs Facebook token they would need the user to authenticate with > Facebook whether or not the user is already authenticated. This becomes > quite tricky, especially if the user is already logged-in and logs in with > FB as another user. But, that's not what this use case is about and we > haven't had a request for this, so no need to consider it now. > > >> >> I might be wrong, but maybe some Keycloak users don't care too much about >> SSO. The added value for them is provisioning of users and the fact, that >> they don't need to implement Facebook or Kerberos authentication, but >> Keycloak implements it for them. So they may want some control on the >> application side how is user authenticated. >> > > SSO or not, it's still the same concept of moving authentication semantics > away from apps to the authentication server. > > TBH I am still not seeing why kc_idp_hint parameter support is ok, but > skip_auth_mech is not. In both cases, it's the application which wants to > control the behaviour somehow. Skip_auth_mech can be used to skip some > mechanism, but also to enforce login with some mechanism (skip all other > mechanisms besides the one required). > I'm not a big fan of kc_idp_hint either ;) "skip_auth_mech" would be a horrible way to enforce a specific auth mechanism. What if you add another mechanism? What if user is already logged-in? It's just not something that should be added without thinking about the corner cases. Then there are also similar things baked into OIDC to consider (acr, amr, id_token_hint, etc..). As we have loads of things to do and skip_auth_mech is not something that anyone has requested, except for in this use-case. Where I'm arguing that it's a bad way to do it. We shouldn't add it now as it's a work around/hackish solution that we haven't fully considered. > > > > >> >> We need a generic mechanism to be able to skip any authenticators that >> automatically log in a user. Currently this is only Kerberos, but in the >> future we could add more, including an option to automatically route to >> external IdPs. >> >> For external IdPs, we already have "Authenticate by Default" switch on >> identity providers. We also have kc_idp_hint parameter as I mentioned above. >> >> >> Ignoring implementation semantics for now, but taking Kerberos as the >> example authenticator I can see some options (in the example below replace >> 'Kerberos' with any other authentication method that can automatically >> login a user): >> >> * If a user that was logged in using Kerberos logs out the user should >> not just be automatically logged-in again for the current browser session. >> Instead the user should be displayed with a regular username/password >> field, but also with an option to login with Kerberos >> * A variant on the above where if a user has logged-out from Kerberos the >> user would be displayed with a "Is this you?" when login, if the user >> selects yes the Kerberos authenticator would continue, if not the regular >> username/password form would be displayed >> >> +1 to support "Is this you" screen. However maybe this should be >> configurable as some deployments may not want to display the screen, but >> want to relogin automatically. >> >> Classic example is redhat.com. When I have kerberos ticket, I can never >> see the login screen on saml.redhat.com . If we enforce adding "Is this >> you", some employees may complain "Hey, why there is another splash screen >> I need to click. Why I am not logged automatically" etc. But maybe I am >> wrong here. Maybe good opportunity to ask IT guys on the call today as they >> have experience with the real world scenarios ;-) >> > > I don't see why it's a problem that the splash screen is displayed. The > user has decided to log out from the Kerberos session so it makes no sense > whatsoever to automatically log the user in again. That's basically > disabling the log out. > > I imagine I have 10 tabs opened in my browser. I want to close the tab > with mojo.redhat.com and before that, I automatically click on "logout" . > After few minutes, I want again to do something different for example in > calendar. redhat.com and now I will see the splash screen when I want to > relogin. > > For me, splash screen is not an issue. Not sure about all other > employees... > > Maybe we can add splash screen automatically and add support for a flag to > not display splash screen just when someone requests it. Again, I can be > wrong, but I bet this request will come earlier or later :-) > Really? I just don't see that as a problem. 99.999% of the time the user won't see any splash screen as they will just login and that's that. For the times when someone logs out I just can't see it being a huge problem that they get a "is this you" prompt. If someone is really that bothered about the splash screen let them tell us and we can add an option, but there's no point in filling the admin console up with all sorts of unused toggles. > > > Marek > > > >> >> >> Conclusion of my point of view: Add variable support for "Is this you" >> screen and in addition have the support for skip_auth_mechanism Michael >> implemented. >> > > If we add is this you screen, then skip_auth_mechanism is not required for > this use case and hence we should not add it unless specifically requested > > >> >> >> Marek >> >> * Implement account switcher - where a user can login to multiple >> accounts at a time and select which account to use >> >> Other ideas? Points for ideas that requires no hacks in applications ;) >> >> On 30 September 2015 at 15:39, Michael Gerber < >> gerbermichi at me.com> wrote: >> >>> Hi all, >>> >>> I would like to use kerberos as my standard authentication mechanism, >>> but I also want to have the possibility to log in as an admin over the >>> login form. >>> Therefore, I want to skip the kerberos authenticator after a successful >>> logout. >>> https://issues.jboss.org/browse/KEYCLOAK-1727 >>> >>> How would you solve this problem? >>> >>> I've got two solutions, one sets a logout session cookie after a logout >>> and then skips the kerberos authentication and another which allows users >>> to skip any kind of alternative authenticators with a query parameter. >>> >>> Logout Session Cookie >>> >>> https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854 >>> >>> Query Param >>> >>> https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc >>> >>> Michael >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/f49de8b9/attachment-0001.html From mposolda at redhat.com Thu Oct 1 06:11:43 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 1 Oct 2015 12:11:43 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560CEE1E.8040708@redhat.com> <560CFFFB.7050901@redhat.com> Message-ID: <560D06DF.3040804@redhat.com> On 01/10/15 12:04, Stian Thorgersen wrote: > > > On 1 October 2015 at 11:42, Marek Posolda > wrote: > > On 01/10/15 10:59, Stian Thorgersen wrote: >> >> >> On 1 October 2015 at 10:26, Marek Posolda > > wrote: >> >> On 01/10/15 09:13, Stian Thorgersen wrote: >>> I don't like the query param approach as it requires somehow >>> adding the query param to specify what authenticators to >>> skip. This would have to be added to applications themselves >>> and with Keycloak the whole idea is that applications >>> shouldn't have to worry about authentication semantics. >> I thing that some applications care about how was user >> authenticated :-\ >> >> >> Maybe, but that's not the case in this use-case. In this case we >> simply want to use another user than the automatically logged-in >> user. So skip_auth_mech just becomes a work around/hack rather >> than a proper solution >> >> >> >> For example when application wants to reuse Kerberos >> credential from the SPNEGO authentication to call some other >> thirdparty kerberos-secured service, it needs a way to >> "force" keycloak to authenticate with Kerberos. Hence it can >> skip other authenticators and leave just Kerberos. >> >> Similar case is, when application wants to reuse Facebook >> access token - in this case application wants to enforce >> login with Facebook. For this case, we already have >> kc_idp_hint parameter, which also requires support on the >> application side . Isn't it similar to the query parameter >> skip_auth_mechanisms ? >> >> >> Those situations are much more advanced than this use-case. In >> those case you'd have to have some form of a additional >> authenticators. For example if an app needs Facebook token they >> would need the user to authenticate with Facebook whether or not >> the user is already authenticated. This becomes quite tricky, >> especially if the user is already logged-in and logs in with FB >> as another user. But, that's not what this use case is about and >> we haven't had a request for this, so no need to consider it now. >> >> >> I might be wrong, but maybe some Keycloak users don't care >> too much about SSO. The added value for them is provisioning >> of users and the fact, that they don't need to implement >> Facebook or Kerberos authentication, but Keycloak implements >> it for them. So they may want some control on the application >> side how is user authenticated. >> >> >> SSO or not, it's still the same concept of moving authentication >> semantics away from apps to the authentication server. > TBH I am still not seeing why kc_idp_hint parameter support is ok, > but skip_auth_mech is not. In both cases, it's the application > which wants to control the behaviour somehow. Skip_auth_mech can > be used to skip some mechanism, but also to enforce login with > some mechanism (skip all other mechanisms besides the one required). > > > I'm not a big fan of kc_idp_hint either ;) > > "skip_auth_mech" would be a horrible way to enforce a specific auth > mechanism. What if you add another mechanism? What if user is already > logged-in? It's just not something that should be added without > thinking about the corner cases. Then there are also similar things > baked into OIDC to consider (acr, amr, id_token_hint, etc..). > > As we have loads of things to do and skip_auth_mech is not something > that anyone has requested, except for in this use-case. Where I'm > arguing that it's a bad way to do it. We shouldn't add it now as it's > a work around/hackish solution that we haven't fully considered. > > > >> >>> We need a generic mechanism to be able to skip any >>> authenticators that automatically log in a user. Currently >>> this is only Kerberos, but in the future we could add more, >>> including an option to automatically route to external IdPs. >> For external IdPs, we already have "Authenticate by Default" >> switch on identity providers. We also have kc_idp_hint >> parameter as I mentioned above. >>> >>> Ignoring implementation semantics for now, but taking >>> Kerberos as the example authenticator I can see some options >>> (in the example below replace 'Kerberos' with any other >>> authentication method that can automatically login a user): >>> >>> * If a user that was logged in using Kerberos logs out the >>> user should not just be automatically logged-in again for >>> the current browser session. Instead the user should be >>> displayed with a regular username/password field, but also >>> with an option to login with Kerberos >>> * A variant on the above where if a user has logged-out from >>> Kerberos the user would be displayed with a "Is this you?" >>> when login, if the user selects yes the Kerberos >>> authenticator would continue, if not the regular >>> username/password form would be displayed >> +1 to support "Is this you" screen. However maybe this should >> be configurable as some deployments may not want to display >> the screen, but want to relogin automatically. >> >> Classic example is redhat.com . When I >> have kerberos ticket, I can never see the login screen on >> saml.redhat.com . If we enforce >> adding "Is this you", some employees may complain "Hey, why >> there is another splash screen I need to click. Why I am not >> logged automatically" etc. But maybe I am wrong here. Maybe >> good opportunity to ask IT guys on the call today as they >> have experience with the real world scenarios ;-) >> >> >> I don't see why it's a problem that the splash screen is >> displayed. The user has decided to log out from the Kerberos >> session so it makes no sense whatsoever to automatically log the >> user in again. That's basically disabling the log out. > I imagine I have 10 tabs opened in my browser. I want to close the > tab with mojo.redhat.com and before that, > I automatically click on "logout" . After few minutes, I want > again to do something different for example in calendar. > redhat.com and now I will see the splash > screen when I want to relogin. > > For me, splash screen is not an issue. Not sure about all other > employees... > > Maybe we can add splash screen automatically and add support for a > flag to not display splash screen just when someone requests it. > Again, I can be wrong, but I bet this request will come earlier or > later :-) > > > Really? I just don't see that as a problem. 99.999% of the time the > user won't see any splash screen as they will just login and that's > that. For the times when someone logs out I just can't see it being a > huge problem that they get a "is this you" prompt. > > If someone is really that bothered about the splash screen let them > tell us and we can add an option, but there's no point in filling the > admin console up with all sorts of unused toggles. Ok, I agree it's better to add additional toggles just when someone requests it. I just bet this request will come :-) Marek > > > > Marek > >> >> >> Conclusion of my point of view: Add variable support for "Is >> this you" screen and in addition have the support for >> skip_auth_mechanism Michael implemented. >> >> >> If we add is this you screen, then skip_auth_mechanism is not >> required for this use case and hence we should not add it unless >> specifically requested >> >> >> >> Marek >> >>> * Implement account switcher - where a user can login to >>> multiple accounts at a time and select which account to use >>> >>> Other ideas? Points for ideas that requires no hacks in >>> applications ;) >>> >>> On 30 September 2015 at 15:39, Michael Gerber >>> > wrote: >>> >>> Hi all, >>> >>> I would like to use kerberos as my standard >>> authentication mechanism, but I also want to have the >>> possibility to log in as an admin over the login form. >>> Therefore, I want to skip the kerberos authenticator >>> after a successful logout. >>> https://issues.jboss.org/browse/KEYCLOAK-1727 >>> >>> How would you solve this problem? >>> >>> I've got two solutions, one sets a logout session cookie >>> after a logout and then skips the kerberos >>> authentication and another which allows users to skip >>> any kind of alternative authenticators with a query >>> parameter. >>> >>> Logout Session Cookie >>> https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854 >>> >>> Query Param >>> https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc >>> >>> Michael >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/c91472d0/attachment-0001.html From mhajas at redhat.com Thu Oct 1 08:23:57 2015 From: mhajas at redhat.com (Michal Hajas) Date: Thu, 1 Oct 2015 08:23:57 -0400 (EDT) Subject: [keycloak-dev] How to enable grant logging In-Reply-To: <1744131951.24492075.1443701298541.JavaMail.zimbra@redhat.com> Message-ID: <1658882558.24504565.1443702237274.JavaMail.zimbra@redhat.com> Hi, I would like to ask, which event type, in Login Events Settings form -> Saved Types input, stands for grant access? Michal. From remi.cartier at imetrik.com Thu Oct 1 09:34:46 2015 From: remi.cartier at imetrik.com (Remi Cartier) Date: Thu, 1 Oct 2015 13:34:46 +0000 Subject: [keycloak-dev] Admin REST - User Roles In-Reply-To: References: <560BB7AC.6040501@redhat.com> Message-ID: yes, I can see : [ { "applicationRoles": null, "attributes": { "key1": [ "value1" ] }, "clientConsents": null, "clientRoles": null, "createdTimestamp": 1443542144845, "credentials": null, "email": null, "emailVerified": true, "enabled": true, "federatedIdentities": null, "federationLink": null, "firstName": "first name", "id": "0556717e-ffb9-4c2d-b85b-533d9396f243", "lastName": "last name", "realmRoles": null, "requiredActions": [], "self": null, "serviceAccountClientId": null, "socialLinks": null, "totp": false, "username": "admin" } ] when doing the query : GET /auth/admin/realms/imetrik/users?first=0&max=2147483647 ________________________________ REMI CARTIER B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) IMETRIK GLOBAL INC. T : +1 514 448-6407 x2009 T : +1 866 276-5382 (toll free) F : +1 514 904-0611 740 Notre Dame St. West, Suite 1575 Montreal, Quebec, Canada H3C 3X6 imetrik.com On Oct 1, 2015, at 2:49 AM, Stian Thorgersen > wrote: Sorry, I meant does it include the "roles" field? On 30 September 2015 at 16:24, Remi Cartier > wrote: The JSON response (string) does NOT contain any roles. ________________________________ From: Stian Thorgersen [sthorger at redhat.com] Sent: Wednesday, September 30, 2015 7:39 AM To: Remi Cartier Cc: Marek Posolda; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Admin REST - User Roles Does the response actually contain the roles though? You're parsing to UserRepresentation then printing it out afterwards. On 30 September 2015 at 13:24, Remi Cartier > wrote: Marek, I see, thank you for your reply. Wouldn't it be less error/question prone if the endpoint returning all the users wouldn't show the *roles attributes ? Because they will always be null if I understood correctly. Regards. R?mi. ________________________________ From: Marek Posolda [mposolda at redhat.com] Sent: Wednesday, September 30, 2015 6:21 AM To: Remi Cartier; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Admin REST - User Roles Hi, to retrieve realm role mappings of user, you need to use the endpoint like http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm . See the docs for details: http://keycloak.github.io/docs/rest-api/overview-index.html Marek On 29/09/15 19:06, Remi Cartier wrote: Hi guys, first of all, thank you for that great piece of software, it?s amazing ! Now, down to business. When I do : keycloak = Keycloak.getInstance(getKeycloakServerURL(), getKeycloakRealm(), getKeycloakRealmAdminUsername(), getKeycloakRealmAdminPassword(), getKeycloakClientId()); for (UserRepresentation userRepresentation : keycloak.realm(getKeycloakRealm()).users().search(null, 0, Integer.MAX_VALUE)) { log.info(ToStringBuilder.reflectionToString(userRepresentation, ToStringStyle.JSON_STYLE)); } The information I get does not contain any roles, all the roles related fields are ?null?. - {"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first name","lastName":"last name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null} However in the admin interface I have setup roles at each layer : realm, client The user I am using to do the queries has all the *realm* roles associated. is there anything else I need to do ? thank you for your help ! ________________________________ REMI CARTIER B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) IMETRIK GLOBAL INC. T : +1 514 448-6407 x2009 T : +1 866 276-5382 (toll free) F : +1 514 904-0611 740 Notre Dame St. West, Suite 1575 Montreal, Quebec, Canada H3C 3X6 imetrik.com _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/7ad412ac/attachment-0001.html From sthorger at redhat.com Thu Oct 1 10:34:47 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 1 Oct 2015 16:34:47 +0200 Subject: [keycloak-dev] Admin REST - User Roles In-Reply-To: References: <560BB7AC.6040501@redhat.com> Message-ID: Is that the json sent on the wire, or is it after you've marshalled it to UserRepresentation and then printed it back again? On 1 October 2015 at 15:34, Remi Cartier wrote: > yes, > > I can see : > > [ > { > "applicationRoles": null, > "attributes": { > "key1": [ > "value1" > ] > }, > "clientConsents": null, > "clientRoles": null, > "createdTimestamp": 1443542144845, > "credentials": null, > "email": null, > "emailVerified": true, > "enabled": true, > "federatedIdentities": null, > "federationLink": null, > "firstName": "first name", > "id": "0556717e-ffb9-4c2d-b85b-533d9396f243", > "lastName": "last name", > "realmRoles": null, > "requiredActions": [], > "self": null, > "serviceAccountClientId": null, > "socialLinks": null, > "totp": false, > "username": "admin" > } > ] > > when doing the query : GET /auth/admin/realms/imetrik/users?first=0&max= > 2147483647 > > ------------------------------ > > > REMI CARTIER > B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) > > *IMETRIK GLOBAL INC.* > *T :* +1 514 448-6407 x2009 > *T :* +1 866 276-5382 (toll free) > *F :* +1 514 904-0611 > > 740 Notre Dame St. West, Suite 1575 > Montreal, Quebec, Canada H3C 3X6 > imetrik.com > > On Oct 1, 2015, at 2:49 AM, Stian Thorgersen wrote: > > Sorry, I meant does it include the "roles" field? > > On 30 September 2015 at 16:24, Remi Cartier > wrote: > >> The JSON response (string) does NOT contain any roles. >> >> ------------------------------ >> *From:* Stian Thorgersen [sthorger at redhat.com] >> *Sent:* Wednesday, September 30, 2015 7:39 AM >> *To:* Remi Cartier >> *Cc:* Marek Posolda; keycloak-dev at lists.jboss.org >> >> *Subject:* Re: [keycloak-dev] Admin REST - User Roles >> >> Does the response actually contain the roles though? You're parsing to UserRepresentation >> then printing it out afterwards. >> >> On 30 September 2015 at 13:24, Remi Cartier >> wrote: >> >>> Marek, >>> >>> I see, thank you for your reply. >>> >>> Wouldn't it be less error/question prone if the endpoint returning all >>> the users wouldn't show the *roles attributes ? >>> Because they will always be null if I understood correctly. >>> >>> Regards. >>> >>> R?mi. >>> >>> ------------------------------ >>> *From:* Marek Posolda [mposolda at redhat.com] >>> *Sent:* Wednesday, September 30, 2015 6:21 AM >>> *To:* Remi Cartier; keycloak-dev at lists.jboss.org >>> *Subject:* Re: [keycloak-dev] Admin REST - User Roles >>> >>> Hi, >>> >>> to retrieve realm role mappings of user, you need to use the endpoint >>> like http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm >>> . See the docs for details: >>> http://keycloak.github.io/docs/rest-api/overview-index.html >>> >>> Marek >>> >>> On 29/09/15 19:06, Remi Cartier wrote: >>> >>> Hi guys, >>> >>> first of all, thank you for that great piece of software, it?s amazing ! >>> >>> Now, down to business. >>> >>> When I do : >>> >>> keycloak = Keycloak.getInstance(getKeycloakServerURL(), >>> getKeycloakRealm(), getKeycloakRealmAdminUsername(), >>> getKeycloakRealmAdminPassword(), getKeycloakClientId()); >>> for (UserRepresentation userRepresentation : >>> keycloak.realm(getKeycloakRealm()).users().search(null, 0, >>> Integer.MAX_VALUE)) { >>> log.info(ToStringBuilder.reflectionToString(userRepresentation, >>> ToStringStyle.JSON_STYLE)); >>> } >>> >>> The information I get does not contain any roles, all the roles related >>> fields are ?null?. - >>> >>> {"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first >>> name","lastName":"last >>> name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null} >>> However in the admin interface I have setup roles at each layer : realm, >>> client >>> >>> The user I am using to do the queries has all the *realm* roles >>> associated. >>> >>> is there anything else I need to do ? >>> >>> thank you for your help ! >>> >>> ------------------------------ >>> >>> >>> REMI CARTIER >>> B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) >>> >>> *IMETRIK GLOBAL INC.* >>> *T :* +1 514 448-6407 x2009 >>> *T :* +1 866 276-5382 (toll free) >>> *F :* +1 514 904-0611 >>> >>> 740 Notre Dame St. West, Suite 1575 >>> Montreal, Quebec, Canada H3C 3X6 >>> imetrik.com >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/7b717f5e/attachment-0001.html From sthorger at redhat.com Thu Oct 1 10:37:51 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 1 Oct 2015 16:37:51 +0200 Subject: [keycloak-dev] Admin REST - User Roles In-Reply-To: References: <560BB7AC.6040501@redhat.com> Message-ID: Just tried it and the returned json for a user is: {"id":"354094d6-8b32-4c32-b1ae-ccd82c5fdca3","createdTimestamp":1443710165680,"username":"admin","enabled":true,"totp":false,"emailVerified":false,"attributes":{"locale":["en"]},"requiredActions":[]} Which doesn't include the roles field. So this is shown because the way you are printing the user, not because it's included on the wire. On 1 October 2015 at 16:34, Stian Thorgersen wrote: > Is that the json sent on the wire, or is it after you've marshalled it to > UserRepresentation and then printed it back again? > > On 1 October 2015 at 15:34, Remi Cartier wrote: > >> yes, >> >> I can see : >> >> [ >> { >> "applicationRoles": null, >> "attributes": { >> "key1": [ >> "value1" >> ] >> }, >> "clientConsents": null, >> "clientRoles": null, >> "createdTimestamp": 1443542144845, >> "credentials": null, >> "email": null, >> "emailVerified": true, >> "enabled": true, >> "federatedIdentities": null, >> "federationLink": null, >> "firstName": "first name", >> "id": "0556717e-ffb9-4c2d-b85b-533d9396f243", >> "lastName": "last name", >> "realmRoles": null, >> "requiredActions": [], >> "self": null, >> "serviceAccountClientId": null, >> "socialLinks": null, >> "totp": false, >> "username": "admin" >> } >> ] >> >> when doing the query : GET /auth/admin/realms/imetrik/users?first=0&max= >> 2147483647 >> >> ------------------------------ >> >> >> REMI CARTIER >> B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) >> >> *IMETRIK GLOBAL INC.* >> *T :* +1 514 448-6407 x2009 >> *T :* +1 866 276-5382 (toll free) >> *F :* +1 514 904-0611 >> >> 740 Notre Dame St. West, Suite 1575 >> Montreal, Quebec, Canada H3C 3X6 >> imetrik.com >> >> On Oct 1, 2015, at 2:49 AM, Stian Thorgersen wrote: >> >> Sorry, I meant does it include the "roles" field? >> >> On 30 September 2015 at 16:24, Remi Cartier >> wrote: >> >>> The JSON response (string) does NOT contain any roles. >>> >>> ------------------------------ >>> *From:* Stian Thorgersen [sthorger at redhat.com] >>> *Sent:* Wednesday, September 30, 2015 7:39 AM >>> *To:* Remi Cartier >>> *Cc:* Marek Posolda; keycloak-dev at lists.jboss.org >>> >>> *Subject:* Re: [keycloak-dev] Admin REST - User Roles >>> >>> Does the response actually contain the roles though? You're parsing to UserRepresentation >>> then printing it out afterwards. >>> >>> On 30 September 2015 at 13:24, Remi Cartier >>> wrote: >>> >>>> Marek, >>>> >>>> I see, thank you for your reply. >>>> >>>> Wouldn't it be less error/question prone if the endpoint returning all >>>> the users wouldn't show the *roles attributes ? >>>> Because they will always be null if I understood correctly. >>>> >>>> Regards. >>>> >>>> R?mi. >>>> >>>> ------------------------------ >>>> *From:* Marek Posolda [mposolda at redhat.com] >>>> *Sent:* Wednesday, September 30, 2015 6:21 AM >>>> *To:* Remi Cartier; keycloak-dev at lists.jboss.org >>>> *Subject:* Re: [keycloak-dev] Admin REST - User Roles >>>> >>>> Hi, >>>> >>>> to retrieve realm role mappings of user, you need to use the endpoint >>>> like http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm >>>> . See the docs for details: >>>> http://keycloak.github.io/docs/rest-api/overview-index.html >>>> >>>> Marek >>>> >>>> On 29/09/15 19:06, Remi Cartier wrote: >>>> >>>> Hi guys, >>>> >>>> first of all, thank you for that great piece of software, it?s amazing ! >>>> >>>> Now, down to business. >>>> >>>> When I do : >>>> >>>> keycloak = Keycloak.getInstance(getKeycloakServerURL(), >>>> getKeycloakRealm(), getKeycloakRealmAdminUsername(), >>>> getKeycloakRealmAdminPassword(), getKeycloakClientId()); >>>> for (UserRepresentation userRepresentation : >>>> keycloak.realm(getKeycloakRealm()).users().search(null, 0, >>>> Integer.MAX_VALUE)) { >>>> log.info(ToStringBuilder.reflectionToString(userRepresentation, >>>> ToStringStyle.JSON_STYLE)); >>>> } >>>> >>>> The information I get does not contain any roles, all the roles related >>>> fields are ?null?. - >>>> >>>> {"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first >>>> name","lastName":"last >>>> name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null} >>>> However in the admin interface I have setup roles at each layer : >>>> realm, client >>>> >>>> The user I am using to do the queries has all the *realm* roles >>>> associated. >>>> >>>> is there anything else I need to do ? >>>> >>>> thank you for your help ! >>>> >>>> ------------------------------ >>>> >>>> >>>> REMI CARTIER >>>> B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) >>>> >>>> *IMETRIK GLOBAL INC.* >>>> *T :* +1 514 448-6407 x2009 >>>> *T :* +1 866 276-5382 (toll free) >>>> *F :* +1 514 904-0611 >>>> >>>> 740 Notre Dame St. West, Suite 1575 >>>> Montreal, Quebec, Canada H3C 3X6 >>>> imetrik.com >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/fa25be50/attachment-0001.html From remi.cartier at imetrik.com Thu Oct 1 10:55:24 2015 From: remi.cartier at imetrik.com (Remi Cartier) Date: Thu, 1 Oct 2015 14:55:24 +0000 Subject: [keycloak-dev] Admin REST - User Roles In-Reply-To: References: <560BB7AC.6040501@redhat.com> Message-ID: <32954D20-AC4C-4A23-962E-D036112BB6E2@imetrik.com> Stian, that?s actually what I am receiving over the wire. Here is the full log of the communication : 16:18:58.472 [main] DEBUG org.apache.http.headers - >> GET /auth/admin/realms/imetrik/users?first=0&max=2147483647 HTTP/1.1 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Accept: application/json 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Accept-Encoding: gzip, deflate 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhZjk4OTY2OS03YmIwLTRkYjgtOTNiNC0xYWI5NmU1MzgyY2UiLCJleHAiOjE0NDM1NTgyMTEsIm5iZiI6MCwiaWF0IjoxNDQzNTU3OTExLCJpc3MiOiJodHRwOi8vbTRpYi1pZG06ODA4MC9hdXRoL3JlYWxtcy9pbWV0cmlrIiwiYXVkIjoidWJpX2RyaXZlciIsInN1YiI6IjA1NTY3MTdlLWZmYjktNGMyZC1iODViLTUzM2Q5Mzk2ZjI0MyIsImF6cCI6InViaV9kcml2ZXIiLCJzZXNzaW9uX3N0YXRlIjoiMDQyNTdlY2EtMDAxMi00ZDU5LWFjMWItNWQ0NzI1MTFiMTc2IiwiY2xpZW50X3Nlc3Npb24iOiI5OGVkZjRkMC00MTk5LTRjODctYjY0OC1jYzhiYzI3MDhkMmUiLCJhbGxvd2VkLW9yaWdpbnMiOltdLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsicmVhbG0tcm9sZSJdfSwicmVzb3VyY2VfYWNjZXNzIjp7InViaV9kcml2ZXIiOnsicm9sZXMiOlsibWlsZWFnZSJdfSwicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtIiwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtZXZlbnRzIiwibWFuYWdlLXJlYWxtIiwibWFuYWdlLWlkZW50aXR5LXByb3ZpZGVycyIsImltcGVyc29uYXRpb24iLCJyZWFsbS1hZG1pbiIsInZpZXctZXZlbnRzIiwibWFuYWdlLXVzZXJzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50Iiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6ImZpcnN0IG5hbWUgbGFzdCBuYW1lIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYWRtaW4iLCJnaXZlbl9uYW1lIjoiZmlyc3QgbmFtZSIsImZhbWlseV9uYW1lIjoibGFzdCBuYW1lIn0.Px7tQJ8TV7ba9urpdNUq-HXul01CebvwSe6mpusMzLmIBJUdlzIJnzXyiuz4_AD9vwdYc5KCMHQ8LbucDs5ZrDYx5JQVJEIAQq6_q7d8hsE2gwp0SPejHvtJgki-hDRiuVlp-8lYGLQ6oJ_ipc6GBeVoaxQU8mmBEailh_rxpRwlXSNkef-r_ixzVwY3EQ5K55V2ivYFLmgEbi4mp7dU1FlzsAlvUOuJzbhVo-pyi0iQBjsvca8IJSIKQetCFxvTNXPIQUk5-bBI96_MOFYyoTenCs2m2ygEBDWB8GabrszAPLGEHEEJ2IgXIEK1kditZ7rXNm-ZgcVGYiBbzhVprQ 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Host: m4ib-idm:8080 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Connection: Keep-Alive 16:18:58.478 [main] DEBUG org.apache.http.wire - << "HTTP/1.1 200 OK[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Connection: keep-alive[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Cache-Control: no-cache[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "X-Powered-By: Undertow/1[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Server: WildFly/9[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Transfer-Encoding: chunked[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Content-Type: application/json[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Date: Tue, 29 Sep 2015 20:18:31 GMT[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "[\r][\n]" 16:18:58.479 [main] DEBUG o.a.h.i.conn.DefaultClientConnection - Receiving response: HTTP/1.1 200 OK 16:18:58.479 [main] DEBUG org.apache.http.headers - << HTTP/1.1 200 OK 16:18:58.479 [main] DEBUG org.apache.http.headers - << Connection: keep-alive 16:18:58.479 [main] DEBUG org.apache.http.headers - << Cache-Control: no-cache 16:18:58.479 [main] DEBUG org.apache.http.headers - << X-Powered-By: Undertow/1 16:18:58.479 [main] DEBUG org.apache.http.headers - << Server: WildFly/9 16:18:58.479 [main] DEBUG org.apache.http.headers - << Transfer-Encoding: chunked 16:18:58.479 [main] DEBUG org.apache.http.headers - << Content-Type: application/json 16:18:58.479 [main] DEBUG org.apache.http.headers - << Date: Tue, 29 Sep 2015 20:18:31 GMT 16:18:58.479 [main] DEBUG o.a.h.impl.client.DefaultHttpClient - Connection can be kept alive indefinitely 16:18:58.480 [main] DEBUG org.apache.http.wire - << "01db[\r][\n]" 16:18:58.480 [main] DEBUG org.apache.http.wire - << "[{"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first name","lastName":"last name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{"key1":["value1"]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null}]" 16:18:58.552 [main] DEBUG org.apache.http.wire - << "[\r][\n]" 16:18:58.552 [main] DEBUG org.apache.http.wire - << "0[\r][\n]" 16:18:58.552 [main] DEBUG org.apache.http.wire - << "[\r][\n]" 16:18:58.552 [main] DEBUG o.a.h.i.c.BasicClientConnectionManager - Releasing connection org.apache.http.impl.conn.ManagedClientConnectionImpl at 483f6d77 16:18:58.552 [main] DEBUG o.a.h.i.c.BasicClientConnectionManager - Connection can be kept alive indefinitely Regards. ________________________________ REMI CARTIER B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) IMETRIK GLOBAL INC. T : +1 514 448-6407 x2009 T : +1 866 276-5382 (toll free) F : +1 514 904-0611 740 Notre Dame St. West, Suite 1575 Montreal, Quebec, Canada H3C 3X6 imetrik.com On Oct 1, 2015, at 10:37 AM, Stian Thorgersen > wrote: Just tried it and the returned json for a user is: {"id":"354094d6-8b32-4c32-b1ae-ccd82c5fdca3","createdTimestamp":1443710165680,"username":"admin","enabled":true,"totp":false,"emailVerified":false,"attributes":{"locale":["en"]},"requiredActions":[]} Which doesn't include the roles field. So this is shown because the way you are printing the user, not because it's included on the wire. On 1 October 2015 at 16:34, Stian Thorgersen > wrote: Is that the json sent on the wire, or is it after you've marshalled it to UserRepresentation and then printed it back again? On 1 October 2015 at 15:34, Remi Cartier > wrote: yes, I can see : [ { "applicationRoles": null, "attributes": { "key1": [ "value1" ] }, "clientConsents": null, "clientRoles": null, "createdTimestamp": 1443542144845, "credentials": null, "email": null, "emailVerified": true, "enabled": true, "federatedIdentities": null, "federationLink": null, "firstName": "first name", "id": "0556717e-ffb9-4c2d-b85b-533d9396f243", "lastName": "last name", "realmRoles": null, "requiredActions": [], "self": null, "serviceAccountClientId": null, "socialLinks": null, "totp": false, "username": "admin" } ] when doing the query : GET /auth/admin/realms/imetrik/users?first=0&max=2147483647 ________________________________ REMI CARTIER B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) IMETRIK GLOBAL INC. T : +1 514 448-6407 x2009 T : +1 866 276-5382 (toll free) F : +1 514 904-0611 740 Notre Dame St. West, Suite 1575 Montreal, Quebec, Canada H3C 3X6 imetrik.com On Oct 1, 2015, at 2:49 AM, Stian Thorgersen > wrote: Sorry, I meant does it include the "roles" field? On 30 September 2015 at 16:24, Remi Cartier > wrote: The JSON response (string) does NOT contain any roles. ________________________________ From: Stian Thorgersen [sthorger at redhat.com] Sent: Wednesday, September 30, 2015 7:39 AM To: Remi Cartier Cc: Marek Posolda; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Admin REST - User Roles Does the response actually contain the roles though? You're parsing to UserRepresentation then printing it out afterwards. On 30 September 2015 at 13:24, Remi Cartier > wrote: Marek, I see, thank you for your reply. Wouldn't it be less error/question prone if the endpoint returning all the users wouldn't show the *roles attributes ? Because they will always be null if I understood correctly. Regards. R?mi. ________________________________ From: Marek Posolda [mposolda at redhat.com] Sent: Wednesday, September 30, 2015 6:21 AM To: Remi Cartier; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Admin REST - User Roles Hi, to retrieve realm role mappings of user, you need to use the endpoint like http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm . See the docs for details: http://keycloak.github.io/docs/rest-api/overview-index.html Marek On 29/09/15 19:06, Remi Cartier wrote: Hi guys, first of all, thank you for that great piece of software, it?s amazing ! Now, down to business. When I do : keycloak = Keycloak.getInstance(getKeycloakServerURL(), getKeycloakRealm(), getKeycloakRealmAdminUsername(), getKeycloakRealmAdminPassword(), getKeycloakClientId()); for (UserRepresentation userRepresentation : keycloak.realm(getKeycloakRealm()).users().search(null, 0, Integer.MAX_VALUE)) { log.info(ToStringBuilder.reflectionToString(userRepresentation, ToStringStyle.JSON_STYLE)); } The information I get does not contain any roles, all the roles related fields are ?null?. - {"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first name","lastName":"last name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null} However in the admin interface I have setup roles at each layer : realm, client The user I am using to do the queries has all the *realm* roles associated. is there anything else I need to do ? thank you for your help ! ________________________________ REMI CARTIER B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) IMETRIK GLOBAL INC. T : +1 514 448-6407 x2009 T : +1 866 276-5382 (toll free) F : +1 514 904-0611 740 Notre Dame St. West, Suite 1575 Montreal, Quebec, Canada H3C 3X6 imetrik.com _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151001/c3d8e66e/attachment-0001.html From bburke at redhat.com Thu Oct 1 14:49:06 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 1 Oct 2015 14:49:06 -0400 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> Message-ID: <560D8022.90004@redhat.com> Sorry for late reply. On 10/1/2015 3:13 AM, Stian Thorgersen wrote: > * If a user that was logged in using Kerberos logs out the user should > not just be automatically logged-in again for the current browser > session. Instead the user should be displayed with a regular > username/password field, but also with an option to login with Kerberos Don't like this idea. #1 Users that want to bypass kerberos have to know to logout first so they can login as a non-kerberos user. #2 username/password screen would have to have knowledge that kerberos is turned on and that the user was logged in via kerberos. I'm don't think this is possible with the current SPI. > * A variant on the above where if a user has logged-out from Kerberos > the user would be displayed with a "Is this you?" when login, if the > user selects yes the Kerberos authenticator would continue, if not the > regular username/password form would be displayed This one might be easy to do with current SPI although not sure if kerberos plugin sets some session variables that need to be cleared. > * Implement account switcher - where a user can login to multiple > accounts at a time and select which account to use > Not sure how this is different than "Is this you?". > Other ideas? Points for ideas that requires no hacks in applications ;) > idp_hint is a much different animal, isn't it? idp_hint is provided by the application. skip_auth_mechanism would be something the user has to know about to type in the URL right? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Thu Oct 1 14:58:25 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 1 Oct 2015 14:58:25 -0400 Subject: [keycloak-dev] added a keycloak-common module Message-ID: <560D8251.307@redhat.com> The SAML adapter had some dependencies on classes within keycloak-core. Unfortunately though, keycloak-core brings in Jackson JSON parser. So, I split out keycloak-core into keycloak-common and keycloak-core. PR is pending, but it should be in when the Europeans wake up. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Fri Oct 2 02:31:03 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 2 Oct 2015 08:31:03 +0200 Subject: [keycloak-dev] Admin REST - User Roles In-Reply-To: <32954D20-AC4C-4A23-962E-D036112BB6E2@imetrik.com> References: <560BB7AC.6040501@redhat.com> <32954D20-AC4C-4A23-962E-D036112BB6E2@imetrik.com> Message-ID: Looks like there's a difference if you return a specific user or search for users. Returning a user doesn't include null values, while search does. Created https://issues.jboss.org/browse/KEYCLOAK-1896 On 1 October 2015 at 16:55, Remi Cartier wrote: > Stian, > > that?s actually what I am receiving over the wire. Here is the full log of > the communication : > > 16:18:58.472 [main] DEBUG org.apache.http.headers - >> GET > /auth/admin/realms/imetrik/users?first=0&max=2147483647 HTTP/1.1 > 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Accept: > application/json > 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Accept-Encoding: > gzip, deflate > 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Authorization: > Bearer > eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhZjk4OTY2OS03YmIwLTRkYjgtOTNiNC0xYWI5NmU1MzgyY2UiLCJleHAiOjE0NDM1NTgyMTEsIm5iZiI6MCwiaWF0IjoxNDQzNTU3OTExLCJpc3MiOiJodHRwOi8vbTRpYi1pZG06ODA4MC9hdXRoL3JlYWxtcy9pbWV0cmlrIiwiYXVkIjoidWJpX2RyaXZlciIsInN1YiI6IjA1NTY3MTdlLWZmYjktNGMyZC1iODViLTUzM2Q5Mzk2ZjI0MyIsImF6cCI6InViaV9kcml2ZXIiLCJzZXNzaW9uX3N0YXRlIjoiMDQyNTdlY2EtMDAxMi00ZDU5LWFjMWItNWQ0NzI1MTFiMTc2IiwiY2xpZW50X3Nlc3Npb24iOiI5OGVkZjRkMC00MTk5LTRjODctYjY0OC1jYzhiYzI3MDhkMmUiLCJhbGxvd2VkLW9yaWdpbnMiOltdLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsicmVhbG0tcm9sZSJdfSwicmVzb3VyY2VfYWNjZXNzIjp7InViaV9kcml2ZXIiOnsicm9sZXMiOlsibWlsZWFnZSJdfSwicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtIiwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtZXZlbnRzIiwibWFuYWdlLXJlYWxtIiwibWFuYWdlLWlkZW50aXR5LXByb3ZpZGVycyIsImltcGVyc29uYXRpb24iLCJyZWFsbS1hZG1pbiIsInZpZXctZXZlbnRzIiwibWFuYWdlLXVzZXJzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50Iiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6ImZpcnN0IG5hbWUgbGFzdCBuYW1lIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYWRtaW4iLCJnaXZlbl9uYW1lIjoiZmlyc3QgbmFtZSIsImZhbWlseV9uYW1lIjoibGFzdCBuYW1lIn0.Px7tQJ8TV7ba9urpdNUq-HXul01CebvwSe6mpusMzLmIBJUdlzIJnzXyiuz4_AD9vwdYc5KCMHQ8LbucDs5ZrDYx5JQVJEIAQq6_q7d8hsE2gwp0SPejHvtJgki-hDRiuVlp-8lYGLQ6oJ_ipc6GBeVoaxQU8mmBEailh_rxpRwlXSNkef-r_ixzVwY3EQ5K55V2ivYFLmgEbi4mp7dU1FlzsAlvUOuJzbhVo-pyi0iQBjsvca8IJSIKQetCFxvTNXPIQUk5-bBI96_MOFYyoTenCs2m2ygEBDWB8GabrszAPLGEHEEJ2IgXIEK1kditZ7rXNm-ZgcVGYiBbzhVprQ > 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Host: m4ib-idm:8080 > 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Connection: > Keep-Alive > 16:18:58.478 [main] DEBUG org.apache.http.wire - << "HTTP/1.1 200 > OK[\r][\n]" > 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Connection: > keep-alive[\r][\n]" > 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Cache-Control: > no-cache[\r][\n]" > 16:18:58.479 [main] DEBUG org.apache.http.wire - << "X-Powered-By: > Undertow/1[\r][\n]" > 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Server: > WildFly/9[\r][\n]" > 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Transfer-Encoding: > chunked[\r][\n]" > 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Content-Type: > application/json[\r][\n]" > 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Date: Tue, 29 Sep > 2015 20:18:31 GMT[\r][\n]" > 16:18:58.479 [main] DEBUG org.apache.http.wire - << "[\r][\n]" > 16:18:58.479 [main] DEBUG o.a.h.i.conn.DefaultClientConnection - Receiving > response: HTTP/1.1 200 OK > 16:18:58.479 [main] DEBUG org.apache.http.headers - << HTTP/1.1 200 OK > 16:18:58.479 [main] DEBUG org.apache.http.headers - << Connection: > keep-alive > 16:18:58.479 [main] DEBUG org.apache.http.headers - << Cache-Control: > no-cache > 16:18:58.479 [main] DEBUG org.apache.http.headers - << X-Powered-By: > Undertow/1 > 16:18:58.479 [main] DEBUG org.apache.http.headers - << Server: WildFly/9 > 16:18:58.479 [main] DEBUG org.apache.http.headers - << Transfer-Encoding: > chunked > 16:18:58.479 [main] DEBUG org.apache.http.headers - << Content-Type: > application/json > 16:18:58.479 [main] DEBUG org.apache.http.headers - << Date: Tue, 29 Sep > 2015 20:18:31 GMT > 16:18:58.479 [main] DEBUG o.a.h.impl.client.DefaultHttpClient - Connection > can be kept alive indefinitely > 16:18:58.480 [main] DEBUG org.apache.http.wire - << "01db[\r][\n]" > 16:18:58.480 [main] DEBUG org.apache.http.wire - << > "[{"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first > name","lastName":"last > name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{"key1":["value1"]},"credentials":null,"requiredActions":[],"federatedIdentities":null, > "realmRoles":null,"clientRoles":null,"clientConsents":null, > "applicationRoles":null,"socialLinks":null}]" > 16:18:58.552 [main] DEBUG org.apache.http.wire - << "[\r][\n]" > 16:18:58.552 [main] DEBUG org.apache.http.wire - << "0[\r][\n]" > 16:18:58.552 [main] DEBUG org.apache.http.wire - << "[\r][\n]" > 16:18:58.552 [main] DEBUG o.a.h.i.c.BasicClientConnectionManager - > Releasing connection > org.apache.http.impl.conn.ManagedClientConnectionImpl at 483f6d77 > 16:18:58.552 [main] DEBUG o.a.h.i.c.BasicClientConnectionManager - > Connection can be kept alive indefinitely > > Regards. > > ------------------------------ > > > REMI CARTIER > B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) > > *IMETRIK GLOBAL INC.* > *T :* +1 514 448-6407 x2009 > *T :* +1 866 276-5382 (toll free) > *F :* +1 514 904-0611 > > 740 Notre Dame St. West, Suite 1575 > Montreal, Quebec, Canada H3C 3X6 > imetrik.com > > On Oct 1, 2015, at 10:37 AM, Stian Thorgersen wrote: > > Just tried it and the returned json for a user is: > > > {"id":"354094d6-8b32-4c32-b1ae-ccd82c5fdca3","createdTimestamp":1443710165680,"username":"admin","enabled":true,"totp":false,"emailVerified":false,"attributes":{"locale":["en"]},"requiredActions":[]} > > Which doesn't include the roles field. So this is shown because the way > you are printing the user, not because it's included on the wire. > > On 1 October 2015 at 16:34, Stian Thorgersen wrote: > >> Is that the json sent on the wire, or is it after you've marshalled it to >> UserRepresentation and then printed it back again? >> >> On 1 October 2015 at 15:34, Remi Cartier >> wrote: >> >>> yes, >>> >>> I can see : >>> >>> [ >>> { >>> "applicationRoles": null, >>> "attributes": { >>> "key1": [ >>> "value1" >>> ] >>> }, >>> "clientConsents": null, >>> "clientRoles": null, >>> "createdTimestamp": 1443542144845, >>> "credentials": null, >>> "email": null, >>> "emailVerified": true, >>> "enabled": true, >>> "federatedIdentities": null, >>> "federationLink": null, >>> "firstName": "first name", >>> "id": "0556717e-ffb9-4c2d-b85b-533d9396f243", >>> "lastName": "last name", >>> "realmRoles": null, >>> "requiredActions": [], >>> "self": null, >>> "serviceAccountClientId": null, >>> "socialLinks": null, >>> "totp": false, >>> "username": "admin" >>> } >>> ] >>> >>> when doing the query : GET /auth/admin/realms/imetrik/users?first=0&max= >>> 2147483647 >>> >>> ------------------------------ >>> >>> >>> REMI CARTIER >>> B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) >>> >>> *IMETRIK GLOBAL INC.* >>> *T :* +1 514 448-6407 x2009 >>> *T :* +1 866 276-5382 (toll free) >>> *F :* +1 514 904-0611 >>> >>> 740 Notre Dame St. West, Suite 1575 >>> Montreal, Quebec, Canada H3C 3X6 >>> imetrik.com >>> >>> On Oct 1, 2015, at 2:49 AM, Stian Thorgersen >>> wrote: >>> >>> Sorry, I meant does it include the "roles" field? >>> >>> On 30 September 2015 at 16:24, Remi Cartier >>> wrote: >>> >>>> The JSON response (string) does NOT contain any roles. >>>> >>>> ------------------------------ >>>> *From:* Stian Thorgersen [sthorger at redhat.com] >>>> *Sent:* Wednesday, September 30, 2015 7:39 AM >>>> *To:* Remi Cartier >>>> *Cc:* Marek Posolda; keycloak-dev at lists.jboss.org >>>> >>>> *Subject:* Re: [keycloak-dev] Admin REST - User Roles >>>> >>>> Does the response actually contain the roles though? You're parsing to UserRepresentation >>>> then printing it out afterwards. >>>> >>>> On 30 September 2015 at 13:24, Remi Cartier >>>> wrote: >>>> >>>>> Marek, >>>>> >>>>> I see, thank you for your reply. >>>>> >>>>> Wouldn't it be less error/question prone if the endpoint returning all >>>>> the users wouldn't show the *roles attributes ? >>>>> Because they will always be null if I understood correctly. >>>>> >>>>> Regards. >>>>> >>>>> R?mi. >>>>> >>>>> ------------------------------ >>>>> *From:* Marek Posolda [mposolda at redhat.com] >>>>> *Sent:* Wednesday, September 30, 2015 6:21 AM >>>>> *To:* Remi Cartier; keycloak-dev at lists.jboss.org >>>>> *Subject:* Re: [keycloak-dev] Admin REST - User Roles >>>>> >>>>> Hi, >>>>> >>>>> to retrieve realm role mappings of user, you need to use the endpoint >>>>> like http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm >>>>> . See the docs for details: >>>>> http://keycloak.github.io/docs/rest-api/overview-index.html >>>>> >>>>> Marek >>>>> >>>>> On 29/09/15 19:06, Remi Cartier wrote: >>>>> >>>>> Hi guys, >>>>> >>>>> first of all, thank you for that great piece of software, it?s amazing >>>>> ! >>>>> >>>>> Now, down to business. >>>>> >>>>> When I do : >>>>> >>>>> keycloak = Keycloak.getInstance(getKeycloakServerURL(), >>>>> getKeycloakRealm(), getKeycloakRealmAdminUsername(), >>>>> getKeycloakRealmAdminPassword(), getKeycloakClientId()); >>>>> for (UserRepresentation userRepresentation : >>>>> keycloak.realm(getKeycloakRealm()).users().search(null, 0, >>>>> Integer.MAX_VALUE)) { >>>>> log.info(ToStringBuilder.reflectionToString(userRepresentation, >>>>> ToStringStyle.JSON_STYLE)); >>>>> } >>>>> >>>>> The information I get does not contain any roles, all the roles >>>>> related fields are ?null?. - >>>>> >>>>> {"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first >>>>> name","lastName":"last >>>>> name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null} >>>>> However in the admin interface I have setup roles at each layer : >>>>> realm, client >>>>> >>>>> The user I am using to do the queries has all the *realm* roles >>>>> associated. >>>>> >>>>> is there anything else I need to do ? >>>>> >>>>> thank you for your help ! >>>>> >>>>> ------------------------------ >>>>> >>>>> >>>>> REMI CARTIER >>>>> B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) >>>>> >>>>> *IMETRIK GLOBAL INC.* >>>>> *T :* +1 514 448-6407 x2009 >>>>> *T :* +1 866 276-5382 (toll free) >>>>> *F :* +1 514 904-0611 >>>>> >>>>> 740 Notre Dame St. West, Suite 1575 >>>>> Montreal, Quebec, Canada H3C 3X6 >>>>> imetrik.com >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>> >>> >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/87ade010/attachment-0001.html From mposolda at redhat.com Fri Oct 2 02:37:22 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 2 Oct 2015 08:37:22 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <560D8022.90004@redhat.com> References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560D8022.90004@redhat.com> Message-ID: <560E2622.3060203@redhat.com> On 01/10/15 20:49, Bill Burke wrote: > Sorry for late reply. > > On 10/1/2015 3:13 AM, Stian Thorgersen wrote: >> * If a user that was logged in using Kerberos logs out the user should >> not just be automatically logged-in again for the current browser >> session. Instead the user should be displayed with a regular >> username/password field, but also with an option to login with Kerberos > Don't like this idea. > > #1 Users that want to bypass kerberos have to know to logout first so > they can login as a non-kerberos user. > > #2 username/password screen would have to have knowledge that kerberos > is turned on and that the user was logged in via kerberos. I'm don't > think this is possible with the current SPI. > >> * A variant on the above where if a user has logged-out from Kerberos >> the user would be displayed with a "Is this you?" when login, if the >> user selects yes the Kerberos authenticator would continue, if not the >> regular username/password form would be displayed > This one might be easy to do with current SPI although not sure if > kerberos plugin sets some session variables that need to be cleared. Yes, it can add the gss_delegation_credential note when Kerberos credential delegation is enabled. Looks that we may also need the non-persistent cookie added during logout, so the "Is this you" screen is not displayed for the first time login? > > >> * Implement account switcher - where a user can login to multiple >> accounts at a time and select which account to use >> > Not sure how this is different than "Is this you?". > >> Other ideas? Points for ideas that requires no hacks in applications ;) >> > idp_hint is a much different animal, isn't it? idp_hint is provided by > the application. skip_auth_mechanism would be something the user has to > know about to type in the URL right? > > > It's quite the same. Both allow application to send something to auth-server . Application can use secured URL with the param ( http://localhost/customer-portal/secured?kc_idp_hint=facebook or http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos ). Adapter then takes care of resend the parameter to auth-server in initial AuthorizationEndpoint request. In both cases, application can either provide the link or user can add the parameters manually. Marek From sthorger at redhat.com Fri Oct 2 02:49:08 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 2 Oct 2015 08:49:08 +0200 Subject: [keycloak-dev] added a keycloak-common module In-Reply-To: <560D8251.307@redhat.com> References: <560D8251.307@redhat.com> Message-ID: We need to reorganize the modules soon. Things make even less sense now. How about: * keycloak-common - common classes re-used by both client and server * keycloak-client-api - client specific interfaces * keycloak-server-api - server specific interfaces, including spi and providers Then we also would have: * keycloak-json - common json classes (json representations, jwt utils, etc.) * keycloak-oidc - common OpenID Connect classes * keycloak-saml - common SAML classes Most SPI implementations would be moved into keycloak-server, other than those that needs to be pluggable. The SPI implementations that should be in separate modules are: * Mongo * JPA - we can combine Liquibase and JPA into one * Social providers * Anything else? On 1 October 2015 at 20:58, Bill Burke wrote: > The SAML adapter had some dependencies on classes within keycloak-core. > Unfortunately though, keycloak-core brings in Jackson JSON parser. > So, I split out keycloak-core into keycloak-common and keycloak-core. > > PR is pending, but it should be in when the Europeans wake up. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/b7bf77ab/attachment.html From gerbermichi at me.com Fri Oct 2 04:58:04 2015 From: gerbermichi at me.com (Michael Gerber) Date: Fri, 02 Oct 2015 10:58:04 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <560E2622.3060203@redhat.com> References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560D8022.90004@redhat.com> <560E2622.3060203@redhat.com> Message-ID: <51B73F94-497C-4C15-A5EF-64912A00CE62@me.com> Maybe we can introduce both, a logout cookie and a query parameter to skip alternativ authenticators. The logout cookie will be set after a logout through keycloak (Logout URL) and the SpnegoAuthenticator offers a new configuration where you can configure if the logout cookie should be ignored or not. So you don?t have to do something ?special? in your application but you also have the possibility to create a URL for admins where they don?t have to logout first. How would you determine the user for the ?is this you?? Would you use the cookie for that or would you do a kerberos login? Michael Gerber Software Engineer Hammerweg 2 8304 Wallisellen Tel. 079 440 23 02 Mail gerbermichi at me.com > On 02.10.2015, at 08:37, Marek Posolda wrote: > > On 01/10/15 20:49, Bill Burke wrote: >> Sorry for late reply. >> >> On 10/1/2015 3:13 AM, Stian Thorgersen wrote: >>> * If a user that was logged in using Kerberos logs out the user should >>> not just be automatically logged-in again for the current browser >>> session. Instead the user should be displayed with a regular >>> username/password field, but also with an option to login with Kerberos >> Don't like this idea. >> >> #1 Users that want to bypass kerberos have to know to logout first so >> they can login as a non-kerberos user. >> >> #2 username/password screen would have to have knowledge that kerberos >> is turned on and that the user was logged in via kerberos. I'm don't >> think this is possible with the current SPI. >> >>> * A variant on the above where if a user has logged-out from Kerberos >>> the user would be displayed with a "Is this you?" when login, if the >>> user selects yes the Kerberos authenticator would continue, if not the >>> regular username/password form would be displayed >> This one might be easy to do with current SPI although not sure if >> kerberos plugin sets some session variables that need to be cleared. > Yes, it can add the gss_delegation_credential note when Kerberos > credential delegation is enabled. > > Looks that we may also need the non-persistent cookie added during > logout, so the "Is this you" screen is not displayed for the first time > login? >> >> >>> * Implement account switcher - where a user can login to multiple >>> accounts at a time and select which account to use >>> >> Not sure how this is different than "Is this you?". >> >>> Other ideas? Points for ideas that requires no hacks in applications ;) >>> >> idp_hint is a much different animal, isn't it? idp_hint is provided by >> the application. skip_auth_mechanism would be something the user has to >> know about to type in the URL right? >> >> >> > It's quite the same. Both allow application to send something to > auth-server . Application can use secured URL with the param ( > http://localhost/customer-portal/secured?kc_idp_hint=facebook or > http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos ). > Adapter then takes care of resend the parameter to auth-server in > initial AuthorizationEndpoint request. In both cases, application can > either provide the link or user can add the parameters manually. > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/a7905924/attachment-0001.html From sthorger at redhat.com Fri Oct 2 05:18:03 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 2 Oct 2015 11:18:03 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <51B73F94-497C-4C15-A5EF-64912A00CE62@me.com> References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560D8022.90004@redhat.com> <560E2622.3060203@redhat.com> <51B73F94-497C-4C15-A5EF-64912A00CE62@me.com> Message-ID: For the "Is this you?" mechanism I'd add a cookie at logout that contains user details and the authenticator that was used. We'd probably need to add an parameter to authenticators that can flag them as automatic login or not. Not sure why we would add both. If "Is this you" satisfies your requirements, there's no one requesting the other one. My concern with adding skip is that it's a custom query param we're introducing that may conflict with same functionality in OIDC, which we would then have to deprecate once we add a similar mechanism from OIDC. On 2 October 2015 at 10:58, Michael Gerber wrote: > Maybe we can introduce both, a logout cookie and a query parameter to skip > alternativ authenticators. > The logout cookie will be set after a logout through keycloak (Logout URL) > and the SpnegoAuthenticator offers a new configuration where you can > configure if the logout cookie should be ignored or not. > > So you don?t have to do something ?special? in your application but you > also have the possibility to create a URL for admins where they don?t have > to logout first. > > How would you determine the user for the ?is this you?? Would you use the > cookie for that or would you do a kerberos login? > > *Michael Gerber* > Software Engineer > > Hammerweg 2 > 8304 Wallisellen > > Tel. 079 440 23 02 > Mail gerbermichi at me.com > > > > > On 02.10.2015, at 08:37, Marek Posolda wrote: > > On 01/10/15 20:49, Bill Burke wrote: > > Sorry for late reply. > > On 10/1/2015 3:13 AM, Stian Thorgersen wrote: > > * If a user that was logged in using Kerberos logs out the user should > not just be automatically logged-in again for the current browser > session. Instead the user should be displayed with a regular > username/password field, but also with an option to login with Kerberos > > Don't like this idea. > > #1 Users that want to bypass kerberos have to know to logout first so > they can login as a non-kerberos user. > > #2 username/password screen would have to have knowledge that kerberos > is turned on and that the user was logged in via kerberos. I'm don't > think this is possible with the current SPI. > > * A variant on the above where if a user has logged-out from Kerberos > the user would be displayed with a "Is this you?" when login, if the > user selects yes the Kerberos authenticator would continue, if not the > regular username/password form would be displayed > > This one might be easy to do with current SPI although not sure if > kerberos plugin sets some session variables that need to be cleared. > > Yes, it can add the gss_delegation_credential note when Kerberos > credential delegation is enabled. > > Looks that we may also need the non-persistent cookie added during > logout, so the "Is this you" screen is not displayed for the first time > login? > > > > * Implement account switcher - where a user can login to multiple > accounts at a time and select which account to use > > Not sure how this is different than "Is this you?". > > Other ideas? Points for ideas that requires no hacks in applications ;) > > idp_hint is a much different animal, isn't it? idp_hint is provided by > the application. skip_auth_mechanism would be something the user has to > know about to type in the URL right? > > > > It's quite the same. Both allow application to send something to > auth-server . Application can use secured URL with the param ( > http://localhost/customer-portal/secured?kc_idp_hint=facebook or > http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos ). > Adapter then takes care of resend the parameter to auth-server in > initial AuthorizationEndpoint request. In both cases, application can > either provide the link or user can add the parameters manually. > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/e8d7e528/attachment.html From sthorger at redhat.com Fri Oct 2 05:26:00 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 2 Oct 2015 11:26:00 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <560D8022.90004@redhat.com> References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560D8022.90004@redhat.com> Message-ID: On 1 October 2015 at 20:49, Bill Burke wrote: > Sorry for late reply. > > On 10/1/2015 3:13 AM, Stian Thorgersen wrote: > > * If a user that was logged in using Kerberos logs out the user should > > not just be automatically logged-in again for the current browser > > session. Instead the user should be displayed with a regular > > username/password field, but also with an option to login with Kerberos > > Don't like this idea. > > #1 Users that want to bypass kerberos have to know to logout first so > they can login as a non-kerberos user. > > #2 username/password screen would have to have knowledge that kerberos > is turned on and that the user was logged in via kerberos. I'm don't > think this is possible with the current SPI. > Could we not have a selector or something in the authentication flow that can select which authenticator to use? The selector could even be allowed to prompt the user for input, so we could implement a "Is this you" selector. > > > * A variant on the above where if a user has logged-out from Kerberos > > the user would be displayed with a "Is this you?" when login, if the > > user selects yes the Kerberos authenticator would continue, if not the > > regular username/password form would be displayed > > This one might be easy to do with current SPI although not sure if > kerberos plugin sets some session variables that need to be cleared. > I was assuming that this option would also require user to logout first. "Is this you" would only be displayed after a logout. > > > > * Implement account switcher - where a user can login to multiple > > accounts at a time and select which account to use > > > > Not sure how this is different than "Is this you?". > "Is this you" would simply prompt the user if the user is the user that previously logged in from that browser. Account switcher would allow a user to be signed-in to Keycloak with multiple accounts and provide some mechanism for applications to select which account. Like GMail and others allow you to be logged-in to multiple accounts at a time. > > > Other ideas? Points for ideas that requires no hacks in applications ;) > > > > idp_hint is a much different animal, isn't it? idp_hint is provided by > the application. skip_auth_mechanism would be something the user has to > know about to type in the URL right? > We should never have added idp_hint in the first place IMO. It leaks authentication semantics into applications and also only works if user is not logged in already. skip_auth_mech could be implemented in applications as well, but my same point stands here. It requires applications to be aware of authentication semantics. It seems that what's being proposed here is that admins manually add it to the login URL though, but that's just a horrible idea, period. > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/d4d84614/attachment-0001.html From mposolda at redhat.com Fri Oct 2 05:33:20 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 2 Oct 2015 11:33:20 +0200 Subject: [keycloak-dev] added a keycloak-common module In-Reply-To: References: <560D8251.307@redhat.com> Message-ID: <560E4F60.8090806@redhat.com> On 02/10/15 08:49, Stian Thorgersen wrote: > We need to reorganize the modules soon. Things make even less sense now. > > How about: > > * keycloak-common - common classes re-used by both client and server > * keycloak-client-api - client specific interfaces > * keycloak-server-api - server specific interfaces, including spi and > providers > > Then we also would have: > * keycloak-json - common json classes (json representations, jwt > utils, etc.) > * keycloak-oidc - common OpenID Connect classes > * keycloak-saml - common SAML classes > > Most SPI implementations would be moved into keycloak-server, other > than those that needs to be pluggable. The SPI implementations that > should be in separate modules are: > > * Mongo > * JPA - we can combine Liquibase and JPA into one > * Social providers > * Anything else? LDAP and Kerberos federation providers? We don't want them to be available in "minimal" distribution right? But I am not sure as Kerberos authenticator is available by default in browser authenticationFlow (even if disabled by default). When someone enables it and LDAP/Kerberos federation provider is not available, it won't work. Marek > > > On 1 October 2015 at 20:58, Bill Burke > wrote: > > The SAML adapter had some dependencies on classes within > keycloak-core. > Unfortunately though, keycloak-core brings in Jackson JSON parser. > So, I split out keycloak-core into keycloak-common and keycloak-core. > > PR is pending, but it should be in when the Europeans wake up. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/778cd0e8/attachment.html From gerbermichi at me.com Fri Oct 2 05:37:04 2015 From: gerbermichi at me.com (Michael Gerber) Date: Fri, 02 Oct 2015 11:37:04 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560D8022.90004@redhat.com> <560E2622.3060203@redhat.com> <51B73F94-497C-4C15-A5EF-64912A00CE62@me.com> Message-ID: <045594E8-A6F1-4156-8E9C-397B1A9B0727@me.com> > On 02.10.2015, at 11:18, Stian Thorgersen wrote: > > For the "Is this you?" mechanism I'd add a cookie at logout that contains user details and the authenticator that was used. We?d probably need to add an parameter to authenticators that can flag them as automatic login or not. So basically you have to add the identity token of the user? Otherwise you can not trust the content of this cookie, right? Why do you want to include the authenticator? And which authenticator should that be? You don?t have to add a flag to the authenticator, you can simply create a helper which handles the whole ?is this you?? stuff and invoke this helper method from each authenticator (there is currently just one) > > Not sure why we would add both. If "Is this you" satisfies your requirements, there's no one requesting the other one. My concern with adding skip is that it?s a custom query param we're introducing that may conflict with same functionality in OIDC, which we would then have to deprecate once we add a similar mechanism from OIDC. Yeah I see. > > On 2 October 2015 at 10:58, Michael Gerber > wrote: > Maybe we can introduce both, a logout cookie and a query parameter to skip alternativ authenticators. > The logout cookie will be set after a logout through keycloak (Logout URL) and the SpnegoAuthenticator offers a new configuration where you can configure if the logout cookie should be ignored or not. > > So you don?t have to do something ?special? in your application but you also have the possibility to create a URL for admins where they don?t have to logout first. > > How would you determine the user for the ?is this you?? Would you use the cookie for that or would you do a kerberos login? > > Michael Gerber > Software Engineer > > Hammerweg 2 > 8304 Wallisellen > > Tel. 079 440 23 02 > Mail gerbermichi at me.com > > > > >> On 02.10.2015, at 08:37, Marek Posolda > wrote: >> >> On 01/10/15 20:49, Bill Burke wrote: >>> Sorry for late reply. >>> >>> On 10/1/2015 3:13 AM, Stian Thorgersen wrote: >>>> * If a user that was logged in using Kerberos logs out the user should >>>> not just be automatically logged-in again for the current browser >>>> session. Instead the user should be displayed with a regular >>>> username/password field, but also with an option to login with Kerberos >>> Don't like this idea. >>> >>> #1 Users that want to bypass kerberos have to know to logout first so >>> they can login as a non-kerberos user. >>> >>> #2 username/password screen would have to have knowledge that kerberos >>> is turned on and that the user was logged in via kerberos. I'm don't >>> think this is possible with the current SPI. >>> >>>> * A variant on the above where if a user has logged-out from Kerberos >>>> the user would be displayed with a "Is this you?" when login, if the >>>> user selects yes the Kerberos authenticator would continue, if not the >>>> regular username/password form would be displayed >>> This one might be easy to do with current SPI although not sure if >>> kerberos plugin sets some session variables that need to be cleared. >> Yes, it can add the gss_delegation_credential note when Kerberos >> credential delegation is enabled. >> >> Looks that we may also need the non-persistent cookie added during >> logout, so the "Is this you" screen is not displayed for the first time >> login? >>> >>> >>>> * Implement account switcher - where a user can login to multiple >>>> accounts at a time and select which account to use >>>> >>> Not sure how this is different than "Is this you?". >>> >>>> Other ideas? Points for ideas that requires no hacks in applications ;) >>>> >>> idp_hint is a much different animal, isn't it? idp_hint is provided by >>> the application. skip_auth_mechanism would be something the user has to >>> know about to type in the URL right? >>> >>> >>> >> It's quite the same. Both allow application to send something to >> auth-server . Application can use secured URL with the param ( >> http://localhost/customer-portal/secured?kc_idp_hint=facebook or >> http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos ). >> Adapter then takes care of resend the parameter to auth-server in >> initial AuthorizationEndpoint request. In both cases, application can >> either provide the link or user can add the parameters manually. >> >> Marek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/ad8317fa/attachment-0001.html From sthorger at redhat.com Fri Oct 2 05:58:06 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 2 Oct 2015 11:58:06 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <045594E8-A6F1-4156-8E9C-397B1A9B0727@me.com> References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560D8022.90004@redhat.com> <560E2622.3060203@redhat.com> <51B73F94-497C-4C15-A5EF-64912A00CE62@me.com> <045594E8-A6F1-4156-8E9C-397B1A9B0727@me.com> Message-ID: On 2 October 2015 at 11:37, Michael Gerber wrote: > > > On 02.10.2015, at 11:18, Stian Thorgersen wrote: > > For the "Is this you?" mechanism I'd add a cookie at logout that contains > user details and the authenticator that was used. We?d probably need to add > an parameter to authenticators that can flag them as automatic login or not. > > So basically you have to add the identity token of the user? Otherwise you > can not trust the content of this cookie, right? > Why do you want to include the authenticator? And which authenticator > should that be? > > You don?t have to add a flag to the authenticator, you can simply create a > helper which handles the whole ?is this you?? stuff and invoke this helper > method from each authenticator (there is currently just one) > It shouldn't be baked into the authenticator itself. It should be a separate thing, something that can control the flow. > Not sure why we would add both. If "Is this you" satisfies your > requirements, there's no one requesting the other one. My concern with > adding skip is that it?s a custom query param we're introducing that may > conflict with same functionality in OIDC, which we would then have to > deprecate once we add a similar mechanism from OIDC. > > Yeah I see. > > > On 2 October 2015 at 10:58, Michael Gerber wrote: > >> Maybe we can introduce both, a logout cookie and a query parameter to >> skip alternativ authenticators. >> The logout cookie will be set after a logout through keycloak (Logout >> URL) and the SpnegoAuthenticator offers a new configuration where you can >> configure if the logout cookie should be ignored or not. >> >> So you don?t have to do something ?special? in your application but you >> also have the possibility to create a URL for admins where they don?t have >> to logout first. >> >> How would you determine the user for the ?is this you?? Would you use the >> cookie for that or would you do a kerberos login? >> >> *Michael Gerber* >> Software Engineer >> >> Hammerweg 2 >> 8304 Wallisellen >> >> Tel. 079 440 23 02 >> Mail gerbermichi at me.com >> >> >> >> >> On 02.10.2015, at 08:37, Marek Posolda wrote: >> >> On 01/10/15 20:49, Bill Burke wrote: >> >> Sorry for late reply. >> >> On 10/1/2015 3:13 AM, Stian Thorgersen wrote: >> >> * If a user that was logged in using Kerberos logs out the user should >> not just be automatically logged-in again for the current browser >> session. Instead the user should be displayed with a regular >> username/password field, but also with an option to login with Kerberos >> >> Don't like this idea. >> >> #1 Users that want to bypass kerberos have to know to logout first so >> they can login as a non-kerberos user. >> >> #2 username/password screen would have to have knowledge that kerberos >> is turned on and that the user was logged in via kerberos. I'm don't >> think this is possible with the current SPI. >> >> * A variant on the above where if a user has logged-out from Kerberos >> the user would be displayed with a "Is this you?" when login, if the >> user selects yes the Kerberos authenticator would continue, if not the >> regular username/password form would be displayed >> >> This one might be easy to do with current SPI although not sure if >> kerberos plugin sets some session variables that need to be cleared. >> >> Yes, it can add the gss_delegation_credential note when Kerberos >> credential delegation is enabled. >> >> Looks that we may also need the non-persistent cookie added during >> logout, so the "Is this you" screen is not displayed for the first time >> login? >> >> >> >> * Implement account switcher - where a user can login to multiple >> accounts at a time and select which account to use >> >> Not sure how this is different than "Is this you?". >> >> Other ideas? Points for ideas that requires no hacks in applications ;) >> >> idp_hint is a much different animal, isn't it? idp_hint is provided by >> the application. skip_auth_mechanism would be something the user has to >> know about to type in the URL right? >> >> >> >> It's quite the same. Both allow application to send something to >> auth-server . Application can use secured URL with the param ( >> http://localhost/customer-portal/secured?kc_idp_hint=facebook or >> http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos ). >> Adapter then takes care of resend the parameter to auth-server in >> initial AuthorizationEndpoint request. In both cases, application can >> either provide the link or user can add the parameters manually. >> >> Marek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/d946b9a9/attachment.html From gerbermichi at me.com Fri Oct 2 06:08:58 2015 From: gerbermichi at me.com (Michael Gerber) Date: Fri, 02 Oct 2015 12:08:58 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560D8022.90004@redhat.com> <560E2622.3060203@redhat.com> <51B73F94-497C-4C15-A5EF-64912A00CE62@me.com> <045594E8-A6F1-4156-8E9C-397B1A9B0727@me.com> Message-ID: <9057F99F-0ADE-4DA9-84AB-93E8758C3B4B@me.com> Let?s summarize it up: 1. Add a logout cookie after successful logout with the identity token of the user 2. Skip all authenticators with the automaticLogin flag if a logout cookie exists and show instead the ?is this you? page 3 If the user press, ?yes this is me? than the login is succeeded, otherwise the next authenticator will be displayed. If everyone agrees with this workflow, than I?m going to create a PR for that, if thats ok? > On 02.10.2015, at 11:58, Stian Thorgersen wrote: > > > > On 2 October 2015 at 11:37, Michael Gerber > wrote: > > >> On 02.10.2015, at 11:18, Stian Thorgersen > wrote: >> >> For the "Is this you?" mechanism I'd add a cookie at logout that contains user details and the authenticator that was used. We?d probably need to add an parameter to authenticators that can flag them as automatic login or not. > > So basically you have to add the identity token of the user? Otherwise you can not trust the content of this cookie, right? > Why do you want to include the authenticator? And which authenticator should that be? > > You don?t have to add a flag to the authenticator, you can simply create a helper which handles the whole ?is this you?? stuff and invoke this helper method from each authenticator (there is currently just one) > > It shouldn't be baked into the authenticator itself. It should be a separate thing, something that can control the flow. > Ok. >> >> Not sure why we would add both. If "Is this you" satisfies your requirements, there's no one requesting the other one. My concern with adding skip is that it?s a custom query param we're introducing that may conflict with same functionality in OIDC, which we would then have to deprecate once we add a similar mechanism from OIDC. > Yeah I see. > >> >> On 2 October 2015 at 10:58, Michael Gerber > wrote: >> Maybe we can introduce both, a logout cookie and a query parameter to skip alternativ authenticators. >> The logout cookie will be set after a logout through keycloak (Logout URL) and the SpnegoAuthenticator offers a new configuration where you can configure if the logout cookie should be ignored or not. >> >> So you don?t have to do something ?special? in your application but you also have the possibility to create a URL for admins where they don?t have to logout first. >> >> How would you determine the user for the ?is this you?? Would you use the cookie for that or would you do a kerberos login? >> >> Michael Gerber >> Software Engineer >> >> Hammerweg 2 >> 8304 Wallisellen >> >> Tel. 079 440 23 02 >> Mail gerbermichi at me.com >> >> >> >> >>> On 02.10.2015, at 08:37, Marek Posolda > wrote: >>> >>> On 01/10/15 20:49, Bill Burke wrote: >>>> Sorry for late reply. >>>> >>>> On 10/1/2015 3:13 AM, Stian Thorgersen wrote: >>>>> * If a user that was logged in using Kerberos logs out the user should >>>>> not just be automatically logged-in again for the current browser >>>>> session. Instead the user should be displayed with a regular >>>>> username/password field, but also with an option to login with Kerberos >>>> Don't like this idea. >>>> >>>> #1 Users that want to bypass kerberos have to know to logout first so >>>> they can login as a non-kerberos user. >>>> >>>> #2 username/password screen would have to have knowledge that kerberos >>>> is turned on and that the user was logged in via kerberos. I'm don't >>>> think this is possible with the current SPI. >>>> >>>>> * A variant on the above where if a user has logged-out from Kerberos >>>>> the user would be displayed with a "Is this you?" when login, if the >>>>> user selects yes the Kerberos authenticator would continue, if not the >>>>> regular username/password form would be displayed >>>> This one might be easy to do with current SPI although not sure if >>>> kerberos plugin sets some session variables that need to be cleared. >>> Yes, it can add the gss_delegation_credential note when Kerberos >>> credential delegation is enabled. >>> >>> Looks that we may also need the non-persistent cookie added during >>> logout, so the "Is this you" screen is not displayed for the first time >>> login? >>>> >>>> >>>>> * Implement account switcher - where a user can login to multiple >>>>> accounts at a time and select which account to use >>>>> >>>> Not sure how this is different than "Is this you?". >>>> >>>>> Other ideas? Points for ideas that requires no hacks in applications ;) >>>>> >>>> idp_hint is a much different animal, isn't it? idp_hint is provided by >>>> the application. skip_auth_mechanism would be something the user has to >>>> know about to type in the URL right? >>>> >>>> >>>> >>> It's quite the same. Both allow application to send something to >>> auth-server . Application can use secured URL with the param ( >>> http://localhost/customer-portal/secured?kc_idp_hint=facebook or >>> http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos ). >>> Adapter then takes care of resend the parameter to auth-server in >>> initial AuthorizationEndpoint request. In both cases, application can >>> either provide the link or user can add the parameters manually. >>> >>> Marek >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/57d38be9/attachment-0001.html From sthorger at redhat.com Fri Oct 2 06:57:48 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 2 Oct 2015 12:57:48 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <9057F99F-0ADE-4DA9-84AB-93E8758C3B4B@me.com> References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560D8022.90004@redhat.com> <560E2622.3060203@redhat.com> <51B73F94-497C-4C15-A5EF-64912A00CE62@me.com> <045594E8-A6F1-4156-8E9C-397B1A9B0727@me.com> <9057F99F-0ADE-4DA9-84AB-93E8758C3B4B@me.com> Message-ID: Here's where I stand on this atm: * I don't like the skip_auth approach * I'm only 90% confident "is this you" is a good approach We should continue the discussion and wait at least over the weekend before implementing something around this. Michael thanks for your previous PR and we will absolutely welcome another one once we've decided on a way forward. I hope we can come to a final conclusion on this early next week. On 2 October 2015 at 12:08, Michael Gerber wrote: > Let?s summarize it up: > > 1. Add a logout cookie after successful logout with the identity token of > the user > 2. Skip all authenticators with the automaticLogin flag if a logout cookie > exists and show instead the ?is this you? page > 3 If the user press, ?yes this is me? than the login is succeeded, > otherwise the next authenticator will be displayed. > > If everyone agrees with this workflow, than I?m going to create a PR for > that, if thats ok? > > On 02.10.2015, at 11:58, Stian Thorgersen wrote: > > > > On 2 October 2015 at 11:37, Michael Gerber wrote: > >> >> >> On 02.10.2015, at 11:18, Stian Thorgersen wrote: >> >> For the "Is this you?" mechanism I'd add a cookie at logout that contains >> user details and the authenticator that was used. We?d probably need to add >> an parameter to authenticators that can flag them as automatic login or not. >> >> So basically you have to add the identity token of the user? Otherwise >> you can not trust the content of this cookie, right? >> Why do you want to include the authenticator? And which authenticator >> should that be? >> >> You don?t have to add a flag to the authenticator, you can simply create >> a helper which handles the whole ?is this you?? stuff and invoke this >> helper method from each authenticator (there is currently just one) >> > > It shouldn't be baked into the authenticator itself. It should be a > separate thing, something that can control the flow. > > Ok. > > >> Not sure why we would add both. If "Is this you" satisfies your >> requirements, there's no one requesting the other one. My concern with >> adding skip is that it?s a custom query param we're introducing that may >> conflict with same functionality in OIDC, which we would then have to >> deprecate once we add a similar mechanism from OIDC. >> >> Yeah I see. >> >> >> On 2 October 2015 at 10:58, Michael Gerber wrote: >> >>> Maybe we can introduce both, a logout cookie and a query parameter to >>> skip alternativ authenticators. >>> The logout cookie will be set after a logout through keycloak (Logout >>> URL) and the SpnegoAuthenticator offers a new configuration where you can >>> configure if the logout cookie should be ignored or not. >>> >>> So you don?t have to do something ?special? in your application but you >>> also have the possibility to create a URL for admins where they don?t have >>> to logout first. >>> >>> How would you determine the user for the ?is this you?? Would you use >>> the cookie for that or would you do a kerberos login? >>> >>> *Michael Gerber* >>> Software Engineer >>> >>> Hammerweg 2 >>> 8304 Wallisellen >>> >>> Tel. 079 440 23 02 >>> Mail gerbermichi at me.com >>> >>> >>> >>> >>> On 02.10.2015, at 08:37, Marek Posolda wrote: >>> >>> On 01/10/15 20:49, Bill Burke wrote: >>> >>> Sorry for late reply. >>> >>> On 10/1/2015 3:13 AM, Stian Thorgersen wrote: >>> >>> * If a user that was logged in using Kerberos logs out the user should >>> not just be automatically logged-in again for the current browser >>> session. Instead the user should be displayed with a regular >>> username/password field, but also with an option to login with Kerberos >>> >>> Don't like this idea. >>> >>> #1 Users that want to bypass kerberos have to know to logout first so >>> they can login as a non-kerberos user. >>> >>> #2 username/password screen would have to have knowledge that kerberos >>> is turned on and that the user was logged in via kerberos. I'm don't >>> think this is possible with the current SPI. >>> >>> * A variant on the above where if a user has logged-out from Kerberos >>> the user would be displayed with a "Is this you?" when login, if the >>> user selects yes the Kerberos authenticator would continue, if not the >>> regular username/password form would be displayed >>> >>> This one might be easy to do with current SPI although not sure if >>> kerberos plugin sets some session variables that need to be cleared. >>> >>> Yes, it can add the gss_delegation_credential note when Kerberos >>> credential delegation is enabled. >>> >>> Looks that we may also need the non-persistent cookie added during >>> logout, so the "Is this you" screen is not displayed for the first time >>> login? >>> >>> >>> >>> * Implement account switcher - where a user can login to multiple >>> accounts at a time and select which account to use >>> >>> Not sure how this is different than "Is this you?". >>> >>> Other ideas? Points for ideas that requires no hacks in applications ;) >>> >>> idp_hint is a much different animal, isn't it? idp_hint is provided by >>> the application. skip_auth_mechanism would be something the user has to >>> know about to type in the URL right? >>> >>> >>> >>> It's quite the same. Both allow application to send something to >>> auth-server . Application can use secured URL with the param ( >>> http://localhost/customer-portal/secured?kc_idp_hint=facebook or >>> http://localhost/customer-portal/secured?skip_auth_mechanism=kerberos ). >>> >>> Adapter then takes care of resend the parameter to auth-server in >>> initial AuthorizationEndpoint request. In both cases, application can >>> either provide the link or user can add the parameters manually. >>> >>> Marek >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/33d617b6/attachment.html From remi.cartier at imetrik.com Fri Oct 2 08:20:30 2015 From: remi.cartier at imetrik.com (Remi Cartier) Date: Fri, 2 Oct 2015 12:20:30 +0000 Subject: [keycloak-dev] Admin REST - User Roles In-Reply-To: References: <560BB7AC.6040501@redhat.com> <32954D20-AC4C-4A23-962E-D036112BB6E2@imetrik.com> Message-ID: <44169587-BC9F-4798-8681-90BCA0C3EF7D@imetrik.com> Amazing, you guys are very responsive ! Thanks & Cheers ! ________________________________ REMI CARTIER B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) IMETRIK GLOBAL INC. T : +1 514 448-6407 x2009 T : +1 866 276-5382 (toll free) F : +1 514 904-0611 740 Notre Dame St. West, Suite 1575 Montreal, Quebec, Canada H3C 3X6 imetrik.com On Oct 2, 2015, at 2:31 AM, Stian Thorgersen > wrote: Looks like there's a difference if you return a specific user or search for users. Returning a user doesn't include null values, while search does. Created https://issues.jboss.org/browse/KEYCLOAK-1896 On 1 October 2015 at 16:55, Remi Cartier > wrote: Stian, that?s actually what I am receiving over the wire. Here is the full log of the communication : 16:18:58.472 [main] DEBUG org.apache.http.headers - >> GET /auth/admin/realms/imetrik/users?first=0&max=2147483647 HTTP/1.1 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Accept: application/json 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Accept-Encoding: gzip, deflate 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhZjk4OTY2OS03YmIwLTRkYjgtOTNiNC0xYWI5NmU1MzgyY2UiLCJleHAiOjE0NDM1NTgyMTEsIm5iZiI6MCwiaWF0IjoxNDQzNTU3OTExLCJpc3MiOiJodHRwOi8vbTRpYi1pZG06ODA4MC9hdXRoL3JlYWxtcy9pbWV0cmlrIiwiYXVkIjoidWJpX2RyaXZlciIsInN1YiI6IjA1NTY3MTdlLWZmYjktNGMyZC1iODViLTUzM2Q5Mzk2ZjI0MyIsImF6cCI6InViaV9kcml2ZXIiLCJzZXNzaW9uX3N0YXRlIjoiMDQyNTdlY2EtMDAxMi00ZDU5LWFjMWItNWQ0NzI1MTFiMTc2IiwiY2xpZW50X3Nlc3Npb24iOiI5OGVkZjRkMC00MTk5LTRjODctYjY0OC1jYzhiYzI3MDhkMmUiLCJhbGxvd2VkLW9yaWdpbnMiOltdLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsicmVhbG0tcm9sZSJdfSwicmVzb3VyY2VfYWNjZXNzIjp7InViaV9kcml2ZXIiOnsicm9sZXMiOlsibWlsZWFnZSJdfSwicmVhbG0tbWFuYWdlbWVudCI6eyJyb2xlcyI6WyJ2aWV3LXJlYWxtIiwidmlldy1pZGVudGl0eS1wcm92aWRlcnMiLCJtYW5hZ2UtZXZlbnRzIiwibWFuYWdlLXJlYWxtIiwibWFuYWdlLWlkZW50aXR5LXByb3ZpZGVycyIsImltcGVyc29uYXRpb24iLCJyZWFsbS1hZG1pbiIsInZpZXctZXZlbnRzIiwibWFuYWdlLXVzZXJzIiwidmlldy11c2VycyIsInZpZXctY2xpZW50cyIsIm1hbmFnZS1jbGllbnRzIl19LCJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50Iiwidmlldy1wcm9maWxlIl19fSwibmFtZSI6ImZpcnN0IG5hbWUgbGFzdCBuYW1lIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYWRtaW4iLCJnaXZlbl9uYW1lIjoiZmlyc3QgbmFtZSIsImZhbWlseV9uYW1lIjoibGFzdCBuYW1lIn0.Px7tQJ8TV7ba9urpdNUq-HXul01CebvwSe6mpusMzLmIBJUdlzIJnzXyiuz4_AD9vwdYc5KCMHQ8LbucDs5ZrDYx5JQVJEIAQq6_q7d8hsE2gwp0SPejHvtJgki-hDRiuVlp-8lYGLQ6oJ_ipc6GBeVoaxQU8mmBEailh_rxpRwlXSNkef-r_ixzVwY3EQ5K55V2ivYFLmgEbi4mp7dU1FlzsAlvUOuJzbhVo-pyi0iQBjsvca8IJSIKQetCFxvTNXPIQUk5-bBI96_MOFYyoTenCs2m2ygEBDWB8GabrszAPLGEHEEJ2IgXIEK1kditZ7rXNm-ZgcVGYiBbzhVprQ 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Host: m4ib-idm:8080 16:18:58.472 [main] DEBUG org.apache.http.headers - >> Connection: Keep-Alive 16:18:58.478 [main] DEBUG org.apache.http.wire - << "HTTP/1.1 200 OK[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Connection: keep-alive[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Cache-Control: no-cache[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "X-Powered-By: Undertow/1[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Server: WildFly/9[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Transfer-Encoding: chunked[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Content-Type: application/json[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "Date: Tue, 29 Sep 2015 20:18:31 GMT[\r][\n]" 16:18:58.479 [main] DEBUG org.apache.http.wire - << "[\r][\n]" 16:18:58.479 [main] DEBUG o.a.h.i.conn.DefaultClientConnection - Receiving response: HTTP/1.1 200 OK 16:18:58.479 [main] DEBUG org.apache.http.headers - << HTTP/1.1 200 OK 16:18:58.479 [main] DEBUG org.apache.http.headers - << Connection: keep-alive 16:18:58.479 [main] DEBUG org.apache.http.headers - << Cache-Control: no-cache 16:18:58.479 [main] DEBUG org.apache.http.headers - << X-Powered-By: Undertow/1 16:18:58.479 [main] DEBUG org.apache.http.headers - << Server: WildFly/9 16:18:58.479 [main] DEBUG org.apache.http.headers - << Transfer-Encoding: chunked 16:18:58.479 [main] DEBUG org.apache.http.headers - << Content-Type: application/json 16:18:58.479 [main] DEBUG org.apache.http.headers - << Date: Tue, 29 Sep 2015 20:18:31 GMT 16:18:58.479 [main] DEBUG o.a.h.impl.client.DefaultHttpClient - Connection can be kept alive indefinitely 16:18:58.480 [main] DEBUG org.apache.http.wire - << "01db[\r][\n]" 16:18:58.480 [main] DEBUG org.apache.http.wire - << "[{"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first name","lastName":"last name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{"key1":["value1"]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null}]" 16:18:58.552 [main] DEBUG org.apache.http.wire - << "[\r][\n]" 16:18:58.552 [main] DEBUG org.apache.http.wire - << "0[\r][\n]" 16:18:58.552 [main] DEBUG org.apache.http.wire - << "[\r][\n]" 16:18:58.552 [main] DEBUG o.a.h.i.c.BasicClientConnectionManager - Releasing connection org.apache.http.impl.conn.ManagedClientConnectionImpl at 483f6d77 16:18:58.552 [main] DEBUG o.a.h.i.c.BasicClientConnectionManager - Connection can be kept alive indefinitely Regards. ________________________________ REMI CARTIER B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) IMETRIK GLOBAL INC. T : +1 514 448-6407 x2009 T : +1 866 276-5382 (toll free) F : +1 514 904-0611 740 Notre Dame St. West, Suite 1575 Montreal, Quebec, Canada H3C 3X6 imetrik.com On Oct 1, 2015, at 10:37 AM, Stian Thorgersen > wrote: Just tried it and the returned json for a user is: {"id":"354094d6-8b32-4c32-b1ae-ccd82c5fdca3","createdTimestamp":1443710165680,"username":"admin","enabled":true,"totp":false,"emailVerified":false,"attributes":{"locale":["en"]},"requiredActions":[]} Which doesn't include the roles field. So this is shown because the way you are printing the user, not because it's included on the wire. On 1 October 2015 at 16:34, Stian Thorgersen > wrote: Is that the json sent on the wire, or is it after you've marshalled it to UserRepresentation and then printed it back again? On 1 October 2015 at 15:34, Remi Cartier > wrote: yes, I can see : [ { "applicationRoles": null, "attributes": { "key1": [ "value1" ] }, "clientConsents": null, "clientRoles": null, "createdTimestamp": 1443542144845, "credentials": null, "email": null, "emailVerified": true, "enabled": true, "federatedIdentities": null, "federationLink": null, "firstName": "first name", "id": "0556717e-ffb9-4c2d-b85b-533d9396f243", "lastName": "last name", "realmRoles": null, "requiredActions": [], "self": null, "serviceAccountClientId": null, "socialLinks": null, "totp": false, "username": "admin" } ] when doing the query : GET /auth/admin/realms/imetrik/users?first=0&max=2147483647 ________________________________ REMI CARTIER B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) IMETRIK GLOBAL INC. T : +1 514 448-6407 x2009 T : +1 866 276-5382 (toll free) F : +1 514 904-0611 740 Notre Dame St. West, Suite 1575 Montreal, Quebec, Canada H3C 3X6 imetrik.com On Oct 1, 2015, at 2:49 AM, Stian Thorgersen > wrote: Sorry, I meant does it include the "roles" field? On 30 September 2015 at 16:24, Remi Cartier > wrote: The JSON response (string) does NOT contain any roles. ________________________________ From: Stian Thorgersen [sthorger at redhat.com] Sent: Wednesday, September 30, 2015 7:39 AM To: Remi Cartier Cc: Marek Posolda; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Admin REST - User Roles Does the response actually contain the roles though? You're parsing to UserRepresentation then printing it out afterwards. On 30 September 2015 at 13:24, Remi Cartier > wrote: Marek, I see, thank you for your reply. Wouldn't it be less error/question prone if the endpoint returning all the users wouldn't show the *roles attributes ? Because they will always be null if I understood correctly. Regards. R?mi. ________________________________ From: Marek Posolda [mposolda at redhat.com] Sent: Wednesday, September 30, 2015 6:21 AM To: Remi Cartier; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Admin REST - User Roles Hi, to retrieve realm role mappings of user, you need to use the endpoint like http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm . See the docs for details: http://keycloak.github.io/docs/rest-api/overview-index.html Marek On 29/09/15 19:06, Remi Cartier wrote: Hi guys, first of all, thank you for that great piece of software, it?s amazing ! Now, down to business. When I do : keycloak = Keycloak.getInstance(getKeycloakServerURL(), getKeycloakRealm(), getKeycloakRealmAdminUsername(), getKeycloakRealmAdminPassword(), getKeycloakClientId()); for (UserRepresentation userRepresentation : keycloak.realm(getKeycloakRealm()).users().search(null, 0, Integer.MAX_VALUE)) { log.info(ToStringBuilder.reflectionToString(userRepresentation, ToStringStyle.JSON_STYLE)); } The information I get does not contain any roles, all the roles related fields are ?null?. - {"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first name","lastName":"last name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null} However in the admin interface I have setup roles at each layer : realm, client The user I am using to do the queries has all the *realm* roles associated. is there anything else I need to do ? thank you for your help ! ________________________________ REMI CARTIER B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) IMETRIK GLOBAL INC. T : +1 514 448-6407 x2009 T : +1 866 276-5382 (toll free) F : +1 514 904-0611 740 Notre Dame St. West, Suite 1575 Montreal, Quebec, Canada H3C 3X6 imetrik.com _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/571c82a1/attachment-0001.html From remi.cartier at imetrik.com Fri Oct 2 08:29:39 2015 From: remi.cartier at imetrik.com (Remi Cartier) Date: Fri, 2 Oct 2015 12:29:39 +0000 Subject: [keycloak-dev] List users that have some client roles & be able to search on users custom attributes Message-ID: <7C37C238-4391-4427-AE41-967AB9070D28@imetrik.com> Hey there, Question 1: I was wondering if there was an existing mechanism to fetch users that have some specific client roles. My scenario is this one. As a SSO provider, different applications (clients) are created in Keycloak. A specific user can have roles for some of those clients. If, in one of my application, I want to list all the users that ?belongs? to me (that have roles for my application) how do I do that ? I don?t want to list all the users and they filter them by some criteria, that would be a very inefficient way to do it. (CPU + Bandwidth) Question 2: In the search REST admin endpoint, is there a mechanism to filter on specific custom attributes ? for example. I created a language attribute for a user. I now want to list all my users with custom attribute language=FR for example, how do I do that ? Syntax could be : /search?attribute1=language&value1=FR or /search?attribute_language=FR Thank for your time and great work. Sorry if those questions have already been asked (if so, please, simply point me to some reference without repeating yourself) Cheers ! ________________________________ REMI CARTIER B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) IMETRIK GLOBAL INC. T : +1 514 448-6407 x2009 T : +1 866 276-5382 (toll free) F : +1 514 904-0611 740 Notre Dame St. West, Suite 1575 Montreal, Quebec, Canada H3C 3X6 imetrik.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/60804d0d/attachment.html From bburke at redhat.com Fri Oct 2 10:31:06 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 2 Oct 2015 10:31:06 -0400 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560D8022.90004@redhat.com> Message-ID: <560E952A.7090906@redhat.com> On 10/2/2015 5:26 AM, Stian Thorgersen wrote: > > > On 1 October 2015 at 20:49, Bill Burke > wrote: > > Sorry for late reply. > > On 10/1/2015 3:13 AM, Stian Thorgersen wrote: > > * If a user that was logged in using Kerberos logs out the user should > > not just be automatically logged-in again for the current browser > > session. Instead the user should be displayed with a regular > > username/password field, but also with an option to login with Kerberos > > Don't like this idea. > > #1 Users that want to bypass kerberos have to know to logout first so > they can login as a non-kerberos user. > > #2 username/password screen would have to have knowledge that kerberos > is turned on and that the user was logged in via kerberos. I'm don't > think this is possible with the current SPI. > > > Could we not have a selector or something in the authentication flow > that can select which authenticator to use? The selector could even be > allowed to prompt the user for input, so we could implement a "Is this > you" selector. > > > > * A variant on the above where if a user has logged-out from Kerberos > > the user would be displayed with a "Is this you?" when login, if the > > user selects yes the Kerberos authenticator would continue, if not the > > regular username/password form would be displayed > > This one might be easy to do with current SPI although not sure if > kerberos plugin sets some session variables that need to be cleared. > > > I was assuming that this option would also require user to logout first. > "Is this you" would only be displayed after a logout. > I don't like this "logout required" thing and the logout cookie. What is the big deal about having a screen "You are already logged in via Kerberos. Do you want to continue? Or log in as a different user?" This would be something that is optionally turned on and shown after the Kerberos/SPNEGO handshake. > > > > * Implement account switcher - where a user can login to multiple > > accounts at a time and select which account to use > > > > Not sure how this is different than "Is this you?". > > > "Is this you" would simply prompt the user if the user is the user that > previously logged in from that browser. > > Account switcher would allow a user to be signed-in to Keycloak with > multiple accounts and provide some mechanism for applications to select > which account. Like GMail and others allow you to be logged-in to > multiple accounts at a time. > Again, this is very similar to the "Is this you?". The steps would be: 1. SPNEGO handshake successful 2. Show account switcher page with kerberos user as only choice. The only need for a logout persistent cookie is to remember successful logins. I would like this approach the best. > > > Other ideas? Points for ideas that requires no hacks in applications ;) > > > > idp_hint is a much different animal, isn't it? idp_hint is provided by > the application. skip_auth_mechanism would be something the user has to > know about to type in the URL right? > > > We should never have added idp_hint in the first place IMO. It leaks > authentication semantics into applications and also only works if user > is not logged in already. > idp_hint is a good thing. If an app integrates with Facebook, they'll need to force the user to login via Facebook so they can obtain a Facebook token. > skip_auth_mech could be implemented in applications as well > but my same > point stands here. It requires applications to be aware of > authentication semantics. It seems that what's being proposed here is > that admins manually add it to the login URL though, but that's just a > horrible idea, period. > skip_auth_mech is the opposite of auth_mechs_required. Something that I believe SAML has. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Oct 2 10:32:53 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 2 Oct 2015 10:32:53 -0400 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <9057F99F-0ADE-4DA9-84AB-93E8758C3B4B@me.com> References: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com> <560D8022.90004@redhat.com> <560E2622.3060203@redhat.com> <51B73F94-497C-4C15-A5EF-64912A00CE62@me.com> <045594E8-A6F1-4156-8E9C-397B1A9B0727@me.com> <9057F99F-0ADE-4DA9-84AB-93E8758C3B4B@me.com> Message-ID: <560E9595.6030603@redhat.com> On 10/2/2015 6:08 AM, Michael Gerber wrote: > Let?s summarize it up: > > 1. Add a logout cookie after successful logout with the identity token > of the user > 2. Skip all authenticators with the automaticLogin flag if a logout > cookie exists and show instead the ?is this you? page > 3 If the user press, ?yes this is me? than the login is succeeded, > otherwise the next authenticator will be displayed. > > If everyone agrees with this workflow, than I?m going to create a PR for > that, if thats ok? > I do not agree with this approach. See my previous email. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Oct 2 11:23:00 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 2 Oct 2015 11:23:00 -0400 Subject: [keycloak-dev] Account Chooser Flo Message-ID: <560EA154.70609@redhat.com> I would like to take the Account Chooser approach to the Kerberos bypass situation. The Flow would be: 1. Cookie - ALTERNATIVE 2. Chooser Flow - ALTERNATIVE a. Kerberos - OPTIONAL b. Account Chooser - ALTERNATIVE c. Forms ALTERNATIVE i. Username/Password - REQUIRED ii. OTP - OPTIONAL * An "accounts used" cookie needs to be optionally set depending on "remember me" switch. This should be a persistent cookie. * Account Chooser page is always shown unless the "account used" cookie is empty and no ClientSessionModel.getAuthenticatedUser is set. * If selected user == current ClientSessionModel.getAuthenticatedUser then return SUCCESSFUL * If selected user != NULL set ClientSessionModel.getAuthenticatedUser, return ATTEMPTED * If selected user == NULL clear ClientSessionModel.getAuthenticatedUser, return ATTEMPTED * Username/Password Form Authenticator does not display username, registration, and broker links if getAuthenticatedUser is already set * An improvement can be made to also perform OTP input on Username/Password page if a UserModel is already chosen. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From vmuzikar at redhat.com Fri Oct 2 13:36:22 2015 From: vmuzikar at redhat.com (Vaclav Muzikar) Date: Fri, 2 Oct 2015 19:36:22 +0200 Subject: [keycloak-dev] IDs/names for Mapper Type Properties Message-ID: Hi all, I'd like to discuss missing @id and @name attributes on UI elements of Mapper Type Properties (related issue: https://issues.jboss.org/browse/KEYCLOAK-1885). This concerns e.g. creating/editing a Client Protocol Mapper. When you choose the Mapper Type, the following properties (like "Token Claim Name" in case of "Hardcoded Claim") don't have any @id or @name. This properties are used on more places all over the Keycloak (the template is "kc-provider-config.html" in "keycloak-forms-common-themes" module). At QE we'd like to add @id for every of these elements so we don't need to use relative XPath locators based on labels, AngularJS directives/attributes etc. which could be unstable. The problem is there's no suitable (object) attribute of these properties to use as HTML @id or @name. The closest thing to this is the mapperType.property.name but it's using illegal characters (spaces) for @id in some cases. E.g. "Claim value" uses the "claim.value" name which is OK but "Claim JSON Type" uses "Claim JSON Type" name (yes, the name is same as the label) which can't be used in HTML as @id because of spaces. I've got some solutions on my mind. *1) Replacing the spaces on the client site (using AngularJS controllers)* which is probably not a nice solution. The Mapper Types (and it's properties) are used on more than one sites/controllers and I haven't found any global getter or something like that for Mapper Types which could contain this replacement code. As far as I know, Mapper Types are fetched using ServerInfo service. But this service is pretty abstract and simple so I don't think it's a good idea to do the replacement there. That means we need to add some getter and rewrite the controllers to use this getter or copy-paste the replacement code all over the controllers which is obviously out of the question. *2) Add a new ID attribute to the REST API* so the ServerInfo service would distribute this attribute to all controllers and templates. *3) Change the "name" attributes* so it can be used as @id. Possible problem could be compatibility and migration of current Keycloak installations to the newer version. Can come upon any other solution? Could you implement any of it? Thank you! Best regards, V?clav Muzik?? Keycloak QE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151002/8cbbc8ac/attachment.html From satyajit.das at spire2grow.com Sun Oct 4 05:04:46 2015 From: satyajit.das at spire2grow.com (Satyajit Das) Date: Sun, 4 Oct 2015 14:34:46 +0530 Subject: [keycloak-dev] Findings about keycloak--Important Message-ID: Hi Team, 1) I have the keycloak(1.4.0 final) set up in windows OS. 2) I have 2 services that i have secured using keycloak. The services are registered in keycloak and the respective keycloak.json is placed in resource folder. 3) When the services are are deployed in Ubuntu OS the authentication works as expected. by sharing the tokenid but then the services are deployed in centos machine the authentication fails. The error is Invalid token: Token is inactive. I tried the same setup and the same war files of services on different instances of centos , we are facing the same issue but the issue is not replicated on ubuntu different instances. Please let me know your thoughts. Regards, Satya. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151004/539cd6ea/attachment.html From gerbermichi at me.com Mon Oct 5 02:01:47 2015 From: gerbermichi at me.com (Michael Gerber) Date: Mon, 05 Oct 2015 06:01:47 +0000 (GMT) Subject: [keycloak-dev] Kerberos, login with different user Message-ID: I don't like this approach if the?"Account Chooser" page is only?configurable?per realm. Because,?I think it is a bit annoying if you always have to go over the?"Account Chooser" page. 99% of all uses want to log in with their kerberos credentials, there are only a few people which want to switch their account. But I think your approach is good, if you can enable the "Account Chooser" page per client and not only per realm.? Am 02. Oktober 2015 um 16:31 schrieb Bill Burke : On 10/2/2015 5:26 AM, Stian Thorgersen wrote: On 1 October 2015 at 20:49, Bill Burke > wrote: Sorry for late reply. On 10/1/2015 3:13 AM, Stian Thorgersen wrote: > * If a user that was logged in using Kerberos logs out the user should > not just be automatically logged-in again for the current browser > session. Instead the user should be displayed with a regular > username/password field, but also with an option to login with Kerberos Don't like this idea. #1 Users that want to bypass kerberos have to know to logout first so they can login as a non-kerberos user. #2 username/password screen would have to have knowledge that kerberos is turned on and that the user was logged in via kerberos. I'm don't think this is possible with the current SPI. Could we not have a selector or something in the authentication flow that can select which authenticator to use? The selector could even be allowed to prompt the user for input, so we could implement a "Is this you" selector. > * A variant on the above where if a user has logged-out from Kerberos > the user would be displayed with a "Is this you?" when login, if the > user selects yes the Kerberos authenticator would continue, if not the > regular username/password form would be displayed This one might be easy to do with current SPI although not sure if kerberos plugin sets some session variables that need to be cleared. I was assuming that this option would also require user to logout first. "Is this you" would only be displayed after a logout. I don't like this "logout required" thing and the logout cookie. What is the big deal about having a screen "You are already logged in via Kerberos. Do you want to continue? Or log in as a different user?" This would be something that is optionally turned on and shown after the Kerberos/SPNEGO handshake. > * Implement account switcher - where a user can login to multiple > accounts at a time and select which account to use > Not sure how this is different than "Is this you?". "Is this you" would simply prompt the user if the user is the user that previously logged in from that browser. Account switcher would allow a user to be signed-in to Keycloak with multiple accounts and provide some mechanism for applications to select which account. Like GMail and others allow you to be logged-in to multiple accounts at a time. Again, this is very similar to the "Is this you?". The steps would be: 1. SPNEGO handshake successful 2. Show account switcher page with kerberos user as only choice. The only need for a logout persistent cookie is to remember successful logins. I would like this approach the best. > Other ideas? Points for ideas that requires no hacks in applications ;) > idp_hint is a much different animal, isn't it? idp_hint is provided by the application. skip_auth_mechanism would be something the user has to know about to type in the URL right? We should never have added idp_hint in the first place IMO. It leaks authentication semantics into applications and also only works if user is not logged in already. idp_hint is a good thing. If an app integrates with Facebook, they'll need to force the user to login via Facebook so they can obtain a Facebook token. skip_auth_mech could be implemented in applications as well but my same point stands here. It requires applications to be aware of authentication semantics. It seems that what's being proposed here is that admins manually add it to the login URL though, but that's just a horrible idea, period. skip_auth_mech is the opposite of auth_mechs_required. Something that I believe SAML has. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151005/6b0ceea9/attachment-0001.html From mposolda at redhat.com Mon Oct 5 02:52:23 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 5 Oct 2015 08:52:23 +0200 Subject: [keycloak-dev] [keycloak-user] Findings about keycloak--Important In-Reply-To: References: Message-ID: <56121E27.1040202@redhat.com> Hi, this looks like bad time set either on your centos machine or on windows OS machine with Keycloak. Can't it be that? I suggest to doublecheck the time settings on all your servers and sync it to be the correct and same on all your servers. Marek On 04/10/15 11:04, Satyajit Das wrote: > Hi Team, > > 1) I have the keycloak(1.4.0 final) set up in windows OS. > > 2) I have 2 services that i have secured using keycloak. The services > are registered in keycloak and the respective keycloak.json is placed > in resource folder. > > 3) When the services are are deployed in Ubuntu OS the authentication > works as expected. by sharing the tokenid > > but then the services are deployed in centos machine the > authentication fails. > > The error is Invalid token: Token is inactive. > > I tried the same setup and the same war files of services on different > instances of centos , we are facing the same issue but the issue is > not replicated on ubuntu different instances. > > Please let me know your thoughts. > > 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-dev/attachments/20151005/0047a36a/attachment.html From sthorger at redhat.com Mon Oct 5 03:39:10 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 5 Oct 2015 09:39:10 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: References: Message-ID: I don't think the account chooser is a good option. As you say users that login with Kerberos (and have enabled Kerberos for the Keycloak domain) will in 99% cases want to login with Kerberos. End of the day I don't really like any of these options, and so far Michael is the only person asking for something like this. With that in mind I think it's better that Michael would develop something custom on top of the authenticator spi, rather than us adding this to Keycloak. On 5 October 2015 at 08:01, Michael Gerber wrote: > I don't like this approach if the "Account Chooser" page is only > configurable per realm. > Because, I think it is a bit annoying if you always have to go over the "Account > Chooser" page. > 99% of all uses want to log in with their kerberos credentials, there are > only a few people which want to switch their account. > > But I think your approach is good, if you can enable the "Account Chooser" > page per client and not only per realm. > > Am 02. Oktober 2015 um 16:31 schrieb Bill Burke : > > > > On 10/2/2015 5:26 AM, Stian Thorgersen wrote: > > > > On 1 October 2015 at 20:49, Bill Burke > > wrote: > > > Sorry for late reply. > > > On 10/1/2015 3:13 AM, Stian Thorgersen wrote: > > > * If a user that was logged in using Kerberos logs out the user should > > > not just be automatically logged-in again for the current browser > > > session. Instead the user should be displayed with a regular > > > username/password field, but also with an option to login with Kerberos > > > Don't like this idea. > > > #1 Users that want to bypass kerberos have to know to logout first so > > they can login as a non-kerberos user. > > > #2 username/password screen would have to have knowledge that kerberos > > is turned on and that the user was logged in via kerberos. I'm don't > > think this is possible with the current SPI. > > > > Could we not have a selector or something in the authentication flow > > that can select which authenticator to use? The selector could even be > > allowed to prompt the user for input, so we could implement a "Is this > > you" selector. > > > > > * A variant on the above where if a user has logged-out from Kerberos > > > the user would be displayed with a "Is this you?" when login, if the > > > user selects yes the Kerberos authenticator would continue, if not the > > > regular username/password form would be displayed > > > This one might be easy to do with current SPI although not sure if > > kerberos plugin sets some session variables that need to be cleared. > > > > I was assuming that this option would also require user to logout first. > > "Is this you" would only be displayed after a logout. > > > > I don't like this "logout required" thing and the logout cookie. What > is the big deal about having a screen "You are already logged in via > Kerberos. Do you want to continue? Or log in as a different user?" > This would be something that is optionally turned on and shown after the > Kerberos/SPNEGO handshake. > > > > > > * Implement account switcher - where a user can login to multiple > > > accounts at a time and select which account to use > > > > > > Not sure how this is different than "Is this you?". > > > > "Is this you" would simply prompt the user if the user is the user that > > previously logged in from that browser. > > > Account switcher would allow a user to be signed-in to Keycloak with > > multiple accounts and provide some mechanism for applications to select > > which account. Like GMail and others allow you to be logged-in to > > multiple accounts at a time. > > > > > Again, this is very similar to the "Is this you?". The steps would be: > > 1. SPNEGO handshake successful > 2. Show account switcher page with kerberos user as only choice. > > The only need for a logout persistent cookie is to remember successful > logins. > > I would like this approach the best. > > > > > Other ideas? Points for ideas that requires no hacks in applications ;) > > > > > > idp_hint is a much different animal, isn't it? idp_hint is provided by > > the application. skip_auth_mechanism would be something the user has to > > know about to type in the URL right? > > > > We should never have added idp_hint in the first place IMO. It leaks > > authentication semantics into applications and also only works if user > > is not logged in already. > > > > idp_hint is a good thing. If an app integrates with Facebook, they'll > need to force the user to login via Facebook so they can obtain a > Facebook token. > > skip_auth_mech could be implemented in applications as well > > but my same > > point stands here. It requires applications to be aware of > > authentication semantics. It seems that what's being proposed here is > > that admins manually add it to the login URL though, but that's just a > > horrible idea, period. > > > > skip_auth_mech is the opposite of auth_mechs_required. Something that I > believe SAML has. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151005/7e52de25/attachment.html From sthorger at redhat.com Mon Oct 5 03:42:14 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 5 Oct 2015 09:42:14 +0200 Subject: [keycloak-dev] Account Chooser Flo In-Reply-To: <560EA154.70609@redhat.com> References: <560EA154.70609@redhat.com> Message-ID: As I commented in the original thread I don't think this is a good idea. Users that have configured their browser has to set a specific domain to enable Kerberos as well as be logged-in using Kerberos to their desktop. With that in mind 99% of users will want to log in with Kerberos 99% of the time. So requiring and extra step in the flow is not nice. Let's please return this conversation to the original thread though, rather than start another thread. On 2 October 2015 at 17:23, Bill Burke wrote: > I would like to take the Account Chooser approach to the Kerberos bypass > situation. The Flow would be: > > 1. Cookie - ALTERNATIVE > 2. Chooser Flow - ALTERNATIVE > a. Kerberos - OPTIONAL > b. Account Chooser - ALTERNATIVE > c. Forms ALTERNATIVE > i. Username/Password - REQUIRED > ii. OTP - OPTIONAL > > > * An "accounts used" cookie needs to be optionally set depending on > "remember me" switch. This should be a persistent cookie. > * Account Chooser page is always shown unless the "account used" cookie > is empty and no ClientSessionModel.getAuthenticatedUser is set. > * If selected user == current ClientSessionModel.getAuthenticatedUser > then return SUCCESSFUL > * If selected user != NULL set ClientSessionModel.getAuthenticatedUser, > return ATTEMPTED > * If selected user == NULL clear > ClientSessionModel.getAuthenticatedUser, return ATTEMPTED > > * Username/Password Form Authenticator does not display username, > registration, and broker links if getAuthenticatedUser is already set > * An improvement can be made to also perform OTP input on > Username/Password page if a UserModel is already chosen. > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151005/270d337f/attachment-0001.html From sthorger at redhat.com Mon Oct 5 03:46:00 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 5 Oct 2015 09:46:00 +0200 Subject: [keycloak-dev] How to enable grant logging In-Reply-To: <1658882558.24504565.1443702237274.JavaMail.zimbra@redhat.com> References: <1744131951.24492075.1443701298541.JavaMail.zimbra@redhat.com> <1658882558.24504565.1443702237274.JavaMail.zimbra@redhat.com> Message-ID: Please use user mailing list for support questions On 1 October 2015 at 14:23, Michal Hajas wrote: > Hi, > > I would like to ask, which event type, in Login Events Settings form -> > Saved Types input, stands for grant access? > > Michal. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151005/0cca5603/attachment.html From sthorger at redhat.com Mon Oct 5 03:46:22 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 5 Oct 2015 09:46:22 +0200 Subject: [keycloak-dev] List users that have some client roles & be able to search on users custom attributes In-Reply-To: <7C37C238-4391-4427-AE41-967AB9070D28@imetrik.com> References: <7C37C238-4391-4427-AE41-967AB9070D28@imetrik.com> Message-ID: Please use user mailing list for support questions On 2 October 2015 at 14:29, Remi Cartier wrote: > Hey there, > > *Question 1:* > > I was wondering if there was an existing mechanism to fetch users that > have some specific client roles. > > My scenario is this one. As a SSO provider, different applications > (clients) are created in Keycloak. > A specific user can have roles for some of those clients. > > If, in one of my application, I want to list all the users that ?belongs? > to me (that have roles for my application) how do I do that ? > > I don?t want to list all the users and they filter them by some criteria, > that would be a very inefficient way to do it. (CPU + Bandwidth) > > *Question 2: * > > In the search REST admin endpoint, is there a mechanism to filter on > specific custom attributes ? > > for example. I created a language attribute for a user. I now want to list > all my users with custom attribute language=FR for example, how do I do > that ? > > Syntax could be : > /search?attribute1=language&value1=FR or > /search?attribute_language=FR > > Thank for your time and great work. > Sorry if those questions have already been asked (if so, please, simply > point me to some reference without repeating yourself) > > Cheers ! > > ------------------------------ > > > REMI CARTIER > B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner) > > *IMETRIK GLOBAL INC.* > *T :* +1 514 448-6407 x2009 > *T :* +1 866 276-5382 (toll free) > *F :* +1 514 904-0611 > > 740 Notre Dame St. West, Suite 1575 > Montreal, Quebec, Canada H3C 3X6 > imetrik.com > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151005/66186264/attachment.html From gerbermichi at me.com Mon Oct 5 08:41:41 2015 From: gerbermichi at me.com (Michael Gerber) Date: Mon, 05 Oct 2015 12:41:41 +0000 (GMT) Subject: [keycloak-dev] Kerberos, login with different user Message-ID: <410fbbb0-8e55-4673-b8ae-b893e7effe23@me.com> Ok, I see. Is there a way to pass an url query parameter through the wildfly adapter into an authenticator? Am 05. Oktober 2015 um 09:39 schrieb Stian Thorgersen : I don't think the account chooser is a good option. As you say users that login with Kerberos (and have enabled Kerberos for the Keycloak domain) will in 99% cases want to login with Kerberos. End of the day I don't really like any of these options, and so far Michael is the only person asking for something like this. With that in mind I think it's better that Michael would develop something custom on top of the authenticator spi, rather than us adding this to Keycloak. On 5 October 2015 at 08:01, Michael Gerber wrote: I don't like this approach if the?"Account Chooser" page is only?configurable?per realm. Because,?I think it is a bit annoying if you always have to go over the?"Account Chooser" page. 99% of all uses want to log in with their kerberos credentials, there are only a few people which want to switch their account. But I think your approach is good, if you can enable the "Account Chooser" page per client and not only per realm.? Am 02. Oktober 2015 um 16:31 schrieb Bill Burke : On 10/2/2015 5:26 AM, Stian Thorgersen wrote: On 1 October 2015 at 20:49, Bill Burke > wrote: Sorry for late reply. On 10/1/2015 3:13 AM, Stian Thorgersen wrote: > * If a user that was logged in using Kerberos logs out the user should > not just be automatically logged-in again for the current browser > session. Instead the user should be displayed with a regular > username/password field, but also with an option to login with Kerberos Don't like this idea. #1 Users that want to bypass kerberos have to know to logout first so they can login as a non-kerberos user. #2 username/password screen would have to have knowledge that kerberos is turned on and that the user was logged in via kerberos. I'm don't think this is possible with the current SPI. Could we not have a selector or something in the authentication flow that can select which authenticator to use? The selector could even be allowed to prompt the user for input, so we could implement a "Is this you" selector. > * A variant on the above where if a user has logged-out from Kerberos > the user would be displayed with a "Is this you?" when login, if the > user selects yes the Kerberos authenticator would continue, if not the > regular username/password form would be displayed This one might be easy to do with current SPI although not sure if kerberos plugin sets some session variables that need to be cleared. I was assuming that this option would also require user to logout first. "Is this you" would only be displayed after a logout. I don't like this "logout required" thing and the logout cookie. What is the big deal about having a screen "You are already logged in via Kerberos. Do you want to continue? Or log in as a different user?" This would be something that is optionally turned on and shown after the Kerberos/SPNEGO handshake. > * Implement account switcher - where a user can login to multiple > accounts at a time and select which account to use > Not sure how this is different than "Is this you?". "Is this you" would simply prompt the user if the user is the user that previously logged in from that browser. Account switcher would allow a user to be signed-in to Keycloak with multiple accounts and provide some mechanism for applications to select which account. Like GMail and others allow you to be logged-in to multiple accounts at a time. Again, this is very similar to the "Is this you?". The steps would be: 1. SPNEGO handshake successful 2. Show account switcher page with kerberos user as only choice. The only need for a logout persistent cookie is to remember successful logins. I would like this approach the best. > Other ideas? Points for ideas that requires no hacks in applications ;) > idp_hint is a much different animal, isn't it? idp_hint is provided by the application. skip_auth_mechanism would be something the user has to know about to type in the URL right? We should never have added idp_hint in the first place IMO. It leaks authentication semantics into applications and also only works if user is not logged in already. idp_hint is a good thing. If an app integrates with Facebook, they'll need to force the user to login via Facebook so they can obtain a Facebook token. skip_auth_mech could be implemented in applications as well but my same point stands here. It requires applications to be aware of authentication semantics. It seems that what's being proposed here is that admins manually add it to the login URL though, but that's just a horrible idea, period. skip_auth_mech is the opposite of auth_mechs_required. Something that I believe SAML has. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151005/8ad791a6/attachment-0001.html From bburke at redhat.com Mon Oct 5 09:10:38 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 5 Oct 2015 09:10:38 -0400 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: References: Message-ID: <561276CE.2050902@redhat.com> On 10/5/2015 3:39 AM, Stian Thorgersen wrote: > I don't think the account chooser is a good option. As you say users > that login with Kerberos (and have enabled Kerberos for the Keycloak > domain) will in 99% cases want to login with Kerberos. > Is logging out of Kerberos a big deal? I have no idea. Never in my career have I had to log in via kerberos. > End of the day I don't really like any of these options, and so far > Michael is the only person asking for something like this. With that in > mind I think it's better that Michael would develop something custom on > top of the authenticator spi, rather than us adding this to Keycloak. > I agree, but an account chooser would be a nice feature to add the way I described it. We got a lot of other stuff to do though that has higher priority. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Oct 5 09:17:31 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 5 Oct 2015 09:17:31 -0400 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <410fbbb0-8e55-4673-b8ae-b893e7effe23@me.com> References: <410fbbb0-8e55-4673-b8ae-b893e7effe23@me.com> Message-ID: <5612786B.7000901@redhat.com> I think you can just specify a query param in the auth server URL in the adapter config: "http://server.com/auth?skip_auth_mech=asdfasdf" It looks like the code uses UriBuilder to create the endpoint urls so the query param should stick around. On 10/5/2015 8:41 AM, Michael Gerber wrote: > Ok, I see. > Is there a way to pass an url query parameter through the wildfly > adapter into an authenticator? > > Am 05. Oktober 2015 um 09:39 schrieb Stian Thorgersen : > >> I don't think the account chooser is a good option. As you say users >> that login with Kerberos (and have enabled Kerberos for the Keycloak >> domain) will in 99% cases want to login with Kerberos. >> >> End of the day I don't really like any of these options, and so far >> Michael is the only person asking for something like this. With that >> in mind I think it's better that Michael would develop something >> custom on top of the authenticator spi, rather than us adding this to >> Keycloak. >> >> On 5 October 2015 at 08:01, Michael Gerber > > wrote: >> >> I don't like this approach if the "Account Chooser" page is only >> configurable per realm. >> Because, I think it is a bit annoying if you always have to go >> over the "Account Chooser" page. >> 99% of all uses want to log in with their kerberos credentials, >> there are only a few people which want to switch their account. >> >> But I think your approach is good, if you can enable the "Account >> Chooser" page per client and not only per realm. >> >> Am 02. Oktober 2015 um 16:31 schrieb Bill Burke > >: >> >>> >>> >>> On 10/2/2015 5:26 AM, Stian Thorgersen wrote: >>>> >>>> >>>> On 1 October 2015 at 20:49, Bill Burke >>> >>>> >> wrote: >>>> >>>> Sorry for late reply. >>>> >>>> On 10/1/2015 3:13 AM, Stian Thorgersen wrote: >>>> > * If a user that was logged in using Kerberos logs out the >>>> user should >>>> > not just be automatically logged-in again for the current browser >>>> > session. Instead the user should be displayed with a regular >>>> > username/password field, but also with an option to login with >>>> Kerberos >>>> >>>> Don't like this idea. >>>> >>>> #1 Users that want to bypass kerberos have to know to logout >>>> first so >>>> they can login as a non-kerberos user. >>>> >>>> #2 username/password screen would have to have knowledge that >>>> kerberos >>>> is turned on and that the user was logged in via kerberos. I'm don't >>>> think this is possible with the current SPI. >>>> >>>> >>>> Could we not have a selector or something in the authentication flow >>>> that can select which authenticator to use? The selector could >>>> even be >>>> allowed to prompt the user for input, so we could implement a >>>> "Is this >>>> you" selector. >>>> >>>> >>>> > * A variant on the above where if a user has logged-out from >>>> Kerberos >>>> > the user would be displayed with a "Is this you?" when login, >>>> if the >>>> > user selects yes the Kerberos authenticator would continue, if >>>> not the >>>> > regular username/password form would be displayed >>>> >>>> This one might be easy to do with current SPI although not sure if >>>> kerberos plugin sets some session variables that need to be cleared. >>>> >>>> >>>> I was assuming that this option would also require user to >>>> logout first. >>>> "Is this you" would only be displayed after a logout. >>>> >>> >>> I don't like this "logout required" thing and the logout cookie. >>> What >>> is the big deal about having a screen "You are already logged in via >>> Kerberos. Do you want to continue? Or log in as a different user?" >>> This would be something that is optionally turned on and shown >>> after the >>> Kerberos/SPNEGO handshake. >>> >>> >>>> >>>> >>>> > * Implement account switcher - where a user can login to multiple >>>> > accounts at a time and select which account to use >>>> > >>>> >>>> Not sure how this is different than "Is this you?". >>>> >>>> >>>> "Is this you" would simply prompt the user if the user is the >>>> user that >>>> previously logged in from that browser. >>>> >>>> Account switcher would allow a user to be signed-in to Keycloak with >>>> multiple accounts and provide some mechanism for applications to >>>> select >>>> which account. Like GMail and others allow you to be logged-in to >>>> multiple accounts at a time. >>>> >>> >>> >>> Again, this is very similar to the "Is this you?". The steps >>> would be: >>> >>> 1. SPNEGO handshake successful >>> 2. Show account switcher page with kerberos user as only choice. >>> >>> The only need for a logout persistent cookie is to remember >>> successful >>> logins. >>> >>> I would like this approach the best. >>> >>> >>>> >>>> > Other ideas? Points for ideas that requires no hacks in >>>> applications ;) >>>> > >>>> >>>> idp_hint is a much different animal, isn't it? idp_hint is >>>> provided by >>>> the application. skip_auth_mechanism would be something the user >>>> has to >>>> know about to type in the URL right? >>>> >>>> >>>> We should never have added idp_hint in the first place IMO. It leaks >>>> authentication semantics into applications and also only works >>>> if user >>>> is not logged in already. >>>> >>> >>> idp_hint is a good thing. If an app integrates with Facebook, >>> they'll >>> need to force the user to login via Facebook so they can obtain a >>> Facebook token. >>> >>>> skip_auth_mech could be implemented in applications as well >>>> but my same >>>> point stands here. It requires applications to be aware of >>>> authentication semantics. It seems that what's being proposed >>>> here is >>>> that admins manually add it to the login URL though, but that's >>>> just a >>>> horrible idea, period. >>>> >>> >>> skip_auth_mech is the opposite of auth_mechs_required. Something >>> that I >>> believe SAML has. >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Oct 5 13:35:45 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 5 Oct 2015 13:35:45 -0400 Subject: [keycloak-dev] docs directory structure change Message-ID: <5612B4F1.5050004@redhat.com> There is now: docbook/ /auth-server-docs /saml-adapter-docs The saml adapter is going to be standalone so it needs its own document. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From tom.cerny at gmail.com Mon Oct 5 15:49:13 2015 From: tom.cerny at gmail.com (Tomas Cerny) Date: Mon, 5 Oct 2015 21:49:13 +0200 Subject: [keycloak-dev] Scope Param with Keycloak Message-ID: Hi all, I am trying to use the scope param with keycloak, which is part of the open id http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims Here is an sample URL (from https://openid.net/specs/openid-connect-basic-1_0.html#AuthenticationRequest ) Which is https://server.example.com/authorize? response_type=code &client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=openid%20profile &state=af0ifjsldkj note the state param there with keycloak this is my auth URL: http://127.0.0.1:8080/auth/realms/example/protocol/openid-connect/auth?client_id=js-console&redirect_uri=http://127.0.0.1:8080/js-console/&state=4bb976a4-ad5f-4af5-955d-1b2bdfb738df&response_type=code When I pass scope param, then it is ignored. Does keycloak support scope param? Can I intercept it to make a custom handler? (e.g. lookup DB data) Sample Use Case: Keycloak has my custom UserFederation provides where I issue user lookup to my SQL DB, and determine access, next basing on the scope I like to post back to the app roles relevant to the scope param. I know keycloak has static roles, but I need it contextual, such as - user is master in scope = A, but reader in scope = B. Since the range of scopes is dynamic and large, the use of client-ids is not sufficient. I assume the scope can help me solving situation such as am I owned of an object? I did days of debugging keycloak code and cannot find much even thought there is OAuth2Constants.Scope but may be that is something different? and I seem some dead sample here: FishEye: changeset d309fab8251d95f50f94c77e4d08e6e8c2977994 The alternative OpenAM supports scope param it - OpenAM Project - About OpenAM Thanks, Tom Here a forum public users. https://developer.jboss.org/message/934762#934762 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151005/7f73c08e/attachment.html From sthorger at redhat.com Tue Oct 6 01:14:07 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 6 Oct 2015 07:14:07 +0200 Subject: [keycloak-dev] Kerberos, login with different user In-Reply-To: <561276CE.2050902@redhat.com> References: <561276CE.2050902@redhat.com> Message-ID: On 5 October 2015 at 15:10, Bill Burke wrote: > > > On 10/5/2015 3:39 AM, Stian Thorgersen wrote: > >> I don't think the account chooser is a good option. As you say users >> that login with Kerberos (and have enabled Kerberos for the Keycloak >> domain) will in 99% cases want to login with Kerberos. >> >> > Is logging out of Kerberos a big deal? I have no idea. Never in my > career have I had to log in via kerberos. No, but I thought that was what you where arguing against? > > > End of the day I don't really like any of these options, and so far >> Michael is the only person asking for something like this. With that in >> mind I think it's better that Michael would develop something custom on >> top of the authenticator spi, rather than us adding this to Keycloak. >> >> > I agree, but an account chooser would be a nice feature to add the way I > described it. We got a lot of other stuff to do though that has higher > priority. Maybe I don't understand the account chooser, but it's seems like it's just a way to select if you want to use Kerberos or regular login? What we need is the ability to log in additional accounts and be able to switch between them. That also requires applications to be able to retrieve tokens for the different logged in accounts. > > > > -- > 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-dev/attachments/20151006/fbfacb19/attachment-0001.html From sthorger at redhat.com Tue Oct 6 03:50:19 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 6 Oct 2015 09:50:19 +0200 Subject: [keycloak-dev] Introduce option to select username mode for a realm Message-ID: We've have someone from the community that wants to use mobile number as the username, as well as verify mobile number by sending a code via SMS. See "Login by mobile number" thread in user mailing list for more details. They are also willing to contribute this back to the community. That made me think it may be nice to be able to configure the behavior of the username "field" for a realm. We could have a simple drop-down in the admin console to configure username mode, with the following options: * Username/email - default behavior where a user provides both a username and email, and the user can login with either. In this mode email has to be unique. * Username - a user can only login with a username. In this mode we could relax the requirement that email has to be unique (that may be difficult though as it would require not using a database constraint, which may make it rather difficult to guarantee uniqueness in other modes) * Email - in this mode only email can be used to login. In this mode username field would not be displayed on the registration form or account management console. In the token the username would be set to email. In this mode verify email address should be enabled by default. * Mobile - user logs in with a mobile number. We can either just add mobile number to the username field or add a new mobile field and require uniqueness on that field. In this mode verify mobile number should be enabled by default. With regards to implementation I think it would be easier to make the existing username/password authenticator, registration form and account management adopt to the mode rather than have separate authenticators, etc.. for each mode. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/a3dec2b0/attachment.html From sthorger at redhat.com Tue Oct 6 04:11:36 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 6 Oct 2015 10:11:36 +0200 Subject: [keycloak-dev] Scope Param with Keycloak In-Reply-To: References: Message-ID: We do not currently support scope param and this is something we plan to add in the future. We do have protocol mappers that you can use to add any additional claims to the token for a client. On 5 October 2015 at 21:49, Tomas Cerny wrote: > Hi all, > > > > I am trying to use the scope param with keycloak, which is part of the > open id > > http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims > > Here is an sample URL (from > https://openid.net/specs/openid-connect-basic-1_0.html#AuthenticationRequest > ) > > > > Which is > > https://server.example.com/authorize? > > response_type=code > > &client_id=s6BhdRkqt3 > > &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb > > &scope=openid%20profile > > &state=af0ifjsldkj > > > > note the state param there > > with keycloak this is my auth URL: > http://127.0.0.1:8080/auth/realms/example/protocol/openid-connect/auth?client_id=js-console&redirect_uri=http://127.0.0.1:8080/js-console/&state=4bb976a4-ad5f-4af5-955d-1b2bdfb738df&response_type=code > > > > When I pass scope param, then it is ignored. > > > > Does keycloak support scope param? Can I intercept it to make a custom > handler? (e.g. lookup DB data) > > > > Sample Use Case: Keycloak has my custom UserFederation provides where I > issue user lookup to my SQL DB, and determine access, next basing on the > scope I like to post back to the app roles relevant to the scope param. > > > > I know keycloak has static roles, but I need it contextual, such as - user > is master in scope = A, but reader in scope = B. Since the range of scopes > is dynamic and large, the use of client-ids is not sufficient. > > > > I assume the scope can help me solving situation such as am I owned of an > object? > > > > I did days of debugging keycloak code and cannot find much even thought > there is OAuth2Constants.Scope but may be that is something different? > > > > and I seem some dead sample here: FishEye: changeset > d309fab8251d95f50f94c77e4d08e6e8c2977994 > > > > > > > The alternative OpenAM supports scope param it - OpenAM Project - About > OpenAM > > > > Thanks, Tom > > Here a forum public users. > https://developer.jboss.org/message/934762#934762 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/c359c09a/attachment.html From sthorger at redhat.com Tue Oct 6 06:35:54 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 6 Oct 2015 12:35:54 +0200 Subject: [keycloak-dev] Interested in joining the Keycloak team? Message-ID: Are you interested in joining the Keycloak team? We're looking for a new member of the team. For more details go to http://jobs.redhat.com/jobs/descriptions/senior-software-engineer-brno-jihomoravsky-kraj-czech-republic-job-1-5879315 . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/b7f02d83/attachment.html From sthorger at redhat.com Tue Oct 6 07:12:00 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 6 Oct 2015 13:12:00 +0200 Subject: [keycloak-dev] RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients In-Reply-To: <301390434.2674739.1443526131745.JavaMail.yahoo@mail.yahoo.com> References: <301390434.2674739.1443526131745.JavaMail.yahoo@mail.yahoo.com> Message-ID: We've looked at it and it's something we'd like to add, but as usual we have to many other things on our hands at the moment On 29 September 2015 at 13:28, Raghuram Prabhala wrote: > Any plans to implement the below? > > http://www.rfc-editor.org/rfc/rfc7636.txt > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/3d87041f/attachment.html From gautric at redhat.com Tue Oct 6 09:11:28 2015 From: gautric at redhat.com (Greg Autric) Date: Tue, 6 Oct 2015 09:11:28 -0400 (EDT) Subject: [keycloak-dev] U2F implemetation In-Reply-To: <13802065.40123403.1444136587423.JavaMail.zimbra@redhat.com> Message-ID: <1915394626.40128278.1444137088661.JavaMail.zimbra@redhat.com> Hi All, I would like develop the u2f feature. I noticed the JIRA ticket [1] I would like to know how can I begin with ? - 2/3 key classes - add u2f attribut to User Model - maybe reuse OTP workflow/action by advance, thx for your help [1] https://issues.jboss.org/browse/KEYCLOAK-1409 Greg AUTRIC JBoss Middleware Consultant email : gautric __at__ redhat __dot__ com twitter : @gautric_io Red Hat Global Services Red Hat France SARL sit: http://www.redhat.fr Le Linea, 1 rue du General Leclerc, 92047 Paris La D?fense Cedex Sent from webmail From mikhail.kuznetsov at hpe.com Tue Oct 6 10:34:07 2015 From: mikhail.kuznetsov at hpe.com (Kuznetsov, Mike) Date: Tue, 6 Oct 2015 14:34:07 +0000 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token Message-ID: <66122567ABACCC42B5B568EC7E90551A1A73CE57@G1W3780.americas.hpqcorp.net> Hello, I noticed that with Keycloak, it seems that refresh tokens are still valid after they are used once. This means that Keycloak does not invalidate Refresh Tokens after they have been used once. I am able to successfully execute the following flow: 1. Obtain Access Token (A1) and Refresh Token (R1) 2. Use Refresh Token (R1) to obtain new Access Token (A2) and Refresh Token (R2) 3. Use same Refresh Token (R1) again to obtain new Access Token (A3) and Refresh Token (R3) Can you please tell me if this is the intended functionality? Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/2a537f14/attachment.html From mposolda at redhat.com Tue Oct 6 10:53:50 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 6 Oct 2015 16:53:50 +0200 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <66122567ABACCC42B5B568EC7E90551A1A73CE57@G1W3780.americas.hpqcorp.net> References: <66122567ABACCC42B5B568EC7E90551A1A73CE57@G1W3780.americas.hpqcorp.net> Message-ID: <5613E07E.6010708@redhat.com> You're right, same refresh token can be used more times. However it is still better to use refresh token R2 in your step 3 instead of using old refresh token R1 because R2 has updated timestamp (each token is valid just for 30 minutes or so, depends on the configured SSO session idle timeout). Or are you referring that this is security issue and potential possibility to Man in the middle? If you use HTTPS (which is recommended for production environment, and especially if you have unsecured/untrusted networkl), this shouldn't be an issue. Marek On 06/10/15 16:34, Kuznetsov, Mike wrote: > > Hello, > > I noticed that with Keycloak, it seems that refresh tokens are still > valid after they are used once. This means that Keycloak does *not* > invalidate Refresh Tokens after they have been used once. > > I am able to successfully execute the following flow: > > 1.Obtain Access Token (A1) and Refresh Token (R1) > > 2.Use Refresh Token (R1) to obtain new Access Token (A2) and Refresh > Token (R2) > > 3.Use same Refresh Token (R1) again to obtain new Access Token (A3) > and Refresh Token (R3) > > Can you please tell me if this is the intended functionality? > > Thank You, > > > *Mikhail Kuznetsov* > > Software Engineer > > Hewlett Packard Enterprise > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/e43bc43a/attachment.html From prabhalar at yahoo.com Tue Oct 6 11:37:46 2015 From: prabhalar at yahoo.com (Raghu Prabhala) Date: Tue, 6 Oct 2015 11:37:46 -0400 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <5613E07E.6010708@redhat.com> References: <66122567ABACCC42B5B568EC7E90551A1A73CE57@G1W3780.americas.hpqcorp.net> <5613E07E.6010708@redhat.com> Message-ID: <20768180-BBB8-45B4-BFE6-7C376F642CFA@yahoo.com> Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh token should be invalidated but retained by the server - to handle compromise of refresh tokens as they are long lived. Thanks, Raghu Sent from my iPhone > On Oct 6, 2015, at 10:53 AM, Marek Posolda wrote: > > You're right, same refresh token can be used more times. However it is still better to use refresh token R2 in your step 3 instead of using old refresh token R1 because R2 has updated timestamp (each token is valid just for 30 minutes or so, depends on the configured SSO session idle timeout). > > Or are you referring that this is security issue and potential possibility to Man in the middle? If you use HTTPS (which is recommended for production environment, and especially if you have unsecured/untrusted networkl), this shouldn't be an issue. > > Marek > >> On 06/10/15 16:34, Kuznetsov, Mike wrote: >> Hello, >> >> I noticed that with Keycloak, it seems that refresh tokens are still valid after they are used once. This means that Keycloak does not invalidate Refresh Tokens after they have been used once. >> >> I am able to successfully execute the following flow: >> 1. Obtain Access Token (A1) and Refresh Token (R1) >> 2. Use Refresh Token (R1) to obtain new Access Token (A2) and Refresh Token (R2) >> 3. Use same Refresh Token (R1) again to obtain new Access Token (A3) and Refresh Token (R3) >> >> >> Can you please tell me if this is the intended functionality? >> >> Thank You, >> >> Mikhail Kuznetsov >> Software Engineer >> Hewlett Packard Enterprise >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/4db7a8d5/attachment-0001.html From mposolda at redhat.com Tue Oct 6 13:16:18 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 6 Oct 2015 19:16:18 +0200 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <20768180-BBB8-45B4-BFE6-7C376F642CFA@yahoo.com> References: <66122567ABACCC42B5B568EC7E90551A1A73CE57@G1W3780.americas.hpqcorp.net> <5613E07E.6010708@redhat.com> <20768180-BBB8-45B4-BFE6-7C376F642CFA@yahoo.com> Message-ID: <561401E2.6080301@redhat.com> Hi Raghu, From the specs, it looks to me that this is not anything mandatory. The paragraph is starting "For example". Feel free to create JIRA, but I personally can't promise anything regarding this... Marek On 06/10/15 17:37, Raghu Prabhala wrote: > Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh > token should be invalidated but retained by the server - to handle > compromise of refresh tokens as they are long lived. > > Thanks, > Raghu > > Sent from my iPhone > > On Oct 6, 2015, at 10:53 AM, Marek Posolda > wrote: > >> You're right, same refresh token can be used more times. However it >> is still better to use refresh token R2 in your step 3 instead of >> using old refresh token R1 because R2 has updated timestamp (each >> token is valid just for 30 minutes or so, depends on the configured >> SSO session idle timeout). >> >> Or are you referring that this is security issue and potential >> possibility to Man in the middle? If you use HTTPS (which is >> recommended for production environment, and especially if you have >> unsecured/untrusted networkl), this shouldn't be an issue. >> >> Marek >> >> On 06/10/15 16:34, Kuznetsov, Mike wrote: >>> >>> Hello, >>> >>> I noticed that with Keycloak, it seems that refresh tokens are still >>> valid after they are used once. This means that Keycloak does *not* >>> invalidate Refresh Tokens after they have been used once. >>> >>> I am able to successfully execute the following flow: >>> >>> 1.Obtain Access Token (A1) and Refresh Token (R1) >>> >>> 2.Use Refresh Token (R1) to obtain new Access Token (A2) and Refresh >>> Token (R2) >>> >>> 3.Use same Refresh Token (R1) again to obtain new Access Token (A3) >>> and Refresh Token (R3) >>> >>> Can you please tell me if this is the intended functionality? >>> >>> Thank You, >>> >>> >>> *Mikhail Kuznetsov* >>> >>> Software Engineer >>> >>> Hewlett Packard Enterprise >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/49387268/attachment.html From ssilvert at redhat.com Tue Oct 6 14:47:09 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 06 Oct 2015 14:47:09 -0400 Subject: [keycloak-dev] Hacking Tips Message-ID: <5614172D.6010709@redhat.com> In talking with Marko, I shared some of my hacking tips to aid with i18n/l10n development. But they are generally handy for easing all Keycloak development. Others might have other ways to improve on this stuff and make our lives easier? Here are mine: *Build server-dist without artifacts *I think Bill gets the credit for making this possible in WildFly. You can build it such that jars are not copied to the server. Instead, they are retrieved from your local maven repo. For Keycloak, you go to /distribution/server-dist/server-provisioning.xml and set copy-module-artifacts="false". Now when you compile any of Keycloak's java modules you just restart the server and see your changes. It would be nice if we could use a system property for this, but it looks like server-provisioning.xml doesn't support props for that attribute. Some day I'll fix it and submit a patch. Anyway, doing that and running mvn compile instead of mvn install brings the build time from 3 minutes to about 6 seconds. Only 6 seconds to build the whole server! I use Windows and Cygwin to do this automatically in a batch file: cd c:\GitHub\keycloak\distribution\server-dist call mvn clean sed -i 's/copy-module-artifacts="true"/copy-module-artifacts="false"/' server-provisioning.xml call mvn compile sed -i 's/copy-module-artifacts="false"/copy-module-artifacts="true"/' server-provisioning.xml *Let the the default theme point to your maven clone instead of /standalone/configuration/themes *You can tell Keycloak to load the default theme from your development environment. This is especially handy when you are working on HTML or JS files for Keycloak Admin Console. To do this, edit keycloak-server.json. Here is the batch file code I use to automate it: cd c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\standalone\configuration sed -i 's,"dir": "${jboss.server.config.dir}/themes","dir": "/GitHub/keycloak/forms/common-themes/src/main/resources/theme",' keycloak-server.json Note: I had to use a comma for my sed delimiter instead of forward slash / *Turn off caching in your browser. *You need to turn off caching to see your HTML and JS changes as soon as you edit them. But it can be a pain to turn caching on and off. I found a nifty FireFox extension called "Cache Disabler" that puts a little button in my toolbar to enable/disable all caching. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/dfda8b48/attachment.html From mposolda at redhat.com Tue Oct 6 15:36:32 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 6 Oct 2015 21:36:32 +0200 Subject: [keycloak-dev] Hacking Tips In-Reply-To: <5614172D.6010709@redhat.com> References: <5614172D.6010709@redhat.com> Message-ID: <561422C0.5000400@redhat.com> Thanks for sharing. Some of my tips: Whenever possible, I am using KeycloakServer from testsuite for development. This uses Keycloak on embedded Undertow instead of Wildfly/EAP. This is not possible just when I need to develop/test something, which really requires "real" Wildfly/EAP6 environment (examples, subsystems, doublecheck that modules.xml are not broken etc) In addition, when I add system property "-Dresources", the UI development is super-easy because: - Caching headers are disabled on server side for theme files, so browser caching is effectively disabled - Themes use local filesystem In other words, when I do some change in HTML or JS file, there is no need to restart server. It's sufficient to logout/login to see all your changes Also I am using Mongo for development when possible. This has advantage that data are persistent among restarts and KeycloakServer restart took me around 2 seconds. Marek On 06/10/15 20:47, Stan Silvert wrote: > In talking with Marko, I shared some of my hacking tips to aid with > i18n/l10n development. But they are generally handy for easing all > Keycloak development. Others might have other ways to improve on this > stuff and make our lives easier? > > Here are mine: > > *Build server-dist without artifacts > *I think Bill gets the credit for making this possible in WildFly. > You can build it such that jars are not copied to the server. > Instead, they are retrieved from your local maven repo. For Keycloak, > you go to /distribution/server-dist/server-provisioning.xml and set > copy-module-artifacts="false". > > Now when you compile any of Keycloak's java modules you just restart > the server and see your changes. > > It would be nice if we could use a system property for this, but it > looks like server-provisioning.xml doesn't support props for that > attribute. Some day I'll fix it and submit a patch. > > Anyway, doing that and running mvn compile instead of mvn install > brings the build time from 3 minutes to about 6 seconds. Only 6 > seconds to build the whole server! > > I use Windows and Cygwin to do this automatically in a batch file: > > cd c:\GitHub\keycloak\distribution\server-dist > call mvn clean > sed -i 's/copy-module-artifacts="true"/copy-module-artifacts="false"/' > server-provisioning.xml > call mvn compile > sed -i 's/copy-module-artifacts="false"/copy-module-artifacts="true"/' > server-provisioning.xml > > *Let the the default theme point to your maven clone instead of > /standalone/configuration/themes > *You can tell Keycloak to load the default theme from your development > environment. This is especially handy when you are working on HTML or > JS files for Keycloak Admin Console. To do this, edit > keycloak-server.json. Here is the batch file code I use to automate it: > > cd > c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\standalone\configuration > sed -i 's,"dir": "${jboss.server.config.dir}/themes","dir": > "/GitHub/keycloak/forms/common-themes/src/main/resources/theme",' > keycloak-server.json > > Note: I had to use a comma for my sed delimiter instead of forward slash / > > *Turn off caching in your browser. > *You need to turn off caching to see your HTML and JS changes as soon > as you edit them. But it can be a pain to turn caching on and off. I > found a nifty FireFox extension called "Cache Disabler" that puts a > little button in my toolbar to enable/disable all caching. > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/e082a07e/attachment-0001.html From mikhail.kuznetsov at hpe.com Tue Oct 6 16:34:29 2015 From: mikhail.kuznetsov at hpe.com (Kuznetsov, Mike) Date: Tue, 6 Oct 2015 20:34:29 +0000 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <561401E2.6080301@redhat.com> References: <66122567ABACCC42B5B568EC7E90551A1A73CE57@G1W3780.americas.hpqcorp.net> <5613E07E.6010708@redhat.com> <20768180-BBB8-45B4-BFE6-7C376F642CFA@yahoo.com> <561401E2.6080301@redhat.com> Message-ID: <66122567ABACCC42B5B568EC7E90551A1A740F93@G1W3780.americas.hpqcorp.net> Hello, The reason I brought this up is that we are currently working on migrating out authentication from a commercially available product called Ping to Keycloak. We noticed that Ping invalidates the refresh token after it is used once, while Keycloak does not. I and my colleague, Kamal are concerned that by not invalidating the refresh token after first use, we may be opening a security hole. While SSL may protect the token in transit, we can see a scenario where the refresh token would be compromised or stolen from the client itself. In this case, the stolen refresh token could be used to get new access tokens without the owner of the client machine knowing. However, if the behavior was changed so that the refresh token could only be used once, then either: 1. If the owner of the client machine would use the refresh token first, then the stolen refresh token could not be used 2. If the stolen refresh token would be used first, then the client machine would not be able to use it and the user of that client machine could be alerted that something was wrong. This user could then reset their password or invalidate all of their access and refresh tokens. Furthermore, we are concerned about this same scenario, but with the offline token. My understanding is that the offline token does not expire and that it can?t be invalidated by logging out the user or changing the user?s password. Have you thought about this scenario? Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Tuesday, October 06, 2015 1:16 PM To: Raghu Prabhala Cc: Kuznetsov, Mike; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token Hi Raghu, From the specs, it looks to me that this is not anything mandatory. The paragraph is starting "For example". Feel free to create JIRA, but I personally can't promise anything regarding this... Marek On 06/10/15 17:37, Raghu Prabhala wrote: Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh token should be invalidated but retained by the server - to handle compromise of refresh tokens as they are long lived. Thanks, Raghu Sent from my iPhone On Oct 6, 2015, at 10:53 AM, Marek Posolda > wrote: You're right, same refresh token can be used more times. However it is still better to use refresh token R2 in your step 3 instead of using old refresh token R1 because R2 has updated timestamp (each token is valid just for 30 minutes or so, depends on the configured SSO session idle timeout). Or are you referring that this is security issue and potential possibility to Man in the middle? If you use HTTPS (which is recommended for production environment, and especially if you have unsecured/untrusted networkl), this shouldn't be an issue. Marek On 06/10/15 16:34, Kuznetsov, Mike wrote: Hello, I noticed that with Keycloak, it seems that refresh tokens are still valid after they are used once. This means that Keycloak does not invalidate Refresh Tokens after they have been used once. I am able to successfully execute the following flow: 1. Obtain Access Token (A1) and Refresh Token (R1) 2. Use Refresh Token (R1) to obtain new Access Token (A2) and Refresh Token (R2) 3. Use same Refresh Token (R1) again to obtain new Access Token (A3) and Refresh Token (R3) Can you please tell me if this is the intended functionality? Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/e0797e86/attachment-0001.html From sartman at capson.com Tue Oct 6 17:16:50 2015 From: sartman at capson.com (Scott Artman) Date: Tue, 6 Oct 2015 21:16:50 +0000 Subject: [keycloak-dev] Using a custom Protocol Mapper to store granular permissions in a token Message-ID: I?m considering migrating a custom authentication and authorization framework to KeyCloak. I like KeyCloak?s authentication support and role to user mapping capabilities. However, I haven?t seen a feature to replace the granular permission support we have in our custom framework. We assign permissions to individual roles and use them to secure resources such as application pages, specific fields within a page, buttons, menu items, etc. One option that may work is the Protocol Mapping feature mentioned in this blog post: http://blog.keycloak.org/2015/03/customizing-keycloak.html. I would like to use a custom Protocol Mapper to store a permission map within a token for the roles associated with a user. Can someone point me to documentation that outlines how to write a custom Protocol Mapper and configure KeyCloak to use it? Thanks, Scott CONFIDENTIALITY NOTICE This e-mail, including any attachments, may include confidential and/or proprietary information from Capson Corp. and/or its subsidiaries or affiliates, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151006/df3236ad/attachment.html From prabhalar at yahoo.com Tue Oct 6 22:27:26 2015 From: prabhalar at yahoo.com (Raghuram Prabhala) Date: Wed, 7 Oct 2015 02:27:26 +0000 (UTC) Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <66122567ABACCC42B5B568EC7E90551A1A740F93@G1W3780.americas.hpqcorp.net> References: <66122567ABACCC42B5B568EC7E90551A1A740F93@G1W3780.americas.hpqcorp.net> Message-ID: <710997604.1735164.1444184846487.JavaMail.yahoo@mail.yahoo.com> Very valid points Mike and even I have similar concerns. But please do understand that even if the refresh token is stolen or compromised,it cannot be used by any client unless both the client_id and client_secret are also compromised/stolen. But nevertheless, it is a good practice to assume the worst and add in protective measures to minimize the chances.? Marek/Bill/Stian - Even our organization is very particular that such potential security issues be addressed. Can this be taken up? BTW I am not sure if you have an API/End point to invalidate tokens for those that are either compromised or must be invalidated as either the user or client is no longer active. If you do not have one then it is a good idea to make one available. Thanks,Raghu From: "Kuznetsov, Mike" To: "keycloak-dev at lists.jboss.org" Cc: "Jagadevan, Kamal" Sent: Tuesday, October 6, 2015 4:34 PM Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token #yiv9982859949 #yiv9982859949 -- _filtered #yiv9982859949 {font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv9982859949 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv9982859949 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv9982859949 {font-family:Consolas;panose-1:2 11 6 9 2 2 4 3 2 4;}#yiv9982859949 #yiv9982859949 p.yiv9982859949MsoNormal, #yiv9982859949 li.yiv9982859949MsoNormal, #yiv9982859949 div.yiv9982859949MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;color:black;}#yiv9982859949 a:link, #yiv9982859949 span.yiv9982859949MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv9982859949 a:visited, #yiv9982859949 span.yiv9982859949MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv9982859949 pre {margin:0in;margin-bottom:.0001pt;font-size:10.0pt;color:black;}#yiv9982859949 p.yiv9982859949MsoListParagraph, #yiv9982859949 li.yiv9982859949MsoListParagraph, #yiv9982859949 div.yiv9982859949MsoListParagraph {margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:11.0pt;color:black;}#yiv9982859949 span.yiv9982859949EmailStyle18 {color:windowtext;}#yiv9982859949 span.yiv9982859949EmailStyle19 {color:#1F497D;}#yiv9982859949 span.yiv9982859949HTMLPreformattedChar {font-family:Consolas;color:black;}#yiv9982859949 span.yiv9982859949EmailStyle22 {color:#1F497D;}#yiv9982859949 .yiv9982859949MsoChpDefault {font-size:10.0pt;} _filtered #yiv9982859949 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv9982859949 div.yiv9982859949WordSection1 {}#yiv9982859949 _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {font-family:Wingdings;} _filtered #yiv9982859949 {font-family:Symbol;} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {font-family:Wingdings;} _filtered #yiv9982859949 {font-family:Symbol;} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {font-family:Wingdings;} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {} _filtered #yiv9982859949 {}#yiv9982859949 ol {margin-bottom:0in;}#yiv9982859949 ul {margin-bottom:0in;}#yiv9982859949 Hello, ? The reason I brought this up is that we are currently working on migrating out authentication from a commercially available product called Ping to Keycloak. We noticed that Ping invalidates the refresh token after it is used once, while Keycloak does not. ? I and my colleague, Kamal are concerned that by not invalidating the refresh token after first use, we may be opening a security hole. While SSL may protect the token in transit, we can see a scenario where the refresh token would be compromised or stolen from the client itself. In this case, the stolen refresh token could be used to get new access tokens without the owner of the client machine knowing. ? However, if the behavior was changed so that the refresh token could only be used once, then either: 1.??????If the owner of the client machine would use the refresh token first, then the stolen refresh token could not be used 2.??????If the stolen refresh token would be used first, then the client machine would not be able to use it and the user of that client machine could be alerted that something was wrong. This user could then reset their password or invalidate all of their access and refresh tokens. ? Furthermore, we are concerned about this same scenario, but with the offline token. My understanding is that the offline token does not expire and that it can?t be invalidated by logging out the user or changing the user?s password. Have you thought about this scenario? ? Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise ? From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Tuesday, October 06, 2015 1:16 PM To: Raghu Prabhala Cc: Kuznetsov, Mike; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token ? Hi Raghu, >From the specs, it looks to me that this is not anything mandatory. The paragraph is starting "For example". Feel free to create JIRA, but I personally can't promise anything regarding this... Marek On 06/10/15 17:37, Raghu Prabhala wrote: Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh token should be invalidated but retained by the server - to handle compromise of refresh tokens as they are long lived.? ? Thanks, Raghu Sent from my iPhone On Oct 6, 2015, at 10:53 AM, Marek Posolda wrote: You're right, same refresh token can be used more times. However it is still better to use refresh token R2 in your step 3 instead of using old refresh token R1 because R2 has updated timestamp (each token is valid just for 30 minutes or so, depends on the configured SSO session idle timeout). Or are you referring that this is security issue and potential possibility to Man in the middle? If you use HTTPS (which is recommended for production environment, and especially if you have unsecured/untrusted networkl), this shouldn't be an issue. Marek On 06/10/15 16:34, Kuznetsov, Mike wrote: Hello, ? I noticed that with Keycloak, it seems that refresh tokens are still valid after they are used once. This means that Keycloak doesnot invalidate Refresh Tokens after they have been used once. ? I am able to successfully execute the following flow: 1.??????Obtain Access Token (A1) and Refresh Token (R1) 2.??????Use Refresh Token (R1) to obtain new Access Token (A2) and Refresh Token (R2) 3.??????Use same Refresh Token (R1) again to obtain new Access Token (A3) and Refresh Token (R3) ? ? Can you please tell me if this is the intended functionality? ? Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise ? _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev ? _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev ? _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/78394adc/attachment-0001.html From sthorger at redhat.com Wed Oct 7 02:36:04 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 7 Oct 2015 08:36:04 +0200 Subject: [keycloak-dev] Hacking Tips In-Reply-To: <561422C0.5000400@redhat.com> References: <5614172D.6010709@redhat.com> <561422C0.5000400@redhat.com> Message-ID: Another plus with KeycloakServer is no need to run Maven, just let your IDE build classes for you in the background On 6 October 2015 at 21:36, Marek Posolda wrote: > Thanks for sharing. > > Some of my tips: Whenever possible, I am using KeycloakServer from > testsuite for development. This uses Keycloak on embedded Undertow instead > of Wildfly/EAP. This is not possible just when I need to develop/test > something, which really requires "real" Wildfly/EAP6 environment (examples, > subsystems, doublecheck that modules.xml are not broken etc) > > In addition, when I add system property "-Dresources", the UI development > is super-easy because: > - Caching headers are disabled on server side for theme files, so browser > caching is effectively disabled > - Themes use local filesystem > > In other words, when I do some change in HTML or JS file, there is no need > to restart server. It's sufficient to logout/login to see all your changes > > Also I am using Mongo for development when possible. This has advantage > that data are persistent among restarts and KeycloakServer restart took me > around 2 seconds. > > Marek > > > > On 06/10/15 20:47, Stan Silvert wrote: > > In talking with Marko, I shared some of my hacking tips to aid with > i18n/l10n development. But they are generally handy for easing all > Keycloak development. Others might have other ways to improve on this > stuff and make our lives easier? > > Here are mine: > > > *Build server-dist without artifacts *I think Bill gets the credit for > making this possible in WildFly. You can build it such that jars are not > copied to the server. Instead, they are retrieved from your local maven > repo. For Keycloak, you go to > /distribution/server-dist/server-provisioning.xml and set > copy-module-artifacts="false". > > Now when you compile any of Keycloak's java modules you just restart the > server and see your changes. > > It would be nice if we could use a system property for this, but it looks > like server-provisioning.xml doesn't support props for that attribute. > Some day I'll fix it and submit a patch. > > Anyway, doing that and running mvn compile instead of mvn install brings > the build time from 3 minutes to about 6 seconds. Only 6 seconds to build > the whole server! > > I use Windows and Cygwin to do this automatically in a batch file: > > cd c:\GitHub\keycloak\distribution\server-dist > call mvn clean > sed -i 's/copy-module-artifacts="true"/copy-module-artifacts="false"/' > server-provisioning.xml > call mvn compile > sed -i 's/copy-module-artifacts="false"/copy-module-artifacts="true"/' > server-provisioning.xml > > > *Let the the default theme point to your maven clone instead of > /standalone/configuration/themes *You can tell Keycloak to load the > default theme from your development environment. This is especially handy > when you are working on HTML or JS files for Keycloak Admin Console. To do > this, edit keycloak-server.json. Here is the batch file code I use to > automate it: > > cd > c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\standalone\configuration > sed -i 's,"dir": "${jboss.server.config.dir}/themes","dir": > "/GitHub/keycloak/forms/common-themes/src/main/resources/theme",' > keycloak-server.json > > Note: I had to use a comma for my sed delimiter instead of forward slash / > > > *Turn off caching in your browser. *You need to turn off caching to see > your HTML and JS changes as soon as you edit them. But it can be a pain to > turn caching on and off. I found a nifty FireFox extension called "Cache > Disabler" that puts a little button in my toolbar to enable/disable all > caching. > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/4612a758/attachment.html From sthorger at redhat.com Wed Oct 7 07:57:46 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 7 Oct 2015 13:57:46 +0200 Subject: [keycloak-dev] Support multiple 2nd factor types Message-ID: At least for now we should add support for multiple types of OTP: * Software tokens * Hardware tokens * U2F It should be possible for an administrator to select what mechanisms are available for a realm. We need the option to enforce that a user has at least one 2nd factor authentication associated with the account. Then it should be possible for adminstrators to provision tokens on behalf of users, but also for users themselves to provision their own. For hardware tokens a lot of them use the same algorithm as the software token, but on caveat is that you need to be able to exchange a device-id for the token secret. This could be a rest endpoint or a lookup in a database, but I don't think there's a generic approach available so maybe we need to introduce an SPI for this. Are we able to do the above with the current Authenticator SPI? We also need: * Account management - users should be able to choose which mechanism to use if there's more than one enabled for a realm * Required action to enable OTP - same as above * Admin console - administrators should be able to provision on behalf of users * We need to refer to it as 2nd factor or multi-factor as OTP is just one possible mechanism. Other simple examples could be sending a code to email or sms which has to be copy/pasted back to the login forms. Looks like we have a community member that is willing to contribute U2F and another that could contribute hardware tokens. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/fbd5528f/attachment.html From mposolda at redhat.com Wed Oct 7 08:12:42 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 7 Oct 2015 14:12:42 +0200 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <710997604.1735164.1444184846487.JavaMail.yahoo@mail.yahoo.com> References: <66122567ABACCC42B5B568EC7E90551A1A740F93@G1W3780.americas.hpqcorp.net> <710997604.1735164.1444184846487.JavaMail.yahoo@mail.yahoo.com> Message-ID: <56150C3A.90702@redhat.com> The points are valid and security can be always improved, however sometimes improving security makes things complicated with the not-so-big advantage... IMO admin should always protect the machine to make sure that nobody unauthorized has access to refresh tokens. And for the transport, HTTPS should be always used. But feel free to create JIRA and we will see... When user or client is deleted, all refresh/offline tokens will defacto become invalid as well and can't be used anymore. You're right that offline token is still valid after user logout. User can revoke it manually in account management or admin can revoke it in admin console. However refresh token is invalid after user logout. All refresh/offline tokens for particular client can be revoked by admin by set notBefore policy to now, which can be done in admin console in "Revocation" tab of particular client. Marek On 07/10/15 04:27, Raghuram Prabhala wrote: > Very valid points Mike and even I have similar concerns. But please do > understand that even if the refresh token is stolen or compromised,it > cannot be used by any client unless both the client_id and > client_secret are also compromised/stolen. But nevertheless, it is a > good practice to assume the worst and add in protective measures to > minimize the chances. > > Marek/Bill/Stian - Even our organization is very particular that such > potential security issues be addressed. Can this be taken up? BTW I am > not sure if you have an API/End point to invalidate tokens for those > that are either compromised or must be invalidated as either the user > or client is no longer active. If you do not have one then it is a > good idea to make one available. > > Thanks, > Raghu > > ------------------------------------------------------------------------ > *From:* "Kuznetsov, Mike" > *To:* "keycloak-dev at lists.jboss.org" > *Cc:* "Jagadevan, Kamal" > *Sent:* Tuesday, October 6, 2015 4:34 PM > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > Hello, > The reason I brought this up is that we are currently working on > migrating out authentication from a commercially available product > called Ping to Keycloak. We noticed that Ping invalidates the refresh > token after it is used once, while Keycloak does not. > I and my colleague, Kamal are concerned that by not invalidating the > refresh token after first use, we may be opening a security hole. > While SSL may protect the token in transit, we can see a scenario > where the refresh token would be compromised or stolen from the client > itself. In this case, the stolen refresh token could be used to get > new access tokens without the owner of the client machine knowing. > However, if the behavior was changed so that the refresh token could > only be used once, then either: > 1.If the owner of the client machine would use the refresh token > first, then the stolen refresh token could not be used > 2.If the stolen refresh token would be used first, then the client > machine would not be able to use it and the user of that client > machine could be alerted that something was wrong. This user could > then reset their password or invalidate all of their access and > refresh tokens. > Furthermore, we are concerned about this same scenario, but with the > offline token. My understanding is that the offline token does not > expire and that it can?t be invalidated by logging out the user or > changing the user?s password. Have you thought about this scenario? > Thank You, > > *Mikhail Kuznetsov* > Software Engineer > Hewlett Packard Enterprise > > > *From:*Marek Posolda [mailto:mposolda at redhat.com] > *Sent:* Tuesday, October 06, 2015 1:16 PM > *To:* Raghu Prabhala > *Cc:* Kuznetsov, Mike; keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > Hi Raghu, > > >From the specs, it looks to me that this is not anything mandatory. > The paragraph is starting "For example". Feel free to create JIRA, but > I personally can't promise anything regarding this... > > Marek > > > On 06/10/15 17:37, Raghu Prabhala wrote: > > Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh > token should be invalidated but retained by the server - to handle > compromise of refresh tokens as they are long lived. > Thanks, > Raghu > > Sent from my iPhone > > On Oct 6, 2015, at 10:53 AM, Marek Posolda > wrote: > > You're right, same refresh token can be used more times. > However it is still better to use refresh token R2 in your > step 3 instead of using old refresh token R1 because R2 has > updated timestamp (each token is valid just for 30 minutes or > so, depends on the configured SSO session idle timeout). > > Or are you referring that this is security issue and potential > possibility to Man in the middle? If you use HTTPS (which is > recommended for production environment, and especially if you > have unsecured/untrusted networkl), this shouldn't be an issue. > > Marek > > On 06/10/15 16:34, Kuznetsov, Mike wrote: > > Hello, > I noticed that with Keycloak, it seems that refresh tokens > are still valid after they are used once. This means that > Keycloak does *not* invalidate Refresh Tokens after they > have been used once. > I am able to successfully execute the following flow: > 1.Obtain Access Token (A1) and Refresh Token (R1) > 2.Use Refresh Token (R1) to obtain new Access Token (A2) > and Refresh Token (R2) > 3.Use same Refresh Token (R1) again to obtain new Access > Token (A3) and Refresh Token (R3) > Can you please tell me if this is the intended functionality? > Thank You, > > *Mikhail Kuznetsov* > Software Engineer > Hewlett Packard Enterprise > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/3462fa89/attachment-0001.html From sthorger at redhat.com Wed Oct 7 08:23:30 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 7 Oct 2015 14:23:30 +0200 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <56150C3A.90702@redhat.com> References: <66122567ABACCC42B5B568EC7E90551A1A740F93@G1W3780.americas.hpqcorp.net> <710997604.1735164.1444184846487.JavaMail.yahoo@mail.yahoo.com> <56150C3A.90702@redhat.com> Message-ID: We should make this configurable. For those worried about security they can enforce new refresh tokens as well as offline tokens will replace the old tokens. It would be fairly simply to implement. If enabled we would only allow refresh token where iat is >= the last session refresh time. I wouldn't make it default behavior for two reasons: * It would break existing clients if they expect to continue using the old refresh token * It comes at a performance cost as clients will have to store the new refresh tokens and offline tokens each time they refresh the token * For offline tokens Keycloak would also have to persist the last refresh time each time the offline token is refreshed I think we'd need to make it a realm wide configuration option. On 7 October 2015 at 14:12, Marek Posolda wrote: > The points are valid and security can be always improved, however > sometimes improving security makes things complicated with the not-so-big > advantage... IMO admin should always protect the machine to make sure that > nobody unauthorized has access to refresh tokens. And for the transport, > HTTPS should be always used. But feel free to create JIRA and we will see... > > When user or client is deleted, all refresh/offline tokens will defacto > become invalid as well and can't be used anymore. You're right that offline > token is still valid after user logout. User can revoke it manually in > account management or admin can revoke it in admin console. However refresh > token is invalid after user logout. All refresh/offline tokens for > particular client can be revoked by admin by set notBefore policy to now, > which can be done in admin console in "Revocation" tab of particular client. > > Marek > > > On 07/10/15 04:27, Raghuram Prabhala wrote: > > Very valid points Mike and even I have similar concerns. But please do > understand that even if the refresh token is stolen or compromised,it > cannot be used by any client unless both the client_id and client_secret > are also compromised/stolen. But nevertheless, it is a good practice to > assume the worst and add in protective measures to minimize the chances. > > Marek/Bill/Stian - Even our organization is very particular that such > potential security issues be addressed. Can this be taken up? BTW I am not > sure if you have an API/End point to invalidate tokens for those that are > either compromised or must be invalidated as either the user or client is > no longer active. If you do not have one then it is a good idea to make one > available. > > Thanks, > Raghu > > ------------------------------ > *From:* "Kuznetsov, Mike" > > *To:* "keycloak-dev at lists.jboss.org" > > *Cc:* "Jagadevan, Kamal" > > *Sent:* Tuesday, October 6, 2015 4:34 PM > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > Hello, > > The reason I brought this up is that we are currently working on migrating > out authentication from a commercially available product called Ping to > Keycloak. We noticed that Ping invalidates the refresh token after it is > used once, while Keycloak does not. > > I and my colleague, Kamal are concerned that by not invalidating the > refresh token after first use, we may be opening a security hole. While SSL > may protect the token in transit, we can see a scenario where the refresh > token would be compromised or stolen from the client itself. In this case, > the stolen refresh token could be used to get new access tokens without the > owner of the client machine knowing. > > However, if the behavior was changed so that the refresh token could only > be used once, then either: > 1. If the owner of the client machine would use the refresh token > first, then the stolen refresh token could not be used > 2. If the stolen refresh token would be used first, then the client > machine would not be able to use it and the user of that client machine > could be alerted that something was wrong. This user could then reset their > password or invalidate all of their access and refresh tokens. > > Furthermore, we are concerned about this same scenario, but with the > offline token. My understanding is that the offline token does not expire > and that it can?t be invalidated by logging out the user or changing the > user?s password. Have you thought about this scenario? > > Thank You, > > *Mikhail Kuznetsov* > Software Engineer > Hewlett Packard Enterprise > > > > *From:* Marek Posolda [mailto:mposolda at redhat.com ] > *Sent:* Tuesday, October 06, 2015 1:16 PM > *To:* Raghu Prabhala > *Cc:* Kuznetsov, Mike; keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > Hi Raghu, > > >From the specs, it looks to me that this is not anything mandatory. The > paragraph is starting "For example". Feel free to create JIRA, but I > personally can't promise anything regarding this... > > Marek > > > On 06/10/15 17:37, Raghu Prabhala wrote: > > Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh token > should be invalidated but retained by the server - to handle compromise of > refresh tokens as they are long lived. > > Thanks, > Raghu > > Sent from my iPhone > > On Oct 6, 2015, at 10:53 AM, Marek Posolda wrote: > > You're right, same refresh token can be used more times. However it is > still better to use refresh token R2 in your step 3 instead of using old > refresh token R1 because R2 has updated timestamp (each token is valid just > for 30 minutes or so, depends on the configured SSO session idle timeout). > > Or are you referring that this is security issue and potential possibility > to Man in the middle? If you use HTTPS (which is recommended for production > environment, and especially if you have unsecured/untrusted networkl), this > shouldn't be an issue. > > Marek > > On 06/10/15 16:34, Kuznetsov, Mike wrote: > > Hello, > > I noticed that with Keycloak, it seems that refresh tokens are still valid > after they are used once. This means that Keycloak does *not* invalidate > Refresh Tokens after they have been used once. > > I am able to successfully execute the following flow: > 1. Obtain Access Token (A1) and Refresh Token (R1) > 2. Use Refresh Token (R1) to obtain new Access Token (A2) and > Refresh Token (R2) > 3. Use same Refresh Token (R1) again to obtain new Access Token > (A3) and Refresh Token (R3) > > > Can you please tell me if this is the intended functionality? > > Thank You, > > *Mikhail Kuznetsov* > Software Engineer > Hewlett Packard Enterprise > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/58bd2c17/attachment-0001.html From mposolda at redhat.com Wed Oct 7 08:28:32 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 7 Oct 2015 14:28:32 +0200 Subject: [keycloak-dev] Introduce option to select username mode for a realm In-Reply-To: References: Message-ID: <56150FF0.8080104@redhat.com> On 06/10/15 09:50, Stian Thorgersen wrote: > We've have someone from the community that wants to use mobile number > as the username, as well as verify mobile number by sending a code via > SMS. See "Login by mobile number" thread in user mailing list for more > details. They are also willing to contribute this back to the community. > > That made me think it may be nice to be able to configure the behavior > of the username "field" for a realm. We could have a simple drop-down > in the admin console to configure username mode, with the following > options: > > * Username/email - default behavior where a user provides both a > username and email, and the user can login with either. In this mode > email has to be unique. > * Username - a user can only login with a username. In this mode we > could relax the requirement that email has to be unique (that may be > difficult though as it would require not using a database constraint, > which may make it rather difficult to guarantee uniqueness in other modes) Even if we add the option, I wouldn't remove email uniqueness. Admin can decide to change the mode back to "Username" to "Email" and then some users won't be able to login due to many users with same email. Also is there usecase when there are 2 different users in realm with same email? > * Email - in this mode only email can be used to login. In this mode > username field would not be displayed on the registration form or > account management console. In the token the username would be set to > email. In this mode verify email address should be enabled by default. > * Mobile - user logs in with a mobile number. We can either just add > mobile number to the username field or add a new mobile field and > require uniqueness on that field. In this mode verify mobile number > should be enabled by default. For the "Mobile" support, isn't an option to remove default username/password Authenticator and add new Authenticator based on mobile number? Also registration screen can be customized and account management as well. Also user can already use protocol mapper to map "mobile_number" attribute to "preferred_username" or whatever he wants into access token. TBH advantages of introducing new option are bit unclear to me. It looks like adding another complexity, which is not needed as authentication with mobile can be done with the SPIs we have now IMO. Marek > > With regards to implementation I think it would be easier to make the > existing username/password authenticator, registration form and > account management adopt to the mode rather than have separate > authenticators, etc.. for each mode. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/25ccbef1/attachment.html From mposolda at redhat.com Wed Oct 7 08:35:04 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 7 Oct 2015 14:35:04 +0200 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: References: <66122567ABACCC42B5B568EC7E90551A1A740F93@G1W3780.americas.hpqcorp.net> <710997604.1735164.1444184846487.JavaMail.yahoo@mail.yahoo.com> <56150C3A.90702@redhat.com> Message-ID: <56151178.2020303@redhat.com> On 07/10/15 14:23, Stian Thorgersen wrote: > We should make this configurable. For those worried about security > they can enforce new refresh tokens as well as offline tokens will > replace the old tokens. It would be fairly simply to implement. If > enabled we would only allow refresh token where iat is >= the last > session refresh time. I was also thinking about this possibility. However if you have 2 clients and you refresh the token for client1, the refresh token of client2 won't be valid as his "iat" will be older. Also SSO login currently refreshes lastSessionRefresh on UserSession. However maybe we can introduce lastSessionRefresh to ClientSession as well? Marek > I wouldn't make it default behavior for two reasons: > > * It would break existing clients if they expect to continue using the > old refresh token > * It comes at a performance cost as clients will have to store the new > refresh tokens and offline tokens each time they refresh the token > * For offline tokens Keycloak would also have to persist the last > refresh time each time the offline token is refreshed > > I think we'd need to make it a realm wide configuration option. > > On 7 October 2015 at 14:12, Marek Posolda > wrote: > > The points are valid and security can be always improved, however > sometimes improving security makes things complicated with the > not-so-big advantage... IMO admin should always protect the > machine to make sure that nobody unauthorized has access to > refresh tokens. And for the transport, HTTPS should be always > used. But feel free to create JIRA and we will see... > > When user or client is deleted, all refresh/offline tokens will > defacto become invalid as well and can't be used anymore. You're > right that offline token is still valid after user logout. User > can revoke it manually in account management or admin can revoke > it in admin console. However refresh token is invalid after user > logout. All refresh/offline tokens for particular client can be > revoked by admin by set notBefore policy to now, which can be done > in admin console in "Revocation" tab of particular client. > > Marek > > > On 07/10/15 04:27, Raghuram Prabhala wrote: >> Very valid points Mike and even I have similar concerns. But >> please do understand that even if the refresh token is stolen or >> compromised,it cannot be used by any client unless both the >> client_id and client_secret are also compromised/stolen. But >> nevertheless, it is a good practice to assume the worst and add >> in protective measures to minimize the chances. >> >> Marek/Bill/Stian - Even our organization is very particular that >> such potential security issues be addressed. Can this be taken >> up? BTW I am not sure if you have an API/End point to invalidate >> tokens for those that are either compromised or must be >> invalidated as either the user or client is no longer active. If >> you do not have one then it is a good idea to make one available. >> >> Thanks, >> Raghu >> >> ------------------------------------------------------------------------ >> *From:* "Kuznetsov, Mike" >> >> *To:* "keycloak-dev at lists.jboss.org" >> >> >> *Cc:* "Jagadevan, Kamal" >> >> *Sent:* Tuesday, October 6, 2015 4:34 PM >> *Subject:* Re: [keycloak-dev] Same Refresh token can be used >> multiple times to obtain access token >> >> Hello, >> The reason I brought this up is that we are currently working on >> migrating out authentication from a commercially available >> product called Ping to Keycloak. We noticed that Ping invalidates >> the refresh token after it is used once, while Keycloak does not. >> I and my colleague, Kamal are concerned that by not invalidating >> the refresh token after first use, we may be opening a security >> hole. While SSL may protect the token in transit, we can see a >> scenario where the refresh token would be compromised or stolen >> from the client itself. In this case, the stolen refresh token >> could be used to get new access tokens without the owner of the >> client machine knowing. >> However, if the behavior was changed so that the refresh token >> could only be used once, then either: >> 1.If the owner of the client machine would use the refresh token >> first, then the stolen refresh token could not be used >> 2.If the stolen refresh token would be used first, then the >> client machine would not be able to use it and the user of that >> client machine could be alerted that something was wrong. This >> user could then reset their password or invalidate all of their >> access and refresh tokens. >> Furthermore, we are concerned about this same scenario, but with >> the offline token. My understanding is that the offline token >> does not expire and that it can?t be invalidated by logging out >> the user or changing the user?s password. Have you thought about >> this scenario? >> Thank You, >> >> *Mikhail Kuznetsov* >> Software Engineer >> Hewlett Packard Enterprise >> >> >> *From:*Marek Posolda [mailto:mposolda at redhat.com] >> *Sent:* Tuesday, October 06, 2015 1:16 PM >> *To:* Raghu Prabhala >> *Cc:* Kuznetsov, Mike; keycloak-dev at lists.jboss.org >> >> *Subject:* Re: [keycloak-dev] Same Refresh token can be used >> multiple times to obtain access token >> Hi Raghu, >> >> >From the specs, it looks to me that this is not anything >> mandatory. The paragraph is starting "For example". Feel free to >> create JIRA, but I personally can't promise anything regarding >> this... >> >> Marek >> >> >> On 06/10/15 17:37, Raghu Prabhala wrote: >> >> Hi Marek - section 10.4 of rfc6749 mentions that the prior >> refresh token should be invalidated but retained by the >> server - to handle compromise of refresh tokens as they are >> long lived. >> Thanks, >> Raghu >> >> Sent from my iPhone >> >> On Oct 6, 2015, at 10:53 AM, Marek Posolda >> > wrote: >> >> You're right, same refresh token can be used more times. >> However it is still better to use refresh token R2 in >> your step 3 instead of using old refresh token R1 because >> R2 has updated timestamp (each token is valid just for 30 >> minutes or so, depends on the configured SSO session idle >> timeout). >> >> Or are you referring that this is security issue and >> potential possibility to Man in the middle? If you use >> HTTPS (which is recommended for production environment, >> and especially if you have unsecured/untrusted networkl), >> this shouldn't be an issue. >> >> Marek >> >> On 06/10/15 16:34, Kuznetsov, Mike wrote: >> >> Hello, >> I noticed that with Keycloak, it seems that refresh >> tokens are still valid after they are used once. This >> means that Keycloak does *not* invalidate Refresh >> Tokens after they have been used once. >> I am able to successfully execute the following flow: >> 1.Obtain Access Token (A1) and Refresh Token (R1) >> 2.Use Refresh Token (R1) to obtain new Access Token >> (A2) and Refresh Token (R2) >> 3.Use same Refresh Token (R1) again to obtain new >> Access Token (A3) and Refresh Token (R3) >> Can you please tell me if this is the intended >> functionality? >> Thank You, >> >> *Mikhail Kuznetsov* >> Software Engineer >> Hewlett Packard Enterprise >> >> >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/346a9e99/attachment-0001.html From sthorger at redhat.com Wed Oct 7 08:38:12 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 7 Oct 2015 14:38:12 +0200 Subject: [keycloak-dev] Introduce option to select username mode for a realm In-Reply-To: <56150FF0.8080104@redhat.com> References: <56150FF0.8080104@redhat.com> Message-ID: I agree mobile can be done with a separate authenticator, it's probably not that much additional work to add either. However, that doesn't change the account management console, registration screens, etc.. So there's more work than that + quite a lot of configuration needed to use mobile instead of email/username. It would be nice to have a configurable option on the username/email authenticator to support only email though. I think we may have this already but it's a realm option rather than a configuration option on the authenticator. Same arguments here, if someone just wants to use email, the username shouldn't be displayed on login, registration and account management. On 7 October 2015 at 14:28, Marek Posolda wrote: > On 06/10/15 09:50, Stian Thorgersen wrote: > > We've have someone from the community that wants to use mobile number as > the username, as well as verify mobile number by sending a code via SMS. > See "Login by mobile number" thread in user mailing list for more details. > They are also willing to contribute this back to the community. > > That made me think it may be nice to be able to configure the behavior of > the username "field" for a realm. We could have a simple drop-down in the > admin console to configure username mode, with the following options: > > * Username/email - default behavior where a user provides both a username > and email, and the user can login with either. In this mode email has to be > unique. > * Username - a user can only login with a username. In this mode we could > relax the requirement that email has to be unique (that may be difficult > though as it would require not using a database constraint, which may make > it rather difficult to guarantee uniqueness in other modes) > > Even if we add the option, I wouldn't remove email uniqueness. Admin can > decide to change the mode back to "Username" to "Email" and then some users > won't be able to login due to many users with same email. Also is there > usecase when there are 2 different users in realm with same email? > > * Email - in this mode only email can be used to login. In this mode > username field would not be displayed on the registration form or account > management console. In the token the username would be set to email. In > this mode verify email address should be enabled by default. > * Mobile - user logs in with a mobile number. We can either just add > mobile number to the username field or add a new mobile field and require > uniqueness on that field. In this mode verify mobile number should be > enabled by default. > > For the "Mobile" support, isn't an option to remove default > username/password Authenticator and add new Authenticator based on mobile > number? Also registration screen can be customized and account management > as well. Also user can already use protocol mapper to map "mobile_number" > attribute to "preferred_username" or whatever he wants into access token. > > TBH advantages of introducing new option are bit unclear to me. It looks > like adding another complexity, which is not needed as authentication with > mobile can be done with the SPIs we have now IMO. > > Marek > > > With regards to implementation I think it would be easier to make the > existing username/password authenticator, registration form and account > management adopt to the mode rather than have separate authenticators, > etc.. for each mode. > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/3d5a6390/attachment.html From sthorger at redhat.com Wed Oct 7 08:38:47 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 7 Oct 2015 14:38:47 +0200 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <56151178.2020303@redhat.com> References: <66122567ABACCC42B5B568EC7E90551A1A740F93@G1W3780.americas.hpqcorp.net> <710997604.1735164.1444184846487.JavaMail.yahoo@mail.yahoo.com> <56150C3A.90702@redhat.com> <56151178.2020303@redhat.com> Message-ID: You're right, we'd have to introduce a lastRefresh on ClientSession On 7 October 2015 at 14:35, Marek Posolda wrote: > On 07/10/15 14:23, Stian Thorgersen wrote: > > We should make this configurable. For those worried about security they > can enforce new refresh tokens as well as offline tokens will replace the > old tokens. It would be fairly simply to implement. If enabled we would > only allow refresh token where iat is >= the last session refresh time. > > I was also thinking about this possibility. However if you have 2 clients > and you refresh the token for client1, the refresh token of client2 won't > be valid as his "iat" will be older. Also SSO login currently refreshes > lastSessionRefresh on UserSession. However maybe we can introduce > lastSessionRefresh to ClientSession as well? > > Marek > > I wouldn't make it default behavior for two reasons: > > * It would break existing clients if they expect to continue using the old > refresh token > * It comes at a performance cost as clients will have to store the new > refresh tokens and offline tokens each time they refresh the token > * For offline tokens Keycloak would also have to persist the last refresh > time each time the offline token is refreshed > > I think we'd need to make it a realm wide configuration option. > > On 7 October 2015 at 14:12, Marek Posolda wrote: > >> The points are valid and security can be always improved, however >> sometimes improving security makes things complicated with the not-so-big >> advantage... IMO admin should always protect the machine to make sure that >> nobody unauthorized has access to refresh tokens. And for the transport, >> HTTPS should be always used. But feel free to create JIRA and we will see... >> >> When user or client is deleted, all refresh/offline tokens will defacto >> become invalid as well and can't be used anymore. You're right that offline >> token is still valid after user logout. User can revoke it manually in >> account management or admin can revoke it in admin console. However refresh >> token is invalid after user logout. All refresh/offline tokens for >> particular client can be revoked by admin by set notBefore policy to now, >> which can be done in admin console in "Revocation" tab of particular client. >> >> Marek >> >> >> On 07/10/15 04:27, Raghuram Prabhala wrote: >> >> Very valid points Mike and even I have similar concerns. But please do >> understand that even if the refresh token is stolen or compromised,it >> cannot be used by any client unless both the client_id and client_secret >> are also compromised/stolen. But nevertheless, it is a good practice to >> assume the worst and add in protective measures to minimize the chances. >> >> Marek/Bill/Stian - Even our organization is very particular that such >> potential security issues be addressed. Can this be taken up? BTW I am not >> sure if you have an API/End point to invalidate tokens for those that are >> either compromised or must be invalidated as either the user or client is >> no longer active. If you do not have one then it is a good idea to make one >> available. >> >> Thanks, >> Raghu >> >> ------------------------------ >> *From:* "Kuznetsov, Mike" >> >> *To:* "keycloak-dev at lists.jboss.org" >> >> *Cc:* "Jagadevan, Kamal" >> >> *Sent:* Tuesday, October 6, 2015 4:34 PM >> *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple >> times to obtain access token >> >> Hello, >> >> The reason I brought this up is that we are currently working on >> migrating out authentication from a commercially available product called >> Ping to Keycloak. We noticed that Ping invalidates the refresh token after >> it is used once, while Keycloak does not. >> >> I and my colleague, Kamal are concerned that by not invalidating the >> refresh token after first use, we may be opening a security hole. While SSL >> may protect the token in transit, we can see a scenario where the refresh >> token would be compromised or stolen from the client itself. In this case, >> the stolen refresh token could be used to get new access tokens without the >> owner of the client machine knowing. >> >> However, if the behavior was changed so that the refresh token could only >> be used once, then either: >> 1. If the owner of the client machine would use the refresh token >> first, then the stolen refresh token could not be used >> 2. If the stolen refresh token would be used first, then the >> client machine would not be able to use it and the user of that client >> machine could be alerted that something was wrong. This user could then >> reset their password or invalidate all of their access and refresh tokens. >> >> Furthermore, we are concerned about this same scenario, but with the >> offline token. My understanding is that the offline token does not expire >> and that it can?t be invalidated by logging out the user or changing the >> user?s password. Have you thought about this scenario? >> >> Thank You, >> >> *Mikhail Kuznetsov* >> Software Engineer >> Hewlett Packard Enterprise >> >> >> >> *From:* Marek Posolda [mailto:mposolda at redhat.com ] >> *Sent:* Tuesday, October 06, 2015 1:16 PM >> *To:* Raghu Prabhala >> *Cc:* Kuznetsov, Mike; >> keycloak-dev at lists.jboss.org >> *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple >> times to obtain access token >> >> Hi Raghu, >> >> >From the specs, it looks to me that this is not anything mandatory. The >> paragraph is starting "For example". Feel free to create JIRA, but I >> personally can't promise anything regarding this... >> >> Marek >> >> >> On 06/10/15 17:37, Raghu Prabhala wrote: >> >> Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh token >> should be invalidated but retained by the server - to handle compromise of >> refresh tokens as they are long lived. >> >> Thanks, >> Raghu >> >> Sent from my iPhone >> >> On Oct 6, 2015, at 10:53 AM, Marek Posolda < >> mposolda at redhat.com> wrote: >> >> You're right, same refresh token can be used more times. However it is >> still better to use refresh token R2 in your step 3 instead of using old >> refresh token R1 because R2 has updated timestamp (each token is valid just >> for 30 minutes or so, depends on the configured SSO session idle timeout). >> >> Or are you referring that this is security issue and potential >> possibility to Man in the middle? If you use HTTPS (which is recommended >> for production environment, and especially if you have unsecured/untrusted >> networkl), this shouldn't be an issue. >> >> Marek >> >> On 06/10/15 16:34, Kuznetsov, Mike wrote: >> >> Hello, >> >> I noticed that with Keycloak, it seems that refresh tokens are still >> valid after they are used once. This means that Keycloak does *not* >> invalidate Refresh Tokens after they have been used once. >> >> I am able to successfully execute the following flow: >> 1. Obtain Access Token (A1) and Refresh Token (R1) >> 2. Use Refresh Token (R1) to obtain new Access Token (A2) and >> Refresh Token (R2) >> 3. Use same Refresh Token (R1) again to obtain new Access Token >> (A3) and Refresh Token (R3) >> >> >> Can you please tell me if this is the intended functionality? >> >> Thank You, >> >> *Mikhail Kuznetsov* >> Software Engineer >> Hewlett Packard Enterprise >> >> >> >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/0880d932/attachment-0001.html From csnyder at iland.com Wed Oct 7 08:46:35 2015 From: csnyder at iland.com (Cory Snyder) Date: Wed, 7 Oct 2015 12:46:35 +0000 Subject: [keycloak-dev] Introduce option to select username mode for a realm In-Reply-To: <56150FF0.8080104@redhat.com> References: <56150FF0.8080104@redhat.com> Message-ID: <2428F061-9A3F-407F-B21E-B8E984109408@iland.com> Hey guys, Just a remark on the idea of relaxing the email uniqueness requirement since Marek asked if there was a good use case. In my organization, we are using Active Directory as the federation provider and there is no easy way to enforce email uniqueness natively in AD. For various reasons, we have some users being created directly in AD by another team within our organization and they routinely create users that have the same email address. Our customers apparently want some generic organization accounts with generic organization email addresses. It has actually been one of the biggest pain points for us and our use of Keycloak since we have to manually resolve the issue when it happens. I personally strongly prefer that the emails are unique because it makes things simpler throughout our internal application, but not having the option to relax this requirement has been a bit of a hassle for us with Active Directory and account registrations that occur outside of Keycloak. Cory Snyder software engineer USA +1.419.731.3479 UK +44.20.7096.0149 iland.com On Oct 7, 2015, at 7:28 AM, Marek Posolda > wrote: On 06/10/15 09:50, Stian Thorgersen wrote: We've have someone from the community that wants to use mobile number as the username, as well as verify mobile number by sending a code via SMS. See "Login by mobile number" thread in user mailing list for more details. They are also willing to contribute this back to the community. That made me think it may be nice to be able to configure the behavior of the username "field" for a realm. We could have a simple drop-down in the admin console to configure username mode, with the following options: * Username/email - default behavior where a user provides both a username and email, and the user can login with either. In this mode email has to be unique. * Username - a user can only login with a username. In this mode we could relax the requirement that email has to be unique (that may be difficult though as it would require not using a database constraint, which may make it rather difficult to guarantee uniqueness in other modes) Even if we add the option, I wouldn't remove email uniqueness. Admin can decide to change the mode back to "Username" to "Email" and then some users won't be able to login due to many users with same email. Also is there usecase when there are 2 different users in realm with same email? * Email - in this mode only email can be used to login. In this mode username field would not be displayed on the registration form or account management console. In the token the username would be set to email. In this mode verify email address should be enabled by default. * Mobile - user logs in with a mobile number. We can either just add mobile number to the username field or add a new mobile field and require uniqueness on that field. In this mode verify mobile number should be enabled by default. For the "Mobile" support, isn't an option to remove default username/password Authenticator and add new Authenticator based on mobile number? Also registration screen can be customized and account management as well. Also user can already use protocol mapper to map "mobile_number" attribute to "preferred_username" or whatever he wants into access token. TBH advantages of introducing new option are bit unclear to me. It looks like adding another complexity, which is not needed as authentication with mobile can be done with the SPIs we have now IMO. Marek With regards to implementation I think it would be easier to make the existing username/password authenticator, registration form and account management adopt to the mode rather than have separate authenticators, etc.. for each mode. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/159a4e6e/attachment.html From mposolda at redhat.com Wed Oct 7 08:48:21 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 7 Oct 2015 14:48:21 +0200 Subject: [keycloak-dev] Introduce option to select username mode for a realm In-Reply-To: References: <56150FF0.8080104@redhat.com> Message-ID: <56151495.6020203@redhat.com> On 07/10/15 14:38, Stian Thorgersen wrote: > I agree mobile can be done with a separate authenticator, it's > probably not that much additional work to add either. However, that > doesn't change the account management console, registration screens, > etc.. So there's more work than that + quite a lot of configuration > needed to use mobile instead of email/username. > > It would be nice to have a configurable option on the username/email > authenticator to support only email though. I think we may have this > already but it's a realm option rather than a configuration option on > the authenticator. Same arguments here, if someone just wants to use > email, the username shouldn't be displayed on login, registration and > account management. Hmm... looks that we already have "isRegistrationEmailAsUsername" on RealmModel. This seems to affect just the registration screen, so admin have possibility to use different username and email, however self-registered user has same username and email. Maybe this one can be replaced from "boolean" to enum with more options? Marek > > On 7 October 2015 at 14:28, Marek Posolda > wrote: > > On 06/10/15 09:50, Stian Thorgersen wrote: >> We've have someone from the community that wants to use mobile >> number as the username, as well as verify mobile number by >> sending a code via SMS. See "Login by mobile number" thread in >> user mailing list for more details. They are also willing to >> contribute this back to the community. >> >> That made me think it may be nice to be able to configure the >> behavior of the username "field" for a realm. We could have a >> simple drop-down in the admin console to configure username mode, >> with the following options: >> >> * Username/email - default behavior where a user provides both a >> username and email, and the user can login with either. In this >> mode email has to be unique. >> * Username - a user can only login with a username. In this mode >> we could relax the requirement that email has to be unique (that >> may be difficult though as it would require not using a database >> constraint, which may make it rather difficult to guarantee >> uniqueness in other modes) > Even if we add the option, I wouldn't remove email uniqueness. > Admin can decide to change the mode back to "Username" to "Email" > and then some users won't be able to login due to many users with > same email. Also is there usecase when there are 2 different users > in realm with same email? >> * Email - in this mode only email can be used to login. In this >> mode username field would not be displayed on the registration >> form or account management console. In the token the username >> would be set to email. In this mode verify email address should >> be enabled by default. >> * Mobile - user logs in with a mobile number. We can either just >> add mobile number to the username field or add a new mobile field >> and require uniqueness on that field. In this mode verify mobile >> number should be enabled by default. > For the "Mobile" support, isn't an option to remove default > username/password Authenticator and add new Authenticator based on > mobile number? Also registration screen can be customized and > account management as well. Also user can already use protocol > mapper to map "mobile_number" attribute to "preferred_username" or > whatever he wants into access token. > > TBH advantages of introducing new option are bit unclear to me. It > looks like adding another complexity, which is not needed as > authentication with mobile can be done with the SPIs we have now IMO. > > Marek >> >> With regards to implementation I think it would be easier to make >> the existing username/password authenticator, registration form >> and account management adopt to the mode rather than have >> separate authenticators, etc.. for each mode. >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151007/2f081e39/attachment.html From ssilvert at redhat.com Wed Oct 7 12:42:58 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 07 Oct 2015 12:42:58 -0400 Subject: [keycloak-dev] i18n/l10n: English text in java code Message-ID: <56154B92.1030804@redhat.com> Marko brought this to my attention yesterday. For some things, we dynamically create UI. In this case, the java code contains the English text and it needs to be localized. Luckily, the solution was pretty straightforward. We just replace the English text with a key into the message bundle. The html template that displays this text already pulls from an Angular scope so we just leave that alone and pass it through the |translate filter. You do need to also add the double-colon. One nice side effect is that if the key is not found in the bundle then the output of the translate filter is the unchanged text. This means that any code which has not converted to using bundle keys will still work as expected. And, any third-party providers can just pass in plain text if they don't care about l10n. If they ever do care about l10n we will just need to provide a means for them to add key/value pairs to the resource bundles. Here is an example for anyone who needs to localize English text embedded in java: https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 Stan From sthorger at redhat.com Wed Oct 7 23:53:04 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Oct 2015 05:53:04 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: <56154B92.1030804@redhat.com> References: <56154B92.1030804@redhat.com> Message-ID: With regards to internationalization I have two questions: * Should we fallback to English messages if a key is missing in a translation? Alternative is to show key, but that's not going to help anyone * Should we change message bundles to UTF-8? Or is ISO 8859-1 going to work for all languages? On 7 October 2015 at 18:42, Stan Silvert wrote: > Marko brought this to my attention yesterday. For some things, we > dynamically create UI. In this case, the java code contains the English > text and it needs to be localized. Luckily, the solution was pretty > straightforward. We just replace the English text with a key into the > message bundle. The html template that displays this text already pulls > from an Angular scope so we just leave that alone and pass it through > the |translate filter. You do need to also add the double-colon. > > One nice side effect is that if the key is not found in the bundle then > the output of the translate filter is the unchanged text. This means > that any code which has not converted to using bundle keys will still > work as expected. And, any third-party providers can just pass in > plain text if they don't care about l10n. If they ever do care about > l10n we will just need to provide a means for them to add key/value > pairs to the resource bundles. > > Here is an example for anyone who needs to localize English text > embedded in java: > > https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 > > Stan > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/465c72bc/attachment.html From thomas.raehalme at aitiofinland.com Thu Oct 8 00:48:36 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Thu, 8 Oct 2015 07:48:36 +0300 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> Message-ID: On Oct 8, 2015 6:53 AM, "Stian Thorgersen" wrote: > > With regards to internationalization I have two questions: > > * Should we fallback to English messages if a key is missing in a translation? Alternative is to show key, but that's not going to help anyone A missing key is a bug and showing the message in the default locale may hide the problem. Even though showing the key does not help the end user it helps the developer and identifies the problem. For this reason I think showing the key would be a good idea. > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going to work for all languages? Depends what those all languages are :-) I think UTF-8 is the best choice as it will handle practically any character. But if you're referring to Java resource bundles the encoding for .properties is ISO-8859-1 but there are means to handle any UTF-8 character. Best regards, Thomas > > On 7 October 2015 at 18:42, Stan Silvert wrote: >> >> Marko brought this to my attention yesterday. For some things, we >> dynamically create UI. In this case, the java code contains the English >> text and it needs to be localized. Luckily, the solution was pretty >> straightforward. We just replace the English text with a key into the >> message bundle. The html template that displays this text already pulls >> from an Angular scope so we just leave that alone and pass it through >> the |translate filter. You do need to also add the double-colon. >> >> One nice side effect is that if the key is not found in the bundle then >> the output of the translate filter is the unchanged text. This means >> that any code which has not converted to using bundle keys will still >> work as expected. And, any third-party providers can just pass in >> plain text if they don't care about l10n. If they ever do care about >> l10n we will just need to provide a means for them to add key/value >> pairs to the resource bundles. >> >> Here is an example for anyone who needs to localize English text >> embedded in java: >> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >> >> Stan >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/e19d6fb2/attachment.html From sthorger at redhat.com Thu Oct 8 00:54:48 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Oct 2015 06:54:48 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> Message-ID: We need to support any language ;) Default message bundles are Java properties. For Java developers it may be expected that they are encoded in ISO-8859-1, but for other people they probably expect UTF-8. Java property files are nice as the format is simple (key=value is much nicer and easier to write than { "key" : "value" }). There's also support for translating property files backed into IDEs. On 8 October 2015 at 06:48, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > > On Oct 8, 2015 6:53 AM, "Stian Thorgersen" wrote: > > > > With regards to internationalization I have two questions: > > > > * Should we fallback to English messages if a key is missing in a > translation? Alternative is to show key, but that's not going to help anyone > > A missing key is a bug and showing the message in the default locale may > hide the problem. > > Even though showing the key does not help the end user it helps the > developer and identifies the problem. For this reason I think showing the > key would be a good idea. > > > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going to > work for all languages? > > Depends what those all languages are :-) > > I think UTF-8 is the best choice as it will handle practically any > character. > > But if you're referring to Java resource bundles the encoding for > .properties is ISO-8859-1 but there are means to handle any UTF-8 character. > > Best regards, > Thomas > > > > > On 7 October 2015 at 18:42, Stan Silvert wrote: > >> > >> Marko brought this to my attention yesterday. For some things, we > >> dynamically create UI. In this case, the java code contains the English > >> text and it needs to be localized. Luckily, the solution was pretty > >> straightforward. We just replace the English text with a key into the > >> message bundle. The html template that displays this text already pulls > >> from an Angular scope so we just leave that alone and pass it through > >> the |translate filter. You do need to also add the double-colon. > >> > >> One nice side effect is that if the key is not found in the bundle then > >> the output of the translate filter is the unchanged text. This means > >> that any code which has not converted to using bundle keys will still > >> work as expected. And, any third-party providers can just pass in > >> plain text if they don't care about l10n. If they ever do care about > >> l10n we will just need to provide a means for them to add key/value > >> pairs to the resource bundles. > >> > >> Here is an example for anyone who needs to localize English text > >> embedded in java: > >> > https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 > >> > >> Stan > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/aec2de09/attachment.html From parul.com at gmail.com Thu Oct 8 03:21:10 2015 From: parul.com at gmail.com (Arulkumar Ponnusamy) Date: Thu, 8 Oct 2015 12:51:10 +0530 Subject: [keycloak-dev] Does PicketLink Service provider supports ECP ? Message-ID: Hi All, We are using picket link as service provider. Our Application supports different interfaces for authentication such as web browser, CLI, API. I could not find any document on Picketlink SP supports on ECP client. Can some clarify on this? Thanks, Arulkumar Ponnusamy. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/ae9cd1f2/attachment.html From Carsten.Saathoff at kisters.de Thu Oct 8 04:42:09 2015 From: Carsten.Saathoff at kisters.de (Carsten Saathoff) Date: Thu, 8 Oct 2015 10:42:09 +0200 Subject: [keycloak-dev] Mongo Replica Sets Message-ID: Hi all, we are currently setting up a production system that uses keycloak as the Identity Provider. We use mongodb as the database for keycloak (since this is our main database), but require keycloak to also handle mongodb replica sets appropriately. Currently, when the primary changes in a mongo replica set, keycloak stops working, since it only connects to a single instance. I have a version of keycloak that uses a mongodb:// uri[1] to specify the mongo connection parameters in the keycloak configuration file. Since mongodb:// uris are a standard way of obtaining a mongo client, this naturally supports replica sets. The patch is only a couple of lines and seems to work. The only issue I have is that the MongoDB update seems to be broken in master currently. But this is also the case when I build keycloak without my patch, so I assume this to be an unrelated issue. The commit is available in my keycloak fork: https://github.com/kodemaniak/keycloak/commit/6741dffe38c9c8d9fd8ca1e92cb15762666a607a Only the setup of the operational attributes is still missing for the configuration via uri, but it can easily be added. I would like to get this somehow into an official release, since I think that supporting replica sets is crucial in order to use keycloak with mongo in a production setup. Personally I think that specifying mongo connection parameters via mongodb:// uris is the most convenient way and it's standardized. So it could even be the only way of specifying the connection details IMHO. Since in the contribution section it's encouraged to first discuss such ideas on this mailing list prior to sending a pull request, I am sending this mail to receive any feedback. best Carsten [1] http://docs.mongodb.org/manual/reference/connection-string/ -------------------------------------------------------------------------------------------------------------------------------------------- Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff at kisters.de | WWW: http://www.kisters.de -------------------------------------------------------------------------------------------------------------------------------------------- Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/26ae0e5c/attachment-0001.html From thomas.raehalme at aitiofinland.com Thu Oct 8 05:08:28 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Thu, 8 Oct 2015 12:08:28 +0300 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> Message-ID: On Thu, Oct 8, 2015 at 7:54 AM, Stian Thorgersen wrote: > Default message bundles are Java properties. For Java developers it may be > expected that they are encoded in ISO-8859-1, but for other people they > probably expect UTF-8. Java property files are nice as the format is simple > (key=value is much nicer and easier to write than { "key" : "value" }). > There's also support for translating property files backed into IDEs. > At the moment if you use Java properties with ResourceBundle the file encoding must be ISO-8859-1. I think Java 9 may introduce support for UTF-8 (http://openjdk.java.net/jeps/226). Best regards, Thomas > > On 8 October 2015 at 06:48, Thomas Raehalme < > thomas.raehalme at aitiofinland.com> wrote: > >> >> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" wrote: >> > >> > With regards to internationalization I have two questions: >> > >> > * Should we fallback to English messages if a key is missing in a >> translation? Alternative is to show key, but that's not going to help anyone >> >> A missing key is a bug and showing the message in the default locale may >> hide the problem. >> >> Even though showing the key does not help the end user it helps the >> developer and identifies the problem. For this reason I think showing the >> key would be a good idea. >> >> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going to >> work for all languages? >> >> Depends what those all languages are :-) >> >> I think UTF-8 is the best choice as it will handle practically any >> character. >> >> But if you're referring to Java resource bundles the encoding for >> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >> >> Best regards, >> Thomas >> >> > >> > On 7 October 2015 at 18:42, Stan Silvert wrote: >> >> >> >> Marko brought this to my attention yesterday. For some things, we >> >> dynamically create UI. In this case, the java code contains the >> English >> >> text and it needs to be localized. Luckily, the solution was pretty >> >> straightforward. We just replace the English text with a key into the >> >> message bundle. The html template that displays this text already >> pulls >> >> from an Angular scope so we just leave that alone and pass it through >> >> the |translate filter. You do need to also add the double-colon. >> >> >> >> One nice side effect is that if the key is not found in the bundle then >> >> the output of the translate filter is the unchanged text. This means >> >> that any code which has not converted to using bundle keys will still >> >> work as expected. And, any third-party providers can just pass in >> >> plain text if they don't care about l10n. If they ever do care about >> >> l10n we will just need to provide a means for them to add key/value >> >> pairs to the resource bundles. >> >> >> >> Here is an example for anyone who needs to localize English text >> >> embedded in java: >> >> >> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >> >> >> >> Stan >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- *Thomas Raehalme* *CTO, teknologiajohtaja* Mobile +358 40 545 0605 *Aitio Finland Oy* V?in?nkatu 26 A 40100 JYV?SKYL?, Finland Tel. +358 10 322 0040 www.aitiofinland.com *Codecenter on nyt Aitio ? me kun ei vain koodata!* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/637e846d/attachment.html From sthorger at redhat.com Thu Oct 8 05:59:06 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Oct 2015 11:59:06 +0200 Subject: [keycloak-dev] Does PicketLink Service provider supports ECP ? In-Reply-To: References: Message-ID: This mailing list is for discussing development of Keycloak, not PicketLink SP. Please look at http://picketlink.org/gethelp/ for support on PicketLink On 8 October 2015 at 09:21, Arulkumar Ponnusamy wrote: > Hi All, > We are using picket link as service provider. Our Application supports > different interfaces for authentication such as web browser, CLI, API. > > > I could not find any document on Picketlink SP supports on ECP client. Can > some clarify on this? > Thanks, > Arulkumar Ponnusamy. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/85458909/attachment.html From sthorger at redhat.com Thu Oct 8 05:59:27 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Oct 2015 11:59:27 +0200 Subject: [keycloak-dev] Mongo Replica Sets In-Reply-To: References: Message-ID: Please use user mailing list for support On 8 October 2015 at 10:42, Carsten Saathoff wrote: > Hi all, > > we are currently setting up a production system that uses keycloak as the > Identity Provider. We use mongodb as the database for keycloak (since this > is our main database), but require keycloak to also handle mongodb replica > sets appropriately. Currently, when the primary changes in a mongo replica > set, keycloak stops working, since it only connects to a single instance. > > I have a version of keycloak that uses a mongodb:// uri[1] to specify the > mongo connection parameters in the keycloak configuration file. Since > mongodb:// uris are a standard way of obtaining a mongo client, this > naturally supports replica sets. The patch is only a couple of lines and > seems to work. The only issue I have is that the MongoDB update seems to be > broken in master currently. But this is also the case when I build keycloak > without my patch, so I assume this to be an unrelated issue. > > The commit is available in my keycloak fork: > > > https://github.com/kodemaniak/keycloak/commit/6741dffe38c9c8d9fd8ca1e92cb15762666a607a > > Only the setup of the operational attributes is still missing for the > configuration via uri, but it can easily be added. > > I would like to get this somehow into an official release, since I think > that supporting replica sets is crucial in order to use keycloak with mongo > in a production setup. Personally I think that specifying mongo connection > parameters via mongodb:// uris is the most convenient way and it's > standardized. So it could even be the only way of specifying the connection > details IMHO. > > Since in the contribution section it's encouraged to first discuss such > ideas on this mailing list prior to sending a pull request, I am sending > this mail to receive any feedback. > > best > > Carsten > > [1] http://docs.mongodb.org/manual/reference/connection-string/ > > ------------------------------ > Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany > Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns > Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers > Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: > Carsten.Saathoff at kisters.de | WWW: http://www.kisters.de > ------------------------------ > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser Mail ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/862e29a1/attachment.html From sthorger at redhat.com Thu Oct 8 06:01:59 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Oct 2015 12:01:59 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> Message-ID: Loading the files with utf-8 isn't a problem, that's easily solved for Java 8 as well. On 8 October 2015 at 11:08, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > > > On Thu, Oct 8, 2015 at 7:54 AM, Stian Thorgersen > wrote: > >> Default message bundles are Java properties. For Java developers it may >> be expected that they are encoded in ISO-8859-1, but for other people >> they probably expect UTF-8. Java property files are nice as the format is >> simple (key=value is much nicer and easier to write than { "key" : "value" >> }). There's also support for translating property files backed into IDEs. >> > > At the moment if you use Java properties with ResourceBundle the file > encoding must be ISO-8859-1. I think Java 9 may introduce support for UTF-8 > (http://openjdk.java.net/jeps/226). > > Best regards, > Thomas > > > > > >> >> On 8 October 2015 at 06:48, Thomas Raehalme < >> thomas.raehalme at aitiofinland.com> wrote: >> >>> >>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" wrote: >>> > >>> > With regards to internationalization I have two questions: >>> > >>> > * Should we fallback to English messages if a key is missing in a >>> translation? Alternative is to show key, but that's not going to help anyone >>> >>> A missing key is a bug and showing the message in the default locale may >>> hide the problem. >>> >>> Even though showing the key does not help the end user it helps the >>> developer and identifies the problem. For this reason I think showing the >>> key would be a good idea. >>> >>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going to >>> work for all languages? >>> >>> Depends what those all languages are :-) >>> >>> I think UTF-8 is the best choice as it will handle practically any >>> character. >>> >>> But if you're referring to Java resource bundles the encoding for >>> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >>> >>> Best regards, >>> Thomas >>> >>> > >>> > On 7 October 2015 at 18:42, Stan Silvert wrote: >>> >> >>> >> Marko brought this to my attention yesterday. For some things, we >>> >> dynamically create UI. In this case, the java code contains the >>> English >>> >> text and it needs to be localized. Luckily, the solution was pretty >>> >> straightforward. We just replace the English text with a key into the >>> >> message bundle. The html template that displays this text already >>> pulls >>> >> from an Angular scope so we just leave that alone and pass it through >>> >> the |translate filter. You do need to also add the double-colon. >>> >> >>> >> One nice side effect is that if the key is not found in the bundle >>> then >>> >> the output of the translate filter is the unchanged text. This means >>> >> that any code which has not converted to using bundle keys will still >>> >> work as expected. And, any third-party providers can just pass in >>> >> plain text if they don't care about l10n. If they ever do care about >>> >> l10n we will just need to provide a means for them to add key/value >>> >> pairs to the resource bundles. >>> >> >>> >> Here is an example for anyone who needs to localize English text >>> >> embedded in java: >>> >> >>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>> >> >>> >> Stan >>> >> _______________________________________________ >>> >> keycloak-dev mailing list >>> >> keycloak-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > >>> > >>> > >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > > > -- > *Thomas Raehalme* > *CTO, teknologiajohtaja* > Mobile +358 40 545 0605 > > *Aitio Finland Oy* > V?in?nkatu 26 A > 40100 JYV?SKYL?, Finland > Tel. +358 10 322 0040 > www.aitiofinland.com > > *Codecenter on nyt Aitio ? me kun ei vain koodata!* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/dea66c00/attachment-0001.html From thomas.raehalme at aitiofinland.com Thu Oct 8 06:05:06 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Thu, 8 Oct 2015 13:05:06 +0300 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> Message-ID: For java.util.Properties, yes, but with ResourceBundles you'd need to use PropertyResourceBundle directly to be able to pass java.io.Reader with the correct encoding. Best regards, Thomas On Thu, Oct 8, 2015 at 1:01 PM, Stian Thorgersen wrote: > Loading the files with utf-8 isn't a problem, that's easily solved for > Java 8 as well. > > On 8 October 2015 at 11:08, Thomas Raehalme < > thomas.raehalme at aitiofinland.com> wrote: > >> >> >> On Thu, Oct 8, 2015 at 7:54 AM, Stian Thorgersen >> wrote: >> >>> Default message bundles are Java properties. For Java developers it may >>> be expected that they are encoded in ISO-8859-1, but for other people >>> they probably expect UTF-8. Java property files are nice as the format is >>> simple (key=value is much nicer and easier to write than { "key" : "value" >>> }). There's also support for translating property files backed into IDEs. >>> >> >> At the moment if you use Java properties with ResourceBundle the file >> encoding must be ISO-8859-1. I think Java 9 may introduce support for UTF-8 >> (http://openjdk.java.net/jeps/226). >> >> Best regards, >> Thomas >> >> >> >> >> >>> >>> On 8 October 2015 at 06:48, Thomas Raehalme < >>> thomas.raehalme at aitiofinland.com> wrote: >>> >>>> >>>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" wrote: >>>> > >>>> > With regards to internationalization I have two questions: >>>> > >>>> > * Should we fallback to English messages if a key is missing in a >>>> translation? Alternative is to show key, but that's not going to help anyone >>>> >>>> A missing key is a bug and showing the message in the default locale >>>> may hide the problem. >>>> >>>> Even though showing the key does not help the end user it helps the >>>> developer and identifies the problem. For this reason I think showing the >>>> key would be a good idea. >>>> >>>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going >>>> to work for all languages? >>>> >>>> Depends what those all languages are :-) >>>> >>>> I think UTF-8 is the best choice as it will handle practically any >>>> character. >>>> >>>> But if you're referring to Java resource bundles the encoding for >>>> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >>>> >>>> Best regards, >>>> Thomas >>>> >>>> > >>>> > On 7 October 2015 at 18:42, Stan Silvert wrote: >>>> >> >>>> >> Marko brought this to my attention yesterday. For some things, we >>>> >> dynamically create UI. In this case, the java code contains the >>>> English >>>> >> text and it needs to be localized. Luckily, the solution was pretty >>>> >> straightforward. We just replace the English text with a key into >>>> the >>>> >> message bundle. The html template that displays this text already >>>> pulls >>>> >> from an Angular scope so we just leave that alone and pass it through >>>> >> the |translate filter. You do need to also add the double-colon. >>>> >> >>>> >> One nice side effect is that if the key is not found in the bundle >>>> then >>>> >> the output of the translate filter is the unchanged text. This means >>>> >> that any code which has not converted to using bundle keys will still >>>> >> work as expected. And, any third-party providers can just pass in >>>> >> plain text if they don't care about l10n. If they ever do care about >>>> >> l10n we will just need to provide a means for them to add key/value >>>> >> pairs to the resource bundles. >>>> >> >>>> >> Here is an example for anyone who needs to localize English text >>>> >> embedded in java: >>>> >> >>>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>>> >> >>>> >> Stan >>>> >> _______________________________________________ >>>> >> keycloak-dev mailing list >>>> >> keycloak-dev at lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> >> >> -- >> *Thomas Raehalme* >> *CTO, teknologiajohtaja* >> Mobile +358 40 545 0605 >> >> *Aitio Finland Oy* >> V?in?nkatu 26 A >> 40100 JYV?SKYL?, Finland >> Tel. +358 10 322 0040 >> www.aitiofinland.com >> >> *Codecenter on nyt Aitio ? me kun ei vain koodata!* >> >> > -- *Thomas Raehalme* *CTO, teknologiajohtaja* Mobile +358 40 545 0605 *Aitio Finland Oy* V?in?nkatu 26 A 40100 JYV?SKYL?, Finland Tel. +358 10 322 0040 www.aitiofinland.com *Codecenter on nyt Aitio ? me kun ei vain koodata!* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/f2bd68d0/attachment.html From Carsten.Saathoff at kisters.de Thu Oct 8 06:24:03 2015 From: Carsten.Saathoff at kisters.de (Carsten Saathoff) Date: Thu, 8 Oct 2015 12:24:03 +0200 Subject: [keycloak-dev] Mongo Replica Sets In-Reply-To: References: Message-ID: I am not asking for support, I am proposing a change to the mongodb connection provider to support mongo replica sets. best Carsten -------------------------------------------------------------------------------------------------------------------------------------------- Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff at kisters.de | WWW: http://www.kisters.de -------------------------------------------------------------------------------------------------------------------------------------------- Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From: Stian Thorgersen To: Carsten Saathoff , Cc: keycloak-dev Date: 08/10/2015 12:00 Subject: Re: [keycloak-dev] Mongo Replica Sets Sent by: keycloak-dev-bounces at lists.jboss.org Please use user mailing list for support On 8 October 2015 at 10:42, Carsten Saathoff wrote: Hi all, we are currently setting up a production system that uses keycloak as the Identity Provider. We use mongodb as the database for keycloak (since this is our main database), but require keycloak to also handle mongodb replica sets appropriately. Currently, when the primary changes in a mongo replica set, keycloak stops working, since it only connects to a single instance. I have a version of keycloak that uses a mongodb:// uri[1] to specify the mongo connection parameters in the keycloak configuration file. Since mongodb:// uris are a standard way of obtaining a mongo client, this naturally supports replica sets. The patch is only a couple of lines and seems to work. The only issue I have is that the MongoDB update seems to be broken in master currently. But this is also the case when I build keycloak without my patch, so I assume this to be an unrelated issue. The commit is available in my keycloak fork: https://github.com/kodemaniak/keycloak/commit/6741dffe38c9c8d9fd8ca1e92cb15762666a607a Only the setup of the operational attributes is still missing for the configuration via uri, but it can easily be added. I would like to get this somehow into an official release, since I think that supporting replica sets is crucial in order to use keycloak with mongo in a production setup. Personally I think that specifying mongo connection parameters via mongodb:// uris is the most convenient way and it's standardized. So it could even be the only way of specifying the connection details IMHO. Since in the contribution section it's encouraged to first discuss such ideas on this mailing list prior to sending a pull request, I am sending this mail to receive any feedback. best Carsten [1] http://docs.mongodb.org/manual/reference/connection-string/ Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff at kisters.de | WWW: http://www.kisters.de Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/4f1b5581/attachment-0001.html From ssilvert at redhat.com Thu Oct 8 08:13:46 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 08 Oct 2015 08:13:46 -0400 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> Message-ID: <56165DFA.50707@redhat.com> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: > > > On Oct 8, 2015 6:53 AM, "Stian Thorgersen" > wrote: > > > > With regards to internationalization I have two questions: > > > > * Should we fallback to English messages if a key is missing in a > translation? Alternative is to show key, but that's not going to help > anyone > > A missing key is a bug and showing the message in the default locale > may hide the problem. > > Even though showing the key does not help the end user it helps the > developer and identifies the problem. For this reason I think showing > the key would be a good idea. > For our bundles, we could catch missing keys at build time. Failing that, I agree that displaying the key is better than falling back to English. This is especially true right now while we haven't completed the task of converting everything. If we fall back to English we won't know if the problem is a missing key or if the text just hasn't been converted yet. > > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going > to work for all languages? > > Depends what those all languages are :-) > > I think UTF-8 is the best choice as it will handle practically any > character. > > But if you're referring to Java resource bundles the encoding for > .properties is ISO-8859-1 but there are means to handle any UTF-8 > character. > Yes, an UTF-8 character can be encoded in ISO-8859-1. Java provides a native2ascii tool for converting entire files. The resource bundle tools in most IDE's do this for you automatically. So you just edit as UTF-8 and it saves the bundle as ISO-8859-1. We can read our bundles as UTF-8 if we want to do that. I'd rather not, because I'm not sure what we might run into down the road with Java assuming resource bundles are always ISO-8859-1. But I'd like to get the perspective of people who have handled resource bundles in languages that are not fully supported by ISO-8859-1. Is it too much of a pain to do a conversion or do the tools make the process seamless? > > Best regards, > Thomas > > > > > On 7 October 2015 at 18:42, Stan Silvert > wrote: > >> > >> Marko brought this to my attention yesterday. For some things, we > >> dynamically create UI. In this case, the java code contains the > English > >> text and it needs to be localized. Luckily, the solution was pretty > >> straightforward. We just replace the English text with a key into the > >> message bundle. The html template that displays this text already > pulls > >> from an Angular scope so we just leave that alone and pass it through > >> the |translate filter. You do need to also add the double-colon. > >> > >> One nice side effect is that if the key is not found in the bundle then > >> the output of the translate filter is the unchanged text. This means > >> that any code which has not converted to using bundle keys will still > >> work as expected. And, any third-party providers can just pass in > >> plain text if they don't care about l10n. If they ever do care about > >> l10n we will just need to provide a means for them to add key/value > >> pairs to the resource bundles. > >> > >> Here is an example for anyone who needs to localize English text > >> embedded in java: > >> > https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 > >> > >> Stan > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/455961cc/attachment.html From bburke at redhat.com Thu Oct 8 08:28:42 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 8 Oct 2015 08:28:42 -0400 Subject: [keycloak-dev] Does PicketLink Service provider supports ECP ? In-Reply-To: References: Message-ID: <5616617A.8030604@redhat.com> We are releasing a Keycloak SAML SP soon, but it does not have ECP support. On 10/8/2015 5:59 AM, Stian Thorgersen wrote: > This mailing list is for discussing development of Keycloak, not > PicketLink SP. Please look at http://picketlink.org/gethelp/ for support > on PicketLink > > On 8 October 2015 at 09:21, Arulkumar Ponnusamy > wrote: > > Hi All, > We are using picket link as service provider. Our Application > supports different interfaces for authentication such as web > browser, CLI, API. > > > I could not find any document on Picketlink SP supports on ECP > client. Can some clarify on this? > Thanks, > Arulkumar Ponnusamy. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From parul.com at gmail.com Thu Oct 8 08:40:14 2015 From: parul.com at gmail.com (Arulkumar Ponnusamy) Date: Thu, 8 Oct 2015 18:10:14 +0530 Subject: [keycloak-dev] Does PicketLink Service provider supports ECP ? In-Reply-To: <5616617A.8030604@redhat.com> References: <5616617A.8030604@redhat.com> Message-ID: Thanks a lot Bill for clarifying.. Do we have release date? Hopefully we would have migration document from picketlink sp to keycloak?.. On 08-Oct-2015 5:58 pm, "Bill Burke" wrote: > We are releasing a Keycloak SAML SP soon, but it does not have ECP support. > > On 10/8/2015 5:59 AM, Stian Thorgersen wrote: > > This mailing list is for discussing development of Keycloak, not > > PicketLink SP. Please look at http://picketlink.org/gethelp/ for support > > on PicketLink > > > > On 8 October 2015 at 09:21, Arulkumar Ponnusamy > > wrote: > > > > Hi All, > > We are using picket link as service provider. Our Application > > supports different interfaces for authentication such as web > > browser, CLI, API. > > > > > > I could not find any document on Picketlink SP supports on ECP > > client. Can some clarify on this? > > Thanks, > > Arulkumar Ponnusamy. > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/aca08412/attachment.html From bburke at redhat.com Thu Oct 8 10:54:42 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 8 Oct 2015 10:54:42 -0400 Subject: [keycloak-dev] Does PicketLink Service provider supports ECP ? In-Reply-To: References: <5616617A.8030604@redhat.com> Message-ID: <561683B2.6020402@redhat.com> No migration doc yet. I hope the config switches are straightforward. On 10/8/2015 8:40 AM, Arulkumar Ponnusamy wrote: > Thanks a lot Bill for clarifying.. Do we have release date? Hopefully we > would have migration document from picketlink sp to keycloak?.. > > On 08-Oct-2015 5:58 pm, "Bill Burke" > wrote: > > We are releasing a Keycloak SAML SP soon, but it does not have ECP > support. > > On 10/8/2015 5:59 AM, Stian Thorgersen wrote: > > This mailing list is for discussing development of Keycloak, not > > PicketLink SP. Please look at http://picketlink.org/gethelp/ for > support > > on PicketLink > > > > On 8 October 2015 at 09:21, Arulkumar Ponnusamy > > > >> wrote: > > > > Hi All, > > We are using picket link as service provider. Our Application > > supports different interfaces for authentication such as web > > browser, CLI, API. > > > > > > I could not find any document on Picketlink SP supports on ECP > > client. Can some clarify on this? > > Thanks, > > Arulkumar Ponnusamy. > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sebastian.rose at aoe.com Thu Oct 8 13:14:00 2015 From: sebastian.rose at aoe.com (Sebastian Rose) Date: Thu, 8 Oct 2015 17:14:00 +0000 Subject: [keycloak-dev] Direct link to registration/forgot-credentials Message-ID: <1444324441245.1050@aoe.com> Hi all, i have a requirement to provide an external link for register account and forgot-credentials. I learned from KEYCLOAK-1904 that using .../openid-connect/registrations?client_id=.... instead auf /openid-connect/auth?client_id=... works for the register account part. KEYCLOAK-1904 brought this to the js-adapter and provided it as an example to js-console. While testing that KEYCLOAK-1910 was created due to a problem with the bean-initialization. For having the same with forgot-credentials i added simmilar code to make .../openid-connect/forgot-credentials?client_id=... work. This change is described in KEYCLOAK-1927. My first approach was not considering the Authorization SPI (thanks Stian). Second approach uses the class AuthenticationProcessor which is already used for .../openid-connect/auth to make KEYCLOAK-1910 and KEYCLOAK-1927 work. I am not sure if i understood completely and any hint/help is appreciated. With some manual tests it worked fine (please see https://github.com/keycloak/keycloak/pull/1686) Please let me know what you think: 1) .../openid-connect/forgot-credentials is something you can live with/find it usefull 2) Is using class AuthenticationProcessor the correct approach . Anything there to consider after the call of .authenticate? There is a lot more code in place for the auth-case, which deals with variants. They don't seem to be useful for the two other cases. 3) I would like to add .../openid-connect/forgot-credentials to the js-adapter and js-console as well. Best Regards, Sebastian? From sthorger at redhat.com Thu Oct 8 13:15:59 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Oct 2015 19:15:59 +0200 Subject: [keycloak-dev] Mongo Replica Sets In-Reply-To: References: Message-ID: Sorry, I scanned it to a bit to quick. Your patch looks good, create a PR and we'll merge it. On 8 October 2015 at 12:24, Carsten Saathoff wrote: > I am not asking for support, I am proposing a change to the mongodb > connection provider to support mongo replica sets. > > best > > Carsten > ------------------------------ > Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany > Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns > Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers > Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: > Carsten.Saathoff at kisters.de | WWW: http://www.kisters.de > ------------------------------ > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser Mail ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > > > From: Stian Thorgersen > To: Carsten Saathoff , > Cc: keycloak-dev > Date: 08/10/2015 12:00 > Subject: Re: [keycloak-dev] Mongo Replica Sets > Sent by: keycloak-dev-bounces at lists.jboss.org > ------------------------------ > > > > Please use user mailing list for support > > On 8 October 2015 at 10:42, Carsten Saathoff < > *Carsten.Saathoff at kisters.de* > wrote: > Hi all, > > we are currently setting up a production system that uses keycloak as the > Identity Provider. We use mongodb as the database for keycloak (since this > is our main database), but require keycloak to also handle mongodb replica > sets appropriately. Currently, when the primary changes in a mongo replica > set, keycloak stops working, since it only connects to a single instance. > > I have a version of keycloak that uses a mongodb:// uri[1] to specify the > mongo connection parameters in the keycloak configuration file. Since > mongodb:// uris are a standard way of obtaining a mongo client, this > naturally supports replica sets. The patch is only a couple of lines and > seems to work. The only issue I have is that the MongoDB update seems to be > broken in master currently. But this is also the case when I build keycloak > without my patch, so I assume this to be an unrelated issue. > > The commit is available in my keycloak fork: > > > *https://github.com/kodemaniak/keycloak/commit/6741dffe38c9c8d9fd8ca1e92cb15762666a607a* > > > Only the setup of the operational attributes is still missing for the > configuration via uri, but it can easily be added. > > I would like to get this somehow into an official release, since I think > that supporting replica sets is crucial in order to use keycloak with mongo > in a production setup. Personally I think that specifying mongo connection > parameters via mongodb:// uris is the most convenient way and it's > standardized. So it could even be the only way of specifying the connection > details IMHO. > > Since in the contribution section it's encouraged to first discuss such > ideas on this mailing list prior to sending a pull request, I am sending > this mail to receive any feedback. > > best > > Carsten > > [1] *http://docs.mongodb.org/manual/reference/connection-string/* > > > ------------------------------ > Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany > Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns > Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers > Phone: *+49 441 93602 -257* <%2B49%20441%2093602%20-257> | Fax: *+49 441 > 93602 -222* <%2B49%20441%2093602%20-222> | E-Mail: > *Carsten.Saathoff at kisters.de* | WWW: > *http://www.kisters.de* > ------------------------------ > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser Mail ist nicht gestattet. > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > _______________________________________________ > keycloak-dev mailing list > *keycloak-dev at lists.jboss.org* > *https://lists.jboss.org/mailman/listinfo/keycloak-dev* > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/8907f4d6/attachment.html From sthorger at redhat.com Thu Oct 8 13:25:24 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Oct 2015 19:25:24 +0200 Subject: [keycloak-dev] Direct link to registration/forgot-credentials In-Reply-To: <1444324441245.1050@aoe.com> References: <1444324441245.1050@aoe.com> Message-ID: I'm happy with adding the forgot-credentials link, but not 100% sure about what's the correct approach. Can you prepare a separate PR for just KEYCLOAK-1927 so we can review it? We can add it as an option to the js-console, but I don't want to add forgotCredentials and createForgotCredentialsUrl, nor do I want to add it to the js-console. Basically I don't really want to advocate this approach. On 8 October 2015 at 19:14, Sebastian Rose wrote: > Hi all, > > i have a requirement to provide an external link for register account and > forgot-credentials. > > I learned from KEYCLOAK-1904 that using > .../openid-connect/registrations?client_id=.... instead auf > /openid-connect/auth?client_id=... works for the register account part. > KEYCLOAK-1904 brought this to the js-adapter and provided it as an example > to js-console. While testing that KEYCLOAK-1910 was created due to a > problem with the bean-initialization. > > For having the same with forgot-credentials i added simmilar code to make > .../openid-connect/forgot-credentials?client_id=... work. This change is > described in KEYCLOAK-1927. > > My first approach was not considering the Authorization SPI (thanks > Stian). Second approach uses the class AuthenticationProcessor which is > already used for .../openid-connect/auth to make KEYCLOAK-1910 and > KEYCLOAK-1927 work. I am not sure if i understood completely and any > hint/help is appreciated. With some manual tests it worked fine (please see > https://github.com/keycloak/keycloak/pull/1686) > > Please let me know what you think: > 1) .../openid-connect/forgot-credentials is something you can live > with/find it usefull > 2) Is using class AuthenticationProcessor the correct approach . Anything > there to consider after the call of .authenticate? There is a lot more code > in place for the auth-case, which deals with variants. They don't seem to > be useful for the two other cases. > 3) I would like to add .../openid-connect/forgot-credentials to the > js-adapter and js-console as well. > > Best Regards, > Sebastian? > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/573993fc/attachment.html From sthorger at redhat.com Thu Oct 8 13:28:42 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Oct 2015 19:28:42 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: <56165DFA.50707@redhat.com> References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> Message-ID: I'm not sure I'm buying into the argument that displaying the key is better for developers. Having English suddenly pop-up in a German translation is just as obvious as a key. Besides as Stan points out you catch missing keys by comparing missing keys between English and German. However, if there is a mistake in a translation then a user may quite likely be able to interpret English text, while a user will not be able to interpret a key. So if a key is missing in a translation (which is obviously a "bug") it's better to display English than to display the key. On 8 October 2015 at 14:13, Stan Silvert wrote: > On 10/8/2015 12:48 AM, Thomas Raehalme wrote: > > > On Oct 8, 2015 6:53 AM, "Stian Thorgersen" wrote: > > > > With regards to internationalization I have two questions: > > > > * Should we fallback to English messages if a key is missing in a > translation? Alternative is to show key, but that's not going to help anyone > > A missing key is a bug and showing the message in the default locale may > hide the problem. > > Even though showing the key does not help the end user it helps the > developer and identifies the problem. For this reason I think showing the > key would be a good idea. > > For our bundles, we could catch missing keys at build time. > > Failing that, I agree that displaying the key is better than falling back > to English. This is especially true right now while we haven't completed > the task of converting everything. If we fall back to English we won't > know if the problem is a missing key or if the text just hasn't been > converted yet. > > > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going to > work for all languages? > > Depends what those all languages are :-) > > I think UTF-8 is the best choice as it will handle practically any > character. > > But if you're referring to Java resource bundles the encoding for > .properties is ISO-8859-1 but there are means to handle any UTF-8 character. > > Yes, an UTF-8 character can be encoded in ISO-8859-1. Java provides a > native2ascii tool for converting entire files. The resource bundle tools > in most IDE's do this for you automatically. So you just edit as UTF-8 and > it saves the bundle as ISO-8859-1. > > We can read our bundles as UTF-8 if we want to do that. I'd rather not, > because I'm not sure what we might run into down the road with Java > assuming resource bundles are always ISO-8859-1. > > But I'd like to get the perspective of people who have handled resource > bundles in languages that are not fully supported by ISO-8859-1. Is it too > much of a pain to do a conversion or do the tools make the process seamless? > > Best regards, > Thomas > > > > > On 7 October 2015 at 18:42, Stan Silvert wrote: > >> > >> Marko brought this to my attention yesterday. For some things, we > >> dynamically create UI. In this case, the java code contains the English > >> text and it needs to be localized. Luckily, the solution was pretty > >> straightforward. We just replace the English text with a key into the > >> message bundle. The html template that displays this text already pulls > >> from an Angular scope so we just leave that alone and pass it through > >> the |translate filter. You do need to also add the double-colon. > >> > >> One nice side effect is that if the key is not found in the bundle then > >> the output of the translate filter is the unchanged text. This means > >> that any code which has not converted to using bundle keys will still > >> work as expected. And, any third-party providers can just pass in > >> plain text if they don't care about l10n. If they ever do care about > >> l10n we will just need to provide a means for them to add key/value > >> pairs to the resource bundles. > >> > >> Here is an example for anyone who needs to localize English text > >> embedded in java: > >> > https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 > >> > >> Stan > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/85c5993d/attachment-0001.html From sthorger at redhat.com Thu Oct 8 14:19:30 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 8 Oct 2015 20:19:30 +0200 Subject: [keycloak-dev] Added 'keycloak.jsonPrettyPrint' system property Message-ID: I fixed an issue where lists of json representations included null values (basically the configuration was just included for packages that started 'org.keycloak' which java.util.List isn't). At the same time I added a system property 'keycloak.jsonPrettyPrint' if enabled Keycloak will return pretty printed json which is nice for development/debug. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/cb7efead/attachment.html From ssilvert at redhat.com Thu Oct 8 14:33:08 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 08 Oct 2015 14:33:08 -0400 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> Message-ID: <5616B6E4.3060906@redhat.com> What if English is the bundle that has a missing key? Let's just put this to rest and solve it once and for all. The simplest solution I can think of is to just compare keys when a new bundle is loaded. If any bundle has a missing key or it has key not found in the previous loaded bundle, we throw a RuntimeException. I can submit a patch for that in just a few minutes. On 10/8/2015 1:28 PM, Stian Thorgersen wrote: > I'm not sure I'm buying into the argument that displaying the key is > better for developers. Having English suddenly pop-up in a German > translation is just as obvious as a key. Besides as Stan points out > you catch missing keys by comparing missing keys between English and > German. > > However, if there is a mistake in a translation then a user may quite > likely be able to interpret English text, while a user will not be > able to interpret a key. So if a key is missing in a translation > (which is obviously a "bug") it's better to display English than to > display the key. > > On 8 October 2015 at 14:13, Stan Silvert > wrote: > > On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >> >> >> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" > > wrote: >> > >> > With regards to internationalization I have two questions: >> > >> > * Should we fallback to English messages if a key is missing in >> a translation? Alternative is to show key, but that's not going >> to help anyone >> >> A missing key is a bug and showing the message in the default >> locale may hide the problem. >> >> Even though showing the key does not help the end user it helps >> the developer and identifies the problem. For this reason I think >> showing the key would be a good idea. >> > For our bundles, we could catch missing keys at build time. > > Failing that, I agree that displaying the key is better than > falling back to English. This is especially true right now while > we haven't completed the task of converting everything. If we > fall back to English we won't know if the problem is a missing key > or if the text just hasn't been converted yet. > >> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going to work for all languages? >> >> Depends what those all languages are :-) >> >> I think UTF-8 is the best choice as it will handle practically >> any character. >> >> But if you're referring to Java resource bundles the encoding for >> .properties is ISO-8859-1 but there are means to handle any UTF-8 >> character. >> > Yes, an UTF-8 character can be encoded in ISO-8859-1. Java > provides a native2ascii tool for converting entire files. The > resource bundle tools in most IDE's do this for you > automatically. So you just edit as UTF-8 and it saves the bundle > as ISO-8859-1. > > We can read our bundles as UTF-8 if we want to do that. I'd rather > not, because I'm not sure what we might run into down the road > with Java assuming resource bundles are always ISO-8859-1. > > But I'd like to get the perspective of people who have handled > resource bundles in languages that are not fully supported by > ISO-8859-1. Is it too much of a pain to do a conversion or do the > tools make the process seamless? > >> Best regards, >> Thomas >> >> > >> > On 7 October 2015 at 18:42, Stan Silvert > > wrote: >> >> >> >> Marko brought this to my attention yesterday. For some things, we >> >> dynamically create UI. In this case, the java code contains >> the English >> >> text and it needs to be localized. Luckily, the solution was >> pretty >> >> straightforward. We just replace the English text with a key >> into the >> >> message bundle. The html template that displays this text >> already pulls >> >> from an Angular scope so we just leave that alone and pass it >> through >> >> the |translate filter. You do need to also add the double-colon. >> >> >> >> One nice side effect is that if the key is not found in the >> bundle then >> >> the output of the translate filter is the unchanged text. >> This means >> >> that any code which has not converted to using bundle keys >> will still >> >> work as expected. And, any third-party providers can just >> pass in >> >> plain text if they don't care about l10n. If they ever do >> care about >> >> l10n we will just need to provide a means for them to add >> key/value >> >> pairs to the resource bundles. >> >> >> >> Here is an example for anyone who needs to localize English text >> >> embedded in java: >> >> >> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >> >> >> >> Stan >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/d94d66cd/attachment.html From sebastian.rose at aoe.com Thu Oct 8 14:47:46 2015 From: sebastian.rose at aoe.com (Sebastian Rose) Date: Thu, 8 Oct 2015 18:47:46 +0000 Subject: [keycloak-dev] Direct link to registration/forgot-credentials In-Reply-To: References: <1444324441245.1050@aoe.com> Message-ID: <273e68ccaca340e5ba88c8f393d4dbd0@exchange02.srv.hq.aoe.lan> Here is the PR for just KEYCLOAK-1927: https://github.com/keycloak/keycloak/pull/1689 Von: Stian Thorgersen [mailto:sthorger at redhat.com] Gesendet: Donnerstag, 8. Oktober 2015 19:25 An: Sebastian Rose Cc: keycloak-dev at lists.jboss.org Betreff: Re: [keycloak-dev] Direct link to registration/forgot-credentials I'm happy with adding the forgot-credentials link, but not 100% sure about what's the correct approach. Can you prepare a separate PR for just KEYCLOAK-1927 so we can review it? We can add it as an option to the js-console, but I don't want to add forgotCredentials and createForgotCredentialsUrl, nor do I want to add it to the js-console. Basically I don't really want to advocate this approach. On 8 October 2015 at 19:14, Sebastian Rose > wrote: Hi all, i have a requirement to provide an external link for register account and forgot-credentials. I learned from KEYCLOAK-1904 that using .../openid-connect/registrations?client_id=.... instead auf /openid-connect/auth?client_id=... works for the register account part. KEYCLOAK-1904 brought this to the js-adapter and provided it as an example to js-console. While testing that KEYCLOAK-1910 was created due to a problem with the bean-initialization. For having the same with forgot-credentials i added simmilar code to make .../openid-connect/forgot-credentials?client_id=... work. This change is described in KEYCLOAK-1927. My first approach was not considering the Authorization SPI (thanks Stian). Second approach uses the class AuthenticationProcessor which is already used for .../openid-connect/auth to make KEYCLOAK-1910 and KEYCLOAK-1927 work. I am not sure if i understood completely and any hint/help is appreciated. With some manual tests it worked fine (please see https://github.com/keycloak/keycloak/pull/1686) Please let me know what you think: 1) .../openid-connect/forgot-credentials is something you can live with/find it usefull 2) Is using class AuthenticationProcessor the correct approach . Anything there to consider after the call of .authenticate? There is a lot more code in place for the auth-case, which deals with variants. They don't seem to be useful for the two other cases. 3) I would like to add .../openid-connect/forgot-credentials to the js-adapter and js-console as well. Best Regards, Sebastian? _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151008/99483dd1/attachment-0001.html From mposolda at redhat.com Fri Oct 9 00:08:55 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 9 Oct 2015 06:08:55 +0200 Subject: [keycloak-dev] Mongo Replica Sets In-Reply-To: References: Message-ID: <56173DD7.5050205@redhat.com> Just one minor thing, it looks to me that when you introduce "uri" in the configuration, the operationalInfo won't be filled. This operationInfo is used for admins for debugging server status and can be shown for example from admin console. Could you improve PR to ensure it is filled? Thanks, Marek On 08/10/15 19:15, Stian Thorgersen wrote: > Sorry, I scanned it to a bit to quick. > > Your patch looks good, create a PR and we'll merge it. > > On 8 October 2015 at 12:24, Carsten Saathoff > > wrote: > > I am not asking for support, I am proposing a change to the > mongodb connection provider to support mongo replica sets. > > best > > Carsten > ------------------------------------------------------------------------ > Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany > Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, > Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers > Phone: +49 441 93602 -257 | Fax: > +49 441 93602 -222 | E-Mail: > Carsten.Saathoff at kisters.de | > WWW: http://www.kisters.de > ------------------------------------------------------------------------ > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder > diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte > sofort den Absender und vernichten Sie diese Mail. Das unerlaubte > Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht > gestattet. > This e-mail may contain confidential and/or privileged > information. If you are not the intended recipient (or have > received this e-mail in error) please notify the sender > immediately and destroy this e-mail. Any unauthorised copying, > disclosure or distribution of the material in this e-mail is > strictly forbidden. > > > > From: Stian Thorgersen > > To: Carsten Saathoff >, > Cc: keycloak-dev > > Date: 08/10/2015 12:00 > Subject: Re: [keycloak-dev] Mongo Replica Sets > Sent by: keycloak-dev-bounces at lists.jboss.org > > ------------------------------------------------------------------------ > > > > Please use user mailing list for support > > On 8 October 2015 at 10:42, Carsten Saathoff > <_Carsten.Saathoff at kisters.de_ > > wrote: > Hi all, > > we are currently setting up a production system that uses keycloak > as the Identity Provider. We use mongodb as the database for > keycloak (since this is our main database), but require keycloak > to also handle mongodb replica sets appropriately. Currently, when > the primary changes in a mongo replica set, keycloak stops > working, since it only connects to a single instance. > > I have a version of keycloak that uses a mongodb:// uri[1] to > specify the mongo connection parameters in the keycloak > configuration file. Since mongodb:// uris are a standard way of > obtaining a mongo client, this naturally supports replica sets. > The patch is only a couple of lines and seems to work. The only > issue I have is that the MongoDB update seems to be broken in > master currently. But this is also the case when I build keycloak > without my patch, so I assume this to be an unrelated issue. > > The commit is available in my keycloak fork: > _ > __https://github.com/kodemaniak/keycloak/commit/6741dffe38c9c8d9fd8ca1e92cb15762666a607a_ > > Only the setup of the operational attributes is still missing for > the configuration via uri, but it can easily be added. > > I would like to get this somehow into an official release, since I > think that supporting replica sets is crucial in order to use > keycloak with mongo in a production setup. Personally I think that > specifying mongo connection parameters via mongodb:// uris is the > most convenient way and it's standardized. So it could even be the > only way of specifying the connection details IMHO. > > Since in the contribution section it's encouraged to first discuss > such ideas on this mailing list prior to sending a pull request, I > am sending this mail to receive any feedback. > > best > > Carsten > > [1] _http://docs.mongodb.org/manual/reference/connection-string/_ > > ------------------------------------------------------------------------ > Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany > Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, > Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers > Phone: _+49 441 93602 -257_ | Fax: > _+49 441 93602 -222_ | E-Mail: > _Carsten.Saathoff at kisters.de_ > | WWW: _http://www.kisters.de_ > > ------------------------------------------------------------------------ > Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte > Informationen. Wenn Sie nicht der richtige Adressat sind oder > diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte > sofort den Absender und vernichten Sie diese Mail. Das unerlaubte > Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht > gestattet. > This e-mail may contain confidential and/or privileged > information. If you are not the intended recipient (or have > received this e-mail in error) please notify the sender > immediately and destroy this e-mail. Any unauthorised copying, > disclosure or distribution of the material in this e-mail is > strictly forbidden. > _______________________________________________ > keycloak-dev mailing list_ > __keycloak-dev at lists.jboss.org_ _ > __https://lists.jboss.org/mailman/listinfo/keycloak-dev_ > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/9bd50c6e/attachment.html From sthorger at redhat.com Fri Oct 9 01:10:09 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Oct 2015 07:10:09 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: <5616B6E4.3060906@redhat.com> References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> Message-ID: That's not putting it to rest at all! Throwing a RuntimeException and rendering the whole admin console useless just because there's a missing key is a horrible idea. On 8 October 2015 at 20:33, Stan Silvert wrote: > What if English is the bundle that has a missing key? > > Let's just put this to rest and solve it once and for all. The simplest > solution I can think of is to just compare keys when a new bundle is > loaded. If any bundle has a missing key or it has key not found in the > previous loaded bundle, we throw a RuntimeException. I can submit a patch > for that in just a few minutes. > > > On 10/8/2015 1:28 PM, Stian Thorgersen wrote: > > I'm not sure I'm buying into the argument that displaying the key is > better for developers. Having English suddenly pop-up in a German > translation is just as obvious as a key. Besides as Stan points out you > catch missing keys by comparing missing keys between English and German. > > However, if there is a mistake in a translation then a user may quite > likely be able to interpret English text, while a user will not be able to > interpret a key. So if a key is missing in a translation (which is > obviously a "bug") it's better to display English than to display the key. > > On 8 October 2015 at 14:13, Stan Silvert wrote: > >> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >> >> >> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" wrote: >> > >> > With regards to internationalization I have two questions: >> > >> > * Should we fallback to English messages if a key is missing in a >> translation? Alternative is to show key, but that's not going to help anyone >> >> A missing key is a bug and showing the message in the default locale may >> hide the problem. >> >> Even though showing the key does not help the end user it helps the >> developer and identifies the problem. For this reason I think showing the >> key would be a good idea. >> >> For our bundles, we could catch missing keys at build time. >> >> Failing that, I agree that displaying the key is better than falling back >> to English. This is especially true right now while we haven't completed >> the task of converting everything. If we fall back to English we won't >> know if the problem is a missing key or if the text just hasn't been >> converted yet. >> >> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going to >> work for all languages? >> >> Depends what those all languages are :-) >> >> I think UTF-8 is the best choice as it will handle practically any >> character. >> >> But if you're referring to Java resource bundles the encoding for >> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >> >> Yes, an UTF-8 character can be encoded in ISO-8859-1. Java provides a >> native2ascii tool for converting entire files. The resource bundle tools >> in most IDE's do this for you automatically. So you just edit as UTF-8 and >> it saves the bundle as ISO-8859-1. >> >> We can read our bundles as UTF-8 if we want to do that. I'd rather not, >> because I'm not sure what we might run into down the road with Java >> assuming resource bundles are always ISO-8859-1. >> >> But I'd like to get the perspective of people who have handled resource >> bundles in languages that are not fully supported by ISO-8859-1. Is it too >> much of a pain to do a conversion or do the tools make the process >> seamless? >> >> Best regards, >> Thomas >> >> > >> > On 7 October 2015 at 18:42, Stan Silvert wrote: >> >> >> >> Marko brought this to my attention yesterday. For some things, we >> >> dynamically create UI. In this case, the java code contains the >> English >> >> text and it needs to be localized. Luckily, the solution was pretty >> >> straightforward. We just replace the English text with a key into the >> >> message bundle. The html template that displays this text already >> pulls >> >> from an Angular scope so we just leave that alone and pass it through >> >> the |translate filter. You do need to also add the double-colon. >> >> >> >> One nice side effect is that if the key is not found in the bundle then >> >> the output of the translate filter is the unchanged text. This means >> >> that any code which has not converted to using bundle keys will still >> >> work as expected. And, any third-party providers can just pass in >> >> plain text if they don't care about l10n. If they ever do care about >> >> l10n we will just need to provide a means for them to add key/value >> >> pairs to the resource bundles. >> >> >> >> Here is an example for anyone who needs to localize English text >> >> embedded in java: >> >> >> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >> >> >> >> Stan >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >> > >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/8b8acad6/attachment-0001.html From sthorger at redhat.com Fri Oct 9 01:11:04 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Oct 2015 07:11:04 +0200 Subject: [keycloak-dev] Direct link to registration/forgot-credentials In-Reply-To: <273e68ccaca340e5ba88c8f393d4dbd0@exchange02.srv.hq.aoe.lan> References: <1444324441245.1050@aoe.com> <273e68ccaca340e5ba88c8f393d4dbd0@exchange02.srv.hq.aoe.lan> Message-ID: Merged - as I said in the PR could you do the same for registration? It looks like the correct approach to me. Would be great if you could also add tests? On 8 October 2015 at 20:47, Sebastian Rose wrote: > Here is the PR for just KEYCLOAK-1927: > https://github.com/keycloak/keycloak/pull/1689 > > > > > > *Von:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Gesendet:* Donnerstag, 8. Oktober 2015 19:25 > *An:* Sebastian Rose > *Cc:* keycloak-dev at lists.jboss.org > *Betreff:* Re: [keycloak-dev] Direct link to > registration/forgot-credentials > > > > I'm happy with adding the forgot-credentials link, but not 100% sure > about what's the correct approach. Can you prepare a separate PR for > just KEYCLOAK-1927 so we can review it? > > > > We can add it as an option to the js-console, but I don't want to add > forgotCredentials and createForgotCredentialsUrl, nor do I want to add it > to the js-console. Basically I don't really want to advocate this approach. > > > > > > > > On 8 October 2015 at 19:14, Sebastian Rose wrote: > > Hi all, > > i have a requirement to provide an external link for register account and > forgot-credentials. > > I learned from KEYCLOAK-1904 that using > .../openid-connect/registrations?client_id=.... instead auf > /openid-connect/auth?client_id=... works for the register account part. > KEYCLOAK-1904 brought this to the js-adapter and provided it as an example > to js-console. While testing that KEYCLOAK-1910 was created due to a > problem with the bean-initialization. > > For having the same with forgot-credentials i added simmilar code to make > .../openid-connect/forgot-credentials?client_id=... work. This change is > described in KEYCLOAK-1927. > > My first approach was not considering the Authorization SPI (thanks > Stian). Second approach uses the class AuthenticationProcessor which is > already used for .../openid-connect/auth to make KEYCLOAK-1910 and > KEYCLOAK-1927 work. I am not sure if i understood completely and any > hint/help is appreciated. With some manual tests it worked fine (please see > https://github.com/keycloak/keycloak/pull/1686) > > Please let me know what you think: > 1) .../openid-connect/forgot-credentials is something you can live > with/find it usefull > 2) Is using class AuthenticationProcessor the correct approach . Anything > there to consider after the call of .authenticate? There is a lot more code > in place for the auth-case, which deals with variants. They don't seem to > be useful for the two other cases. > 3) I would like to add .../openid-connect/forgot-credentials to the > js-adapter and js-console as well. > > Best Regards, > Sebastian? > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/a51b07a4/attachment.html From gerbermichi at me.com Fri Oct 9 01:16:40 2015 From: gerbermichi at me.com (Michael Gerber) Date: Fri, 09 Oct 2015 07:16:40 +0200 Subject: [keycloak-dev] id_token_hint Message-ID: Hi, Do you have any plans to include the id_token_hint in the near future? id_token_hint OPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value. If the ID Token received by the RP from the OP is encrypted, to use it as an id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the id_token_hint value. Best Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/7d423f79/attachment.html From sthorger at redhat.com Fri Oct 9 01:41:32 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Oct 2015 07:41:32 +0200 Subject: [keycloak-dev] id_token_hint In-Reply-To: References: Message-ID: It wasn't on our road map, but it looks easy to add On 9 October 2015 at 07:16, Michael Gerber wrote: > Hi, > Do you have any plans to include the id_token_hint in the near future? > id_token_hintOPTIONAL. ID Token previously issued by the Authorization > Server being passed as a hint about the End-User's current or past > authenticated session with the Client. If the End-User identified by the ID > Token is logged in or is logged in by the request, then the Authorization > Server returns a positive response; otherwise, it SHOULD return an error, > such as login_required. When possible, an id_token_hint SHOULD be present > when prompt=none is used and an invalid_request error MAY be returned if > it is not; however, the server SHOULD respond successfully when possible, > even if it is not present. The Authorization Server need not be listed as > an audience of the ID Token when it is used as an id_token_hint value.If > the ID Token received by the RP from the OP is encrypted, to use it as an > id_token_hint, the Client MUST decrypt the signed ID Token contained > within the encrypted ID Token. The Client MAY re-encrypt the signed ID > token to the Authentication Server using a key that enables the server to > decrypt the ID Token, and use the re-encrypted ID token as the > id_token_hint value. > Best > Michael > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/a361f682/attachment.html From gerbermichi at me.com Fri Oct 9 01:46:35 2015 From: gerbermichi at me.com (Michael Gerber) Date: Fri, 09 Oct 2015 05:46:35 +0000 (GMT) Subject: [keycloak-dev] id_token_hint Message-ID: As far as I understand it, we just have to create a new authenticator, check for the?id_token_hint, if it is valid than we set the authenticated user, otherwise we send attempted. I can create a PR for that if it is that simple ;) Am 09. Oktober 2015 um 07:41 schrieb Stian Thorgersen : It wasn't on our road map, but it looks easy to add On 9 October 2015 at 07:16, Michael Gerber wrote: Hi, Do you have any plans to include the id_token_hint in the near future? id_token_hintOPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as?login_required. When possible, an?id_token_hint?SHOULD be present when?prompt=none?is used and an?invalid_request?error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an?id_token_hint?value.If the ID Token received by the RP from the OP is encrypted, to use it as an?id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the?id_token_hint?value. Best Michael _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/d630e0f8/attachment-0001.html From thomas.raehalme at aitiofinland.com Fri Oct 9 01:51:34 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Fri, 9 Oct 2015 08:51:34 +0300 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> Message-ID: How about returning something noticeable like ???key??? for example? On Oct 9, 2015 8:10 AM, "Stian Thorgersen" wrote: > That's not putting it to rest at all! Throwing a RuntimeException and > rendering the whole admin console useless just because there's a missing > key is a horrible idea. > > On 8 October 2015 at 20:33, Stan Silvert wrote: > >> What if English is the bundle that has a missing key? >> >> Let's just put this to rest and solve it once and for all. The simplest >> solution I can think of is to just compare keys when a new bundle is >> loaded. If any bundle has a missing key or it has key not found in the >> previous loaded bundle, we throw a RuntimeException. I can submit a patch >> for that in just a few minutes. >> >> >> On 10/8/2015 1:28 PM, Stian Thorgersen wrote: >> >> I'm not sure I'm buying into the argument that displaying the key is >> better for developers. Having English suddenly pop-up in a German >> translation is just as obvious as a key. Besides as Stan points out you >> catch missing keys by comparing missing keys between English and German. >> >> However, if there is a mistake in a translation then a user may quite >> likely be able to interpret English text, while a user will not be able to >> interpret a key. So if a key is missing in a translation (which is >> obviously a "bug") it's better to display English than to display the key. >> >> On 8 October 2015 at 14:13, Stan Silvert wrote: >> >>> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >>> >>> >>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" wrote: >>> > >>> > With regards to internationalization I have two questions: >>> > >>> > * Should we fallback to English messages if a key is missing in a >>> translation? Alternative is to show key, but that's not going to help anyone >>> >>> A missing key is a bug and showing the message in the default locale may >>> hide the problem. >>> >>> Even though showing the key does not help the end user it helps the >>> developer and identifies the problem. For this reason I think showing the >>> key would be a good idea. >>> >>> For our bundles, we could catch missing keys at build time. >>> >>> Failing that, I agree that displaying the key is better than falling >>> back to English. This is especially true right now while we haven't >>> completed the task of converting everything. If we fall back to English we >>> won't know if the problem is a missing key or if the text just hasn't been >>> converted yet. >>> >>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going to >>> work for all languages? >>> >>> Depends what those all languages are :-) >>> >>> I think UTF-8 is the best choice as it will handle practically any >>> character. >>> >>> But if you're referring to Java resource bundles the encoding for >>> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >>> >>> Yes, an UTF-8 character can be encoded in ISO-8859-1. Java provides a >>> native2ascii tool for converting entire files. The resource bundle tools >>> in most IDE's do this for you automatically. So you just edit as UTF-8 and >>> it saves the bundle as ISO-8859-1. >>> >>> We can read our bundles as UTF-8 if we want to do that. I'd rather not, >>> because I'm not sure what we might run into down the road with Java >>> assuming resource bundles are always ISO-8859-1. >>> >>> But I'd like to get the perspective of people who have handled resource >>> bundles in languages that are not fully supported by ISO-8859-1. Is it too >>> much of a pain to do a conversion or do the tools make the process >>> seamless? >>> >>> Best regards, >>> Thomas >>> >>> > >>> > On 7 October 2015 at 18:42, Stan Silvert wrote: >>> >> >>> >> Marko brought this to my attention yesterday. For some things, we >>> >> dynamically create UI. In this case, the java code contains the >>> English >>> >> text and it needs to be localized. Luckily, the solution was pretty >>> >> straightforward. We just replace the English text with a key into the >>> >> message bundle. The html template that displays this text already >>> pulls >>> >> from an Angular scope so we just leave that alone and pass it through >>> >> the |translate filter. You do need to also add the double-colon. >>> >> >>> >> One nice side effect is that if the key is not found in the bundle >>> then >>> >> the output of the translate filter is the unchanged text. This means >>> >> that any code which has not converted to using bundle keys will still >>> >> work as expected. And, any third-party providers can just pass in >>> >> plain text if they don't care about l10n. If they ever do care about >>> >> l10n we will just need to provide a means for them to add key/value >>> >> pairs to the resource bundles. >>> >> >>> >> Here is an example for anyone who needs to localize English text >>> >> embedded in java: >>> >> >>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>> >> >>> >> Stan >>> >> _______________________________________________ >>> >> keycloak-dev mailing list >>> >> keycloak-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > >>> > >>> > >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/c8706648/attachment.html From sthorger at redhat.com Fri Oct 9 02:09:22 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Oct 2015 08:09:22 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> Message-ID: There's two places where keys can be missing: * In a translation - this can be an honest mistake, or the translation wasn't updated when KC was updated * Custom keys added - for example when keys are used for display names of clients, roles, etc.. Manually having to go through all sorts of pages to look for missing keys is very error prone and time consuming, so will not be the best option for developers. In both cases above the correct way to do this would be to have a way to verify a message bundle. We need a tool that can quickly identify if there are missing keys and we could expose that through the admin console. We currently have a student looking at providing a UI for defining locales and she is also going to look at adding some way of identifying if a locale is missing keys and also to easily list only missing keys. For end users as I've said they will have no clue what ???key??? is, and even worse if we throw an exception/error just because a missing key we'll actually break the whole console just because of a missing key. It's a much better option to look for the key in another translation and display that. Chances are they will be able to interpret one or two English words. Certainly higher chance of that then them being able to interpret ???key???. On 9 October 2015 at 07:51, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > How about returning something noticeable like ???key??? for example? > On Oct 9, 2015 8:10 AM, "Stian Thorgersen" wrote: > >> That's not putting it to rest at all! Throwing a RuntimeException and >> rendering the whole admin console useless just because there's a missing >> key is a horrible idea. >> >> On 8 October 2015 at 20:33, Stan Silvert wrote: >> >>> What if English is the bundle that has a missing key? >>> >>> Let's just put this to rest and solve it once and for all. The simplest >>> solution I can think of is to just compare keys when a new bundle is >>> loaded. If any bundle has a missing key or it has key not found in the >>> previous loaded bundle, we throw a RuntimeException. I can submit a patch >>> for that in just a few minutes. >>> >>> >>> On 10/8/2015 1:28 PM, Stian Thorgersen wrote: >>> >>> I'm not sure I'm buying into the argument that displaying the key is >>> better for developers. Having English suddenly pop-up in a German >>> translation is just as obvious as a key. Besides as Stan points out you >>> catch missing keys by comparing missing keys between English and German. >>> >>> However, if there is a mistake in a translation then a user may quite >>> likely be able to interpret English text, while a user will not be able to >>> interpret a key. So if a key is missing in a translation (which is >>> obviously a "bug") it's better to display English than to display the key. >>> >>> On 8 October 2015 at 14:13, Stan Silvert wrote: >>> >>>> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >>>> >>>> >>>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" wrote: >>>> > >>>> > With regards to internationalization I have two questions: >>>> > >>>> > * Should we fallback to English messages if a key is missing in a >>>> translation? Alternative is to show key, but that's not going to help anyone >>>> >>>> A missing key is a bug and showing the message in the default locale >>>> may hide the problem. >>>> >>>> Even though showing the key does not help the end user it helps the >>>> developer and identifies the problem. For this reason I think showing the >>>> key would be a good idea. >>>> >>>> For our bundles, we could catch missing keys at build time. >>>> >>>> Failing that, I agree that displaying the key is better than falling >>>> back to English. This is especially true right now while we haven't >>>> completed the task of converting everything. If we fall back to English we >>>> won't know if the problem is a missing key or if the text just hasn't been >>>> converted yet. >>>> >>>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going >>>> to work for all languages? >>>> >>>> Depends what those all languages are :-) >>>> >>>> I think UTF-8 is the best choice as it will handle practically any >>>> character. >>>> >>>> But if you're referring to Java resource bundles the encoding for >>>> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >>>> >>>> Yes, an UTF-8 character can be encoded in ISO-8859-1. Java provides a >>>> native2ascii tool for converting entire files. The resource bundle tools >>>> in most IDE's do this for you automatically. So you just edit as UTF-8 and >>>> it saves the bundle as ISO-8859-1. >>>> >>>> We can read our bundles as UTF-8 if we want to do that. I'd rather >>>> not, because I'm not sure what we might run into down the road with Java >>>> assuming resource bundles are always ISO-8859-1. >>>> >>>> But I'd like to get the perspective of people who have handled resource >>>> bundles in languages that are not fully supported by ISO-8859-1. Is it too >>>> much of a pain to do a conversion or do the tools make the process >>>> seamless? >>>> >>>> Best regards, >>>> Thomas >>>> >>>> > >>>> > On 7 October 2015 at 18:42, Stan Silvert wrote: >>>> >> >>>> >> Marko brought this to my attention yesterday. For some things, we >>>> >> dynamically create UI. In this case, the java code contains the >>>> English >>>> >> text and it needs to be localized. Luckily, the solution was pretty >>>> >> straightforward. We just replace the English text with a key into >>>> the >>>> >> message bundle. The html template that displays this text already >>>> pulls >>>> >> from an Angular scope so we just leave that alone and pass it through >>>> >> the |translate filter. You do need to also add the double-colon. >>>> >> >>>> >> One nice side effect is that if the key is not found in the bundle >>>> then >>>> >> the output of the translate filter is the unchanged text. This means >>>> >> that any code which has not converted to using bundle keys will still >>>> >> work as expected. And, any third-party providers can just pass in >>>> >> plain text if they don't care about l10n. If they ever do care about >>>> >> l10n we will just need to provide a means for them to add key/value >>>> >> pairs to the resource bundles. >>>> >> >>>> >> Here is an example for anyone who needs to localize English text >>>> >> embedded in java: >>>> >> >>>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>>> >> >>>> >> Stan >>>> >> _______________________________________________ >>>> >> keycloak-dev mailing list >>>> >> keycloak-dev at lists.jboss.org >>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/fbea4e37/attachment-0001.html From thomas.raehalme at aitiofinland.com Fri Oct 9 02:18:11 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Fri, 9 Oct 2015 09:18:11 +0300 Subject: [keycloak-dev] Adding descriptive names for realms and roles Message-ID: Hi! The name of a realm or a role is also its identifier. I would like to be able to use a bit more descriptive names, but at the same time I don't want them to be used in URLs or when testing for a presence of a role. What do you think would it be possible for realms and roles to have both id and a name? Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/584eff71/attachment.html From Carsten.Saathoff at kisters.de Fri Oct 9 02:28:04 2015 From: Carsten.Saathoff at kisters.de (Carsten Saathoff) Date: Fri, 9 Oct 2015 08:28:04 +0200 Subject: [keycloak-dev] Mongo Replica Sets In-Reply-To: <56173DD7.5050205@redhat.com> References: <56173DD7.5050205@redhat.com> Message-ID: Yes, you are right. I will update that. best Carsten -------------------------------------------------------------------------------------------------------------------------------------------- Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff at kisters.de | WWW: http://www.kisters.de -------------------------------------------------------------------------------------------------------------------------------------------- Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From: Marek Posolda To: stian at redhat.com, Carsten Saathoff , Cc: keycloak-dev Date: 09/10/2015 06:10 Subject: Re: [keycloak-dev] Mongo Replica Sets Sent by: keycloak-dev-bounces at lists.jboss.org Just one minor thing, it looks to me that when you introduce "uri" in the configuration, the operationalInfo won't be filled. This operationInfo is used for admins for debugging server status and can be shown for example from admin console. Could you improve PR to ensure it is filled? Thanks, Marek On 08/10/15 19:15, Stian Thorgersen wrote: Sorry, I scanned it to a bit to quick. Your patch looks good, create a PR and we'll merge it. On 8 October 2015 at 12:24, Carsten Saathoff wrote: I am not asking for support, I am proposing a change to the mongodb connection provider to support mongo replica sets. best Carsten Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff at kisters.de | WWW: http://www.kisters.de Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From: Stian Thorgersen To: Carsten Saathoff , Cc: keycloak-dev Date: 08/10/2015 12:00 Subject: Re: [keycloak-dev] Mongo Replica Sets Sent by: keycloak-dev-bounces at lists.jboss.org Please use user mailing list for support On 8 October 2015 at 10:42, Carsten Saathoff wrote: Hi all, we are currently setting up a production system that uses keycloak as the Identity Provider. We use mongodb as the database for keycloak (since this is our main database), but require keycloak to also handle mongodb replica sets appropriately. Currently, when the primary changes in a mongo replica set, keycloak stops working, since it only connects to a single instance. I have a version of keycloak that uses a mongodb:// uri[1] to specify the mongo connection parameters in the keycloak configuration file. Since mongodb:// uris are a standard way of obtaining a mongo client, this naturally supports replica sets. The patch is only a couple of lines and seems to work. The only issue I have is that the MongoDB update seems to be broken in master currently. But this is also the case when I build keycloak without my patch, so I assume this to be an unrelated issue. The commit is available in my keycloak fork: https://github.com/kodemaniak/keycloak/commit/6741dffe38c9c8d9fd8ca1e92cb15762666a607a Only the setup of the operational attributes is still missing for the configuration via uri, but it can easily be added. I would like to get this somehow into an official release, since I think that supporting replica sets is crucial in order to use keycloak with mongo in a production setup. Personally I think that specifying mongo connection parameters via mongodb:// uris is the most convenient way and it's standardized. So it could even be the only way of specifying the connection details IMHO. Since in the contribution section it's encouraged to first discuss such ideas on this mailing list prior to sending a pull request, I am sending this mail to receive any feedback. best Carsten [1] http://docs.mongodb.org/manual/reference/connection-string/ Carsten Saathoff - KISTERS AG - Stau 75 - 26122 Oldenburg - Germany Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers Phone: +49 441 93602 -257 | Fax: +49 441 93602 -222 | E-Mail: Carsten.Saathoff at kisters.de | WWW: http://www.kisters.de Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/e6bf453b/attachment-0001.html From sthorger at redhat.com Fri Oct 9 02:46:42 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Oct 2015 08:46:42 +0200 Subject: [keycloak-dev] Adding descriptive names for realms and roles In-Reply-To: References: Message-ID: Just added https://issues.jboss.org/browse/KEYCLOAK-1934, we already have description for roles which is used on the grant page, but maybe we should add display name as well On 9 October 2015 at 08:18, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > Hi! > > The name of a realm or a role is also its identifier. I would like to be > able to use a bit more descriptive names, but at the same time I don't want > them to be used in URLs or when testing for a presence of a role. > > What do you think would it be possible for realms and roles to have both > id and a name? > > Best regards, > Thomas > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/d488984c/attachment.html From thomas.raehalme at aitiofinland.com Fri Oct 9 02:52:49 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Fri, 9 Oct 2015 09:52:49 +0300 Subject: [keycloak-dev] Adding descriptive names for realms and roles In-Reply-To: References: Message-ID: Thanks! Should I create a separate issue for the role display name? On Fri, Oct 9, 2015 at 9:46 AM, Stian Thorgersen wrote: > Just added https://issues.jboss.org/browse/KEYCLOAK-1934, we already have > description for roles which is used on the grant page, but maybe we should > add display name as well > > On 9 October 2015 at 08:18, Thomas Raehalme < > thomas.raehalme at aitiofinland.com> wrote: > >> Hi! >> >> The name of a realm or a role is also its identifier. I would like to be >> able to use a bit more descriptive names, but at the same time I don't want >> them to be used in URLs or when testing for a presence of a role. >> >> What do you think would it be possible for realms and roles to have both >> id and a name? >> >> Best regards, >> Thomas >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- *Thomas Raehalme* *CTO, teknologiajohtaja* Mobile +358 40 545 0605 *Aitio Finland Oy* V?in?nkatu 26 A 40100 JYV?SKYL?, Finland Tel. +358 10 322 0040 www.aitiofinland.com *Codecenter on nyt Aitio ? me kun ei vain koodata!* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/14d7c60c/attachment.html From sthorger at redhat.com Fri Oct 9 02:55:14 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Oct 2015 08:55:14 +0200 Subject: [keycloak-dev] Adding descriptive names for realms and roles In-Reply-To: References: Message-ID: Sure On 9 October 2015 at 08:52, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > Thanks! Should I create a separate issue for the role display name? > > On Fri, Oct 9, 2015 at 9:46 AM, Stian Thorgersen > wrote: > >> Just added https://issues.jboss.org/browse/KEYCLOAK-1934, we already >> have description for roles which is used on the grant page, but maybe we >> should add display name as well >> >> On 9 October 2015 at 08:18, Thomas Raehalme < >> thomas.raehalme at aitiofinland.com> wrote: >> >>> Hi! >>> >>> The name of a realm or a role is also its identifier. I would like to be >>> able to use a bit more descriptive names, but at the same time I don't want >>> them to be used in URLs or when testing for a presence of a role. >>> >>> What do you think would it be possible for realms and roles to have both >>> id and a name? >>> >>> Best regards, >>> Thomas >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > > > -- > *Thomas Raehalme* > *CTO, teknologiajohtaja* > Mobile +358 40 545 0605 > > *Aitio Finland Oy* > V?in?nkatu 26 A > 40100 JYV?SKYL?, Finland > Tel. +358 10 322 0040 > www.aitiofinland.com > > *Codecenter on nyt Aitio ? me kun ei vain koodata!* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/6a87ad61/attachment.html From thomas.raehalme at aitiofinland.com Fri Oct 9 03:19:16 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Fri, 9 Oct 2015 10:19:16 +0300 Subject: [keycloak-dev] Adding descriptive names for realms and roles In-Reply-To: References: Message-ID: Added https://issues.jboss.org/browse/KEYCLOAK-1936 for the role display name. On Fri, Oct 9, 2015 at 9:55 AM, Stian Thorgersen wrote: > Sure > > On 9 October 2015 at 08:52, Thomas Raehalme < > thomas.raehalme at aitiofinland.com> wrote: > >> Thanks! Should I create a separate issue for the role display name? >> >> On Fri, Oct 9, 2015 at 9:46 AM, Stian Thorgersen >> wrote: >> >>> Just added https://issues.jboss.org/browse/KEYCLOAK-1934, we already >>> have description for roles which is used on the grant page, but maybe we >>> should add display name as well >>> >>> On 9 October 2015 at 08:18, Thomas Raehalme < >>> thomas.raehalme at aitiofinland.com> wrote: >>> >>>> Hi! >>>> >>>> The name of a realm or a role is also its identifier. I would like to >>>> be able to use a bit more descriptive names, but at the same time I don't >>>> want them to be used in URLs or when testing for a presence of a role. >>>> >>>> What do you think would it be possible for realms and roles to have >>>> both id and a name? >>>> >>>> Best regards, >>>> Thomas >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> >> >> -- >> *Thomas Raehalme* >> *CTO, teknologiajohtaja* >> Mobile +358 40 545 0605 >> >> *Aitio Finland Oy* >> V?in?nkatu 26 A >> 40100 JYV?SKYL?, Finland >> Tel. +358 10 322 0040 >> www.aitiofinland.com >> >> *Codecenter on nyt Aitio ? me kun ei vain koodata!* >> >> > -- *Thomas Raehalme* *CTO, teknologiajohtaja* Mobile +358 40 545 0605 *Aitio Finland Oy* V?in?nkatu 26 A 40100 JYV?SKYL?, Finland Tel. +358 10 322 0040 www.aitiofinland.com *Codecenter on nyt Aitio ? me kun ei vain koodata!* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/6c0f7a96/attachment-0001.html From velias at redhat.com Fri Oct 9 05:39:20 2015 From: velias at redhat.com (Vlastimil Elias) Date: Fri, 9 Oct 2015 11:39:20 +0200 Subject: [keycloak-dev] Support for SSO bridge with shared user base Message-ID: <56178B48.2030603@redhat.com> Hi, I'd like to implement SSO bridge between Keycloak used for our website, and other SAML 2 based SSO server used by another website. Both SSO servers share common user base (user federation provider in keycloak against same user store as the SAML SSO server). What I want to achieve is that once user is logged in on other SAML SSO server and then comes to Keycloak site I'd like to login him there automatically. What I can do is to configure SAML Identity Provider in Keycloak and enable "Authenticate By Default" for it. But I think this will always lead to user creation conflict in Keycloak as we share user base. I have to somehow force this "SAML Identity Provider" in keycloak to directly use existing Keycloak users instead of creating new one and linking to them. Is this somehow achievable in Keycloak 1.5, eg. by development of some extension? From what I know I think it s not achievable and feature must be coded into keycloak core. And one other question ;-) When "Authenticate By Default" is used for some Identity Provider then I believe that Keycloak redirects user's browser to this provider in passive mode before showing own login page to get identity from it if any. But what happen if the provider is unreachable? In this case user finishes with erro page and is not able to login into Keycloak at all. Is Keycloak able to detect provider failure and stop redirecting user there? Thanks in advance Vlastimil -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From mstrukel at redhat.com Fri Oct 9 06:21:38 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 9 Oct 2015 12:21:38 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> Message-ID: And we can always log the missing key situation into server log - that should be enough for developers to notice it, and fix it. On Fri, Oct 9, 2015 at 8:09 AM, Stian Thorgersen wrote: > There's two places where keys can be missing: > > * In a translation - this can be an honest mistake, or the translation > wasn't updated when KC was updated > * Custom keys added - for example when keys are used for display names of > clients, roles, etc.. > > Manually having to go through all sorts of pages to look for missing keys > is very error prone and time consuming, so will not be the best option for > developers. In both cases above the correct way to do this would be to have > a way to verify a message bundle. We need a tool that can quickly identify > if there are missing keys and we could expose that through the admin > console. We currently have a student looking at providing a UI for defining > locales and she is also going to look at adding some way of identifying if > a locale is missing keys and also to easily list only missing keys. > > For end users as I've said they will have no clue what ???key??? is, and > even worse if we throw an exception/error just because a missing key we'll > actually break the whole console just because of a missing key. It's a much > better option to look for the key in another translation and display that. > Chances are they will be able to interpret one or two English words. > Certainly higher chance of that then them being able to interpret ???key???. > > > On 9 October 2015 at 07:51, Thomas Raehalme < > thomas.raehalme at aitiofinland.com> wrote: > >> How about returning something noticeable like ???key??? for example? >> On Oct 9, 2015 8:10 AM, "Stian Thorgersen" wrote: >> >>> That's not putting it to rest at all! Throwing a RuntimeException and >>> rendering the whole admin console useless just because there's a missing >>> key is a horrible idea. >>> >>> On 8 October 2015 at 20:33, Stan Silvert wrote: >>> >>>> What if English is the bundle that has a missing key? >>>> >>>> Let's just put this to rest and solve it once and for all. The >>>> simplest solution I can think of is to just compare keys when a new bundle >>>> is loaded. If any bundle has a missing key or it has key not found in the >>>> previous loaded bundle, we throw a RuntimeException. I can submit a patch >>>> for that in just a few minutes. >>>> >>>> >>>> On 10/8/2015 1:28 PM, Stian Thorgersen wrote: >>>> >>>> I'm not sure I'm buying into the argument that displaying the key is >>>> better for developers. Having English suddenly pop-up in a German >>>> translation is just as obvious as a key. Besides as Stan points out you >>>> catch missing keys by comparing missing keys between English and German. >>>> >>>> However, if there is a mistake in a translation then a user may quite >>>> likely be able to interpret English text, while a user will not be able to >>>> interpret a key. So if a key is missing in a translation (which is >>>> obviously a "bug") it's better to display English than to display the key. >>>> >>>> On 8 October 2015 at 14:13, Stan Silvert wrote: >>>> >>>>> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >>>>> >>>>> >>>>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" >>>>> wrote: >>>>> > >>>>> > With regards to internationalization I have two questions: >>>>> > >>>>> > * Should we fallback to English messages if a key is missing in a >>>>> translation? Alternative is to show key, but that's not going to help anyone >>>>> >>>>> A missing key is a bug and showing the message in the default locale >>>>> may hide the problem. >>>>> >>>>> Even though showing the key does not help the end user it helps the >>>>> developer and identifies the problem. For this reason I think showing the >>>>> key would be a good idea. >>>>> >>>>> For our bundles, we could catch missing keys at build time. >>>>> >>>>> Failing that, I agree that displaying the key is better than falling >>>>> back to English. This is especially true right now while we haven't >>>>> completed the task of converting everything. If we fall back to English we >>>>> won't know if the problem is a missing key or if the text just hasn't been >>>>> converted yet. >>>>> >>>>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going >>>>> to work for all languages? >>>>> >>>>> Depends what those all languages are :-) >>>>> >>>>> I think UTF-8 is the best choice as it will handle practically any >>>>> character. >>>>> >>>>> But if you're referring to Java resource bundles the encoding for >>>>> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >>>>> >>>>> Yes, an UTF-8 character can be encoded in ISO-8859-1. Java provides a >>>>> native2ascii tool for converting entire files. The resource bundle tools >>>>> in most IDE's do this for you automatically. So you just edit as UTF-8 and >>>>> it saves the bundle as ISO-8859-1. >>>>> >>>>> We can read our bundles as UTF-8 if we want to do that. I'd rather >>>>> not, because I'm not sure what we might run into down the road with Java >>>>> assuming resource bundles are always ISO-8859-1. >>>>> >>>>> But I'd like to get the perspective of people who have handled >>>>> resource bundles in languages that are not fully supported by ISO-8859-1. >>>>> Is it too much of a pain to do a conversion or do the tools make the >>>>> process seamless? >>>>> >>>>> Best regards, >>>>> Thomas >>>>> >>>>> > >>>>> > On 7 October 2015 at 18:42, Stan Silvert >>>>> wrote: >>>>> >> >>>>> >> Marko brought this to my attention yesterday. For some things, we >>>>> >> dynamically create UI. In this case, the java code contains the >>>>> English >>>>> >> text and it needs to be localized. Luckily, the solution was pretty >>>>> >> straightforward. We just replace the English text with a key into >>>>> the >>>>> >> message bundle. The html template that displays this text already >>>>> pulls >>>>> >> from an Angular scope so we just leave that alone and pass it >>>>> through >>>>> >> the |translate filter. You do need to also add the double-colon. >>>>> >> >>>>> >> One nice side effect is that if the key is not found in the bundle >>>>> then >>>>> >> the output of the translate filter is the unchanged text. This >>>>> means >>>>> >> that any code which has not converted to using bundle keys will >>>>> still >>>>> >> work as expected. And, any third-party providers can just pass in >>>>> >> plain text if they don't care about l10n. If they ever do care >>>>> about >>>>> >> l10n we will just need to provide a means for them to add key/value >>>>> >> pairs to the resource bundles. >>>>> >> >>>>> >> Here is an example for anyone who needs to localize English text >>>>> >> embedded in java: >>>>> >> >>>>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>>>> >> >>>>> >> Stan >>>>> >> _______________________________________________ >>>>> >> keycloak-dev mailing list >>>>> >> keycloak-dev at lists.jboss.org >>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > keycloak-dev mailing list >>>>> > keycloak-dev at lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >>>>> >>>> >>>> >>> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/2230b5e1/attachment.html From ssilvert at redhat.com Fri Oct 9 07:06:07 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 09 Oct 2015 07:06:07 -0400 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> Message-ID: <56179F9F.1020402@redhat.com> On 10/9/2015 1:10 AM, Stian Thorgersen wrote: > That's not putting it to rest at all! Throwing a RuntimeException and > rendering the whole admin console useless just because there's a > missing key is a horrible idea. This is exactly what needs to happen. A missing key is a bug. We don't want such a bug to get past development. I could improve it by catching the problem at build time, but that's a little more difficult to implement and it's only a slight improvement. Besides, it doesn't render the console useless. It only renders the bundle useless, which it the state you are in anyway. We don't want a bundle to "sort of" work if there is a bug in it. We might never get to the bad page and never notice it until production. When the RuntimeException occurs from a bad bundle, you can switch back to your original language and everything works fine. > > On 8 October 2015 at 20:33, Stan Silvert > wrote: > > What if English is the bundle that has a missing key? > > Let's just put this to rest and solve it once and for all. The > simplest solution I can think of is to just compare keys when a > new bundle is loaded. If any bundle has a missing key or it has > key not found in the previous loaded bundle, we throw a > RuntimeException. I can submit a patch for that in just a few > minutes. > > > On 10/8/2015 1:28 PM, Stian Thorgersen wrote: >> I'm not sure I'm buying into the argument that displaying the key >> is better for developers. Having English suddenly pop-up in a >> German translation is just as obvious as a key. Besides as Stan >> points out you catch missing keys by comparing missing keys >> between English and German. >> >> However, if there is a mistake in a translation then a user may >> quite likely be able to interpret English text, while a user will >> not be able to interpret a key. So if a key is missing in a >> translation (which is obviously a "bug") it's better to display >> English than to display the key. >> >> On 8 October 2015 at 14:13, Stan Silvert > > wrote: >> >> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >>> >>> >>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" >>> > wrote: >>> > >>> > With regards to internationalization I have two questions: >>> > >>> > * Should we fallback to English messages if a key is >>> missing in a translation? Alternative is to show key, but >>> that's not going to help anyone >>> >>> A missing key is a bug and showing the message in the >>> default locale may hide the problem. >>> >>> Even though showing the key does not help the end user it >>> helps the developer and identifies the problem. For this >>> reason I think showing the key would be a good idea. >>> >> For our bundles, we could catch missing keys at build time. >> >> Failing that, I agree that displaying the key is better than >> falling back to English. This is especially true right now >> while we haven't completed the task of converting >> everything. If we fall back to English we won't know if the >> problem is a missing key or if the text just hasn't been >> converted yet. >> >>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going to work >>> for all languages? >>> >>> Depends what those all languages are :-) >>> >>> I think UTF-8 is the best choice as it will handle >>> practically any character. >>> >>> But if you're referring to Java resource bundles the >>> encoding for .properties is ISO-8859-1 but there are means >>> to handle any UTF-8 character. >>> >> Yes, an UTF-8 character can be encoded in ISO-8859-1. Java >> provides a native2ascii tool for converting entire files. >> The resource bundle tools in most IDE's do this for you >> automatically. So you just edit as UTF-8 and it saves the >> bundle as ISO-8859-1. >> >> We can read our bundles as UTF-8 if we want to do that. I'd >> rather not, because I'm not sure what we might run into down >> the road with Java assuming resource bundles are always >> ISO-8859-1. >> >> But I'd like to get the perspective of people who have >> handled resource bundles in languages that are not fully >> supported by ISO-8859-1. Is it too much of a pain to do a >> conversion or do the tools make the process seamless? >> >>> Best regards, >>> Thomas >>> >>> > >>> > On 7 October 2015 at 18:42, Stan Silvert >>> > wrote: >>> >> >>> >> Marko brought this to my attention yesterday. For some >>> things, we >>> >> dynamically create UI. In this case, the java code >>> contains the English >>> >> text and it needs to be localized. Luckily, the solution >>> was pretty >>> >> straightforward. We just replace the English text with a >>> key into the >>> >> message bundle. The html template that displays this >>> text already pulls >>> >> from an Angular scope so we just leave that alone and >>> pass it through >>> >> the |translate filter. You do need to also add the >>> double-colon. >>> >> >>> >> One nice side effect is that if the key is not found in >>> the bundle then >>> >> the output of the translate filter is the unchanged >>> text. This means >>> >> that any code which has not converted to using bundle >>> keys will still >>> >> work as expected. And, any third-party providers can >>> just pass in >>> >> plain text if they don't care about l10n. If they ever >>> do care about >>> >> l10n we will just need to provide a means for them to add >>> key/value >>> >> pairs to the resource bundles. >>> >> >>> >> Here is an example for anyone who needs to localize >>> English text >>> >> embedded in java: >>> >> >>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>> >> >>> >> Stan >>> >> _______________________________________________ >>> >> keycloak-dev mailing list >>> >> keycloak-dev at lists.jboss.org >>> >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > >>> > >>> > >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/0ee8e6aa/attachment-0001.html From ssilvert at redhat.com Fri Oct 9 07:24:11 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 09 Oct 2015 07:24:11 -0400 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> Message-ID: <5617A3DB.80200@redhat.com> On 10/9/2015 6:21 AM, Marko Strukelj wrote: > And we can always log the missing key situation into server log - that > should be enough for developers to notice it, and fix it. This is basically what happens with the code I wrote for the fix: https://github.com/keycloak/keycloak/pull/1690 You get an error in the console and then a stack trace on the server. The stack trace tells you exactly which key is missing. But the console doesn't crash or anything like that. You just switch back to your original language and everything works fine. > > On Fri, Oct 9, 2015 at 8:09 AM, Stian Thorgersen > wrote: > > There's two places where keys can be missing: > > * In a translation - this can be an honest mistake, or the > translation wasn't updated when KC was updated > * Custom keys added - for example when keys are used for display > names of clients, roles, etc.. > > Manually having to go through all sorts of pages to look for > missing keys is very error prone and time consuming, so will not > be the best option for developers. In both cases above the correct > way to do this would be to have a way to verify a message > bundle. We need a tool that can quickly identify if there are > missing keys and we could expose that through the admin console. > We currently have a student looking at providing a UI for defining > locales and she is also going to look at adding some way of > identifying if a locale is missing keys and also to easily list > only missing keys. > > For end users as I've said they will have no clue what ???key??? > is, and even worse if we throw an exception/error just because a > missing key we'll actually break the whole console just because of > a missing key. It's a much better option to look for the key in > another translation and display that. Chances are they will be > able to interpret one or two English words. Certainly higher > chance of that then them being able to interpret ???key???. > > > On 9 October 2015 at 07:51, Thomas Raehalme > > wrote: > > How about returning something noticeable like ???key??? for > example? > > On Oct 9, 2015 8:10 AM, "Stian Thorgersen" > > wrote: > > That's not putting it to rest at all! Throwing a > RuntimeException and rendering the whole admin console > useless just because there's a missing key is a horrible idea. > > On 8 October 2015 at 20:33, Stan Silvert > > wrote: > > What if English is the bundle that has a missing key? > > Let's just put this to rest and solve it once and for > all. The simplest solution I can think of is to just > compare keys when a new bundle is loaded. If any > bundle has a missing key or it has key not found in > the previous loaded bundle, we throw a > RuntimeException. I can submit a patch for that in > just a few minutes. > > > On 10/8/2015 1:28 PM, Stian Thorgersen wrote: >> I'm not sure I'm buying into the argument that >> displaying the key is better for developers. Having >> English suddenly pop-up in a German translation is >> just as obvious as a key. Besides as Stan points out >> you catch missing keys by comparing missing keys >> between English and German. >> >> However, if there is a mistake in a translation then >> a user may quite likely be able to interpret English >> text, while a user will not be able to interpret a >> key. So if a key is missing in a translation (which >> is obviously a "bug") it's better to display English >> than to display the key. >> >> On 8 October 2015 at 14:13, Stan Silvert >> > wrote: >> >> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >>> >>> >>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" >>> >> > wrote: >>> > >>> > With regards to internationalization I have >>> two questions: >>> > >>> > * Should we fallback to English messages if a >>> key is missing in a translation? Alternative is >>> to show key, but that's not going to help anyone >>> >>> A missing key is a bug and showing the message >>> in the default locale may hide the problem. >>> >>> Even though showing the key does not help the >>> end user it helps the developer and identifies >>> the problem. For this reason I think showing the >>> key would be a good idea. >>> >> For our bundles, we could catch missing keys at >> build time. >> >> Failing that, I agree that displaying the key is >> better than falling back to English. This is >> especially true right now while we haven't >> completed the task of converting everything. If >> we fall back to English we won't know if the >> problem is a missing key or if the text just >> hasn't been converted yet. >> >>> > * Should we change message bundles to UTF-8? Or >>> is ISO 8859-1 going to work for all languages? >>> >>> Depends what those all languages are :-) >>> >>> I think UTF-8 is the best choice as it will >>> handle practically any character. >>> >>> But if you're referring to Java resource bundles >>> the encoding for .properties is ISO-8859-1 but >>> there are means to handle any UTF-8 character. >>> >> Yes, an UTF-8 character can be encoded in >> ISO-8859-1. Java provides a native2ascii tool >> for converting entire files. The resource bundle >> tools in most IDE's do this for you >> automatically. So you just edit as UTF-8 and it >> saves the bundle as ISO-8859-1. >> >> We can read our bundles as UTF-8 if we want to do >> that. I'd rather not, because I'm not sure what >> we might run into down the road with Java >> assuming resource bundles are always ISO-8859-1. >> >> But I'd like to get the perspective of people who >> have handled resource bundles in languages that >> are not fully supported by ISO-8859-1. Is it too >> much of a pain to do a conversion or do the tools >> make the process seamless? >> >>> Best regards, >>> Thomas >>> >>> > >>> > On 7 October 2015 at 18:42, Stan Silvert >>> >> > wrote: >>> >> >>> >> Marko brought this to my attention yesterday. >>> For some things, we >>> >> dynamically create UI. In this case, the >>> java code contains the English >>> >> text and it needs to be localized. Luckily, >>> the solution was pretty >>> >> straightforward. We just replace the English >>> text with a key into the >>> >> message bundle. The html template that >>> displays this text already pulls >>> >> from an Angular scope so we just leave that >>> alone and pass it through >>> >> the |translate filter. You do need to also >>> add the double-colon. >>> >> >>> >> One nice side effect is that if the key is >>> not found in the bundle then >>> >> the output of the translate filter is the >>> unchanged text. This means >>> >> that any code which has not converted to >>> using bundle keys will still >>> >> work as expected. And, any third-party >>> providers can just pass in >>> >> plain text if they don't care about l10n. If >>> they ever do care about >>> >> l10n we will just need to provide a means for >>> them to add key/value >>> >> pairs to the resource bundles. >>> >> >>> >> Here is an example for anyone who needs to >>> localize English text >>> >> embedded in java: >>> >> >>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>> >> >>> >> Stan >>> >> _______________________________________________ >>> >> keycloak-dev mailing list >>> >> keycloak-dev at lists.jboss.org >>> >>> >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > >>> > >>> > >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> >>> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/8732d120/attachment-0001.html From sthorger at redhat.com Fri Oct 9 07:32:38 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Oct 2015 13:32:38 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: <5617A3DB.80200@redhat.com> References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> <5617A3DB.80200@redhat.com> Message-ID: #1 You're not going to catch all missing keys this way - as I said there's 2 types, custom defined as well which could be missing from default bundle #2 Rendering the whole bundle useless just because you're missing one key is just daft #3 There will quite likely be separate teams that do translations to those that do development, which means stack traces and log output is not the solution #4 Doing a check each time you pull a message bundle to compare with the base bundle is probably not that expensive, but still pretty daft thing to do #5 A proper util that's used to translate bundles is much better - we can implement a page in the admin console that allows you to validate a bundle and print out all missing bundles. This is something that would be more developer friendly and also would be usable by non-developers (aka people with other language skills than Java) On 9 October 2015 at 13:24, Stan Silvert wrote: > On 10/9/2015 6:21 AM, Marko Strukelj wrote: > > And we can always log the missing key situation into server log - that > should be enough for developers to notice it, and fix it. > > This is basically what happens with the code I wrote for the fix: > https://github.com/keycloak/keycloak/pull/1690 > > You get an error in the console and then a stack trace on the server. The > stack trace tells you exactly which key is missing. But the console > doesn't crash or anything like that. You just switch back to your original > language and everything works fine. > > > On Fri, Oct 9, 2015 at 8:09 AM, Stian Thorgersen > wrote: > >> There's two places where keys can be missing: >> >> * In a translation - this can be an honest mistake, or the translation >> wasn't updated when KC was updated >> * Custom keys added - for example when keys are used for display names of >> clients, roles, etc.. >> >> Manually having to go through all sorts of pages to look for missing keys >> is very error prone and time consuming, so will not be the best option for >> developers. In both cases above the correct way to do this would be to have >> a way to verify a message bundle. We need a tool that can quickly identify >> if there are missing keys and we could expose that through the admin >> console. We currently have a student looking at providing a UI for defining >> locales and she is also going to look at adding some way of identifying if >> a locale is missing keys and also to easily list only missing keys. >> >> For end users as I've said they will have no clue what ???key??? is, and >> even worse if we throw an exception/error just because a missing key we'll >> actually break the whole console just because of a missing key. It's a much >> better option to look for the key in another translation and display that. >> Chances are they will be able to interpret one or two English words. >> Certainly higher chance of that then them being able to interpret ???key???. >> >> >> On 9 October 2015 at 07:51, Thomas Raehalme < >> thomas.raehalme at aitiofinland.com> wrote: >> >>> How about returning something noticeable like ???key??? for example? >>> On Oct 9, 2015 8:10 AM, "Stian Thorgersen" wrote: >>> >>>> That's not putting it to rest at all! Throwing a RuntimeException and >>>> rendering the whole admin console useless just because there's a missing >>>> key is a horrible idea. >>>> >>>> On 8 October 2015 at 20:33, Stan Silvert wrote: >>>> >>>>> What if English is the bundle that has a missing key? >>>>> >>>>> Let's just put this to rest and solve it once and for all. The >>>>> simplest solution I can think of is to just compare keys when a new bundle >>>>> is loaded. If any bundle has a missing key or it has key not found in the >>>>> previous loaded bundle, we throw a RuntimeException. I can submit a patch >>>>> for that in just a few minutes. >>>>> >>>>> >>>>> On 10/8/2015 1:28 PM, Stian Thorgersen wrote: >>>>> >>>>> I'm not sure I'm buying into the argument that displaying the key is >>>>> better for developers. Having English suddenly pop-up in a German >>>>> translation is just as obvious as a key. Besides as Stan points out you >>>>> catch missing keys by comparing missing keys between English and German. >>>>> >>>>> However, if there is a mistake in a translation then a user may quite >>>>> likely be able to interpret English text, while a user will not be able to >>>>> interpret a key. So if a key is missing in a translation (which is >>>>> obviously a "bug") it's better to display English than to display the key. >>>>> >>>>> On 8 October 2015 at 14:13, Stan Silvert wrote: >>>>> >>>>>> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >>>>>> >>>>>> >>>>>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" >>>>>> wrote: >>>>>> > >>>>>> > With regards to internationalization I have two questions: >>>>>> > >>>>>> > * Should we fallback to English messages if a key is missing in a >>>>>> translation? Alternative is to show key, but that's not going to help anyone >>>>>> >>>>>> A missing key is a bug and showing the message in the default locale >>>>>> may hide the problem. >>>>>> >>>>>> Even though showing the key does not help the end user it helps the >>>>>> developer and identifies the problem. For this reason I think showing the >>>>>> key would be a good idea. >>>>>> >>>>>> For our bundles, we could catch missing keys at build time. >>>>>> >>>>>> Failing that, I agree that displaying the key is better than falling >>>>>> back to English. This is especially true right now while we haven't >>>>>> completed the task of converting everything. If we fall back to English we >>>>>> won't know if the problem is a missing key or if the text just hasn't been >>>>>> converted yet. >>>>>> >>>>>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 going >>>>>> to work for all languages? >>>>>> >>>>>> Depends what those all languages are :-) >>>>>> >>>>>> I think UTF-8 is the best choice as it will handle practically any >>>>>> character. >>>>>> >>>>>> But if you're referring to Java resource bundles the encoding for >>>>>> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >>>>>> >>>>>> Yes, an UTF-8 character can be encoded in ISO-8859-1. Java provides >>>>>> a native2ascii tool for converting entire files. The resource bundle tools >>>>>> in most IDE's do this for you automatically. So you just edit as UTF-8 and >>>>>> it saves the bundle as ISO-8859-1. >>>>>> >>>>>> We can read our bundles as UTF-8 if we want to do that. I'd rather >>>>>> not, because I'm not sure what we might run into down the road with Java >>>>>> assuming resource bundles are always ISO-8859-1. >>>>>> >>>>>> But I'd like to get the perspective of people who have handled >>>>>> resource bundles in languages that are not fully supported by ISO-8859-1. >>>>>> Is it too much of a pain to do a conversion or do the tools make the >>>>>> process seamless? >>>>>> >>>>>> Best regards, >>>>>> Thomas >>>>>> >>>>>> > >>>>>> > On 7 October 2015 at 18:42, Stan Silvert >>>>>> wrote: >>>>>> >> >>>>>> >> Marko brought this to my attention yesterday. For some things, we >>>>>> >> dynamically create UI. In this case, the java code contains the >>>>>> English >>>>>> >> text and it needs to be localized. Luckily, the solution was >>>>>> pretty >>>>>> >> straightforward. We just replace the English text with a key into >>>>>> the >>>>>> >> message bundle. The html template that displays this text already >>>>>> pulls >>>>>> >> from an Angular scope so we just leave that alone and pass it >>>>>> through >>>>>> >> the |translate filter. You do need to also add the double-colon. >>>>>> >> >>>>>> >> One nice side effect is that if the key is not found in the bundle >>>>>> then >>>>>> >> the output of the translate filter is the unchanged text. This >>>>>> means >>>>>> >> that any code which has not converted to using bundle keys will >>>>>> still >>>>>> >> work as expected. And, any third-party providers can just pass in >>>>>> >> plain text if they don't care about l10n. If they ever do care >>>>>> about >>>>>> >> l10n we will just need to provide a means for them to add key/value >>>>>> >> pairs to the resource bundles. >>>>>> >> >>>>>> >> Here is an example for anyone who needs to localize English text >>>>>> >> embedded in java: >>>>>> >> >>>>>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>>>>> >> >>>>>> >> Stan >>>>>> >> _______________________________________________ >>>>>> >> keycloak-dev mailing list >>>>>> >> keycloak-dev at lists.jboss.org >>>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > keycloak-dev mailing list >>>>>> > keycloak-dev at lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/852b0205/attachment-0001.html From ssilvert at redhat.com Fri Oct 9 07:46:04 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 09 Oct 2015 07:46:04 -0400 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> <5617A3DB.80200@redhat.com> Message-ID: <5617A8FC.50001@redhat.com> On 10/9/2015 7:32 AM, Stian Thorgersen wrote: > #1 You're not going to catch all missing keys this way - as I said > there's 2 types, custom defined as well which could be missing from > default bundle It catches it at load time. As it loads each bundle, it checks against the previously loaded bundle. That will indeed catch all missing keys in any bundle you try to test. I don't know exactly what you mean by "custom defined". Somehow a third-party bundle must be merged with our default bundle. Unless I completely misunderstand, the code I wrote will still work. > #2 Rendering the whole bundle useless just because you're missing one > key is just daft It is the correct thing to do. A missing key is like a null pointer. It deserves a RuntimeException. > #3 There will quite likely be separate teams that do translations to > those that do development, which means stack traces and log output is > not the solution I don't see what that has to do with anything. You start with a set of bundles containing all the correct keys. Then you translate each bundle. If you accidentally delete a key then you want to know that right away. But we should indeed ask the translation team what they want to see. > #4 Doing a check each time you pull a message bundle to compare with > the base bundle is probably not that expensive, but still pretty daft > thing to do You only load each bundle once. So the check only happens the first time you request the bundle. > #5 A proper util that's used to translate bundles is much better - we > can implement a page in the admin console that allows you to validate > a bundle and print out all missing bundles. This is something that > would be more developer friendly and also would be usable by > non-developers (aka people with other language skills than Java) We should ask the translation team what they want to see and how they do their work. I'm sure that they don't expect a tool to be built into the product. None of our other products have that. > > > On 9 October 2015 at 13:24, Stan Silvert > wrote: > > On 10/9/2015 6:21 AM, Marko Strukelj wrote: >> And we can always log the missing key situation into server log - >> that should be enough for developers to notice it, and fix it. > This is basically what happens with the code I wrote for the fix: > https://github.com/keycloak/keycloak/pull/1690 > > You get an error in the console and then a stack trace on the > server. The stack trace tells you exactly which key is missing. > But the console doesn't crash or anything like that. You just > switch back to your original language and everything works fine. > >> >> On Fri, Oct 9, 2015 at 8:09 AM, Stian Thorgersen >> > wrote: >> >> There's two places where keys can be missing: >> >> * In a translation - this can be an honest mistake, or the >> translation wasn't updated when KC was updated >> * Custom keys added - for example when keys are used for >> display names of clients, roles, etc.. >> >> Manually having to go through all sorts of pages to look for >> missing keys is very error prone and time consuming, so will >> not be the best option for developers. In both cases above >> the correct way to do this would be to have a way to verify a >> message bundle. We need a tool that can quickly identify if >> there are missing keys and we could expose that through the >> admin console. We currently have a student looking at >> providing a UI for defining locales and she is also going to >> look at adding some way of identifying if a locale is missing >> keys and also to easily list only missing keys. >> >> For end users as I've said they will have no clue what >> ???key??? is, and even worse if we throw an exception/error >> just because a missing key we'll actually break the whole >> console just because of a missing key. It's a much better >> option to look for the key in another translation and display >> that. Chances are they will be able to interpret one or two >> English words. Certainly higher chance of that then them >> being able to interpret ???key???. >> >> >> On 9 October 2015 at 07:51, Thomas Raehalme >> > > wrote: >> >> How about returning something noticeable like ???key??? >> for example? >> >> On Oct 9, 2015 8:10 AM, "Stian Thorgersen" >> > wrote: >> >> That's not putting it to rest at all! Throwing a >> RuntimeException and rendering the whole admin >> console useless just because there's a missing key is >> a horrible idea. >> >> On 8 October 2015 at 20:33, Stan Silvert >> > wrote: >> >> What if English is the bundle that has a missing key? >> >> Let's just put this to rest and solve it once and >> for all. The simplest solution I can think of is >> to just compare keys when a new bundle is loaded. >> If any bundle has a missing key or it has key not >> found in the previous loaded bundle, we throw a >> RuntimeException. I can submit a patch for that >> in just a few minutes. >> >> >> On 10/8/2015 1:28 PM, Stian Thorgersen wrote: >>> I'm not sure I'm buying into the argument that >>> displaying the key is better for developers. >>> Having English suddenly pop-up in a German >>> translation is just as obvious as a key. Besides >>> as Stan points out you catch missing keys by >>> comparing missing keys between English and German. >>> >>> However, if there is a mistake in a translation >>> then a user may quite likely be able to >>> interpret English text, while a user will not be >>> able to interpret a key. So if a key is missing >>> in a translation (which is obviously a "bug") >>> it's better to display English than to display >>> the key. >>> >>> On 8 October 2015 at 14:13, Stan Silvert >>> >> > wrote: >>> >>> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >>>> >>>> >>>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" >>>> >>> > wrote: >>>> > >>>> > With regards to internationalization I >>>> have two questions: >>>> > >>>> > * Should we fallback to English messages >>>> if a key is missing in a translation? >>>> Alternative is to show key, but that's not >>>> going to help anyone >>>> >>>> A missing key is a bug and showing the >>>> message in the default locale may hide the >>>> problem. >>>> >>>> Even though showing the key does not help >>>> the end user it helps the developer and >>>> identifies the problem. For this reason I >>>> think showing the key would be a good idea. >>>> >>> For our bundles, we could catch missing keys >>> at build time. >>> >>> Failing that, I agree that displaying the >>> key is better than falling back to English. >>> This is especially true right now while we >>> haven't completed the task of converting >>> everything. If we fall back to English we >>> won't know if the problem is a missing key >>> or if the text just hasn't been converted yet. >>> >>>> > * Should we change message bundles to >>>> UTF-8? Or is ISO 8859-1 going to work for >>>> all languages? >>>> >>>> Depends what those all languages are :-) >>>> >>>> I think UTF-8 is the best choice as it will >>>> handle practically any character. >>>> >>>> But if you're referring to Java resource >>>> bundles the encoding for .properties is >>>> ISO-8859-1 but there are means to handle >>>> any UTF-8 character. >>>> >>> Yes, an UTF-8 character can be encoded in >>> ISO-8859-1. Java provides a native2ascii >>> tool for converting entire files. The >>> resource bundle tools in most IDE's do this >>> for you automatically. So you just edit as >>> UTF-8 and it saves the bundle as ISO-8859-1. >>> >>> We can read our bundles as UTF-8 if we want >>> to do that. I'd rather not, because I'm not >>> sure what we might run into down the road >>> with Java assuming resource bundles are >>> always ISO-8859-1. >>> >>> But I'd like to get the perspective of >>> people who have handled resource bundles in >>> languages that are not fully supported by >>> ISO-8859-1. Is it too much of a pain to do a >>> conversion or do the tools make the process >>> seamless? >>> >>>> Best regards, >>>> Thomas >>>> >>>> > >>>> > On 7 October 2015 at 18:42, Stan Silvert >>>> >>> > wrote: >>>> >> >>>> >> Marko brought this to my attention >>>> yesterday. For some things, we >>>> >> dynamically create UI. In this case, >>>> the java code contains the English >>>> >> text and it needs to be localized. >>>> Luckily, the solution was pretty >>>> >> straightforward. We just replace the >>>> English text with a key into the >>>> >> message bundle. The html template that >>>> displays this text already pulls >>>> >> from an Angular scope so we just leave >>>> that alone and pass it through >>>> >> the |translate filter. You do need to >>>> also add the double-colon. >>>> >> >>>> >> One nice side effect is that if the key >>>> is not found in the bundle then >>>> >> the output of the translate filter is >>>> the unchanged text. This means >>>> >> that any code which has not converted to >>>> using bundle keys will still >>>> >> work as expected. And, any third-party >>>> providers can just pass in >>>> >> plain text if they don't care about >>>> l10n. If they ever do care about >>>> >> l10n we will just need to provide a >>>> means for them to add key/value >>>> >> pairs to the resource bundles. >>>> >> >>>> >> Here is an example for anyone who needs >>>> to localize English text >>>> >> embedded in java: >>>> >> >>>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>>> >> >>>> >> Stan >>>> >> >>>> _______________________________________________ >>>> >> keycloak-dev mailing list >>>> >> keycloak-dev at lists.jboss.org >>>> >>>> >> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev at lists.jboss.org >>>> >>>> > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/5682dbe3/attachment-0001.html From sthorger at redhat.com Fri Oct 9 07:56:26 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Oct 2015 13:56:26 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: <5617A8FC.50001@redhat.com> References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> <5617A3DB.80200@redhat.com> <5617A8FC.50001@redhat.com> Message-ID: On 9 October 2015 at 13:46, Stan Silvert wrote: > On 10/9/2015 7:32 AM, Stian Thorgersen wrote: > > #1 You're not going to catch all missing keys this way - as I said there's > 2 types, custom defined as well which could be missing from default bundle > > It catches it at load time. As it loads each bundle, it checks against > the previously loaded bundle. That will indeed catch all missing keys in > any bundle you try to test. > > I don't know exactly what you mean by "custom defined". Somehow a > third-party bundle must be merged with our default bundle. Unless I > completely misunderstand, the code I wrote will still work. > New keys can be defined by using keys in client descriptions, client names, etc, etc.. These won't be in our message bundle, but would be in the bundle in a customers theme. This is why message bundles inherit from the parent theme. Custom providers and themes can further introduce new keys. > > #2 Rendering the whole bundle useless just because you're missing one key > is just daft > > It is the correct thing to do. A missing key is like a null pointer. It > deserves a RuntimeException. > No it's not the correct thing to do. > > #3 There will quite likely be separate teams that do translations to those > that do development, which means stack traces and log output is not the > solution > > I don't see what that has to do with anything. You start with a set of > bundles containing all the correct keys. Then you translate each bundle. > If you accidentally delete a key then you want to know that right away. > But we should indeed ask the translation team what they want to see. > Sure, go ahead and ask them if they want to look for RuntimeExceptions in the server log. > > #4 Doing a check each time you pull a message bundle to compare with the > base bundle is probably not that expensive, but still pretty daft thing to > do > > You only load each bundle once. So the check only happens the first time > you request the bundle. > > #5 A proper util that's used to translate bundles is much better - we can > implement a page in the admin console that allows you to validate a bundle > and print out all missing bundles. This is something that would be more > developer friendly and also would be usable by non-developers (aka people > with other language skills than Java) > > We should ask the translation team what they want to see and how they do > their work. I'm sure that they don't expect a tool to be built into the > product. None of our other products have that. > I don't just care about our translation team, they will translate the built in keys, but they won't translate the ones introduced by users. > > > > On 9 October 2015 at 13:24, Stan Silvert wrote: > >> On 10/9/2015 6:21 AM, Marko Strukelj wrote: >> >> And we can always log the missing key situation into server log - that >> should be enough for developers to notice it, and fix it. >> >> This is basically what happens with the code I wrote for the fix: >> https://github.com/keycloak/keycloak/pull/1690 >> >> You get an error in the console and then a stack trace on the server. >> The stack trace tells you exactly which key is missing. But the console >> doesn't crash or anything like that. You just switch back to your original >> language and everything works fine. >> >> >> On Fri, Oct 9, 2015 at 8:09 AM, Stian Thorgersen >> wrote: >> >>> There's two places where keys can be missing: >>> >>> * In a translation - this can be an honest mistake, or the translation >>> wasn't updated when KC was updated >>> * Custom keys added - for example when keys are used for display names >>> of clients, roles, etc.. >>> >>> Manually having to go through all sorts of pages to look for missing >>> keys is very error prone and time consuming, so will not be the best option >>> for developers. In both cases above the correct way to do this would be to >>> have a way to verify a message bundle. We need a tool that can quickly >>> identify if there are missing keys and we could expose that through the >>> admin console. We currently have a student looking at providing a UI for >>> defining locales and she is also going to look at adding some way of >>> identifying if a locale is missing keys and also to easily list only >>> missing keys. >>> >>> For end users as I've said they will have no clue what ???key??? is, and >>> even worse if we throw an exception/error just because a missing key we'll >>> actually break the whole console just because of a missing key. It's a much >>> better option to look for the key in another translation and display that. >>> Chances are they will be able to interpret one or two English words. >>> Certainly higher chance of that then them being able to interpret ???key???. >>> >>> >>> On 9 October 2015 at 07:51, Thomas Raehalme < >>> thomas.raehalme at aitiofinland.com> wrote: >>> >>>> How about returning something noticeable like ???key??? for example? >>>> On Oct 9, 2015 8:10 AM, "Stian Thorgersen" wrote: >>>> >>>>> That's not putting it to rest at all! Throwing a RuntimeException and >>>>> rendering the whole admin console useless just because there's a missing >>>>> key is a horrible idea. >>>>> >>>>> On 8 October 2015 at 20:33, Stan Silvert wrote: >>>>> >>>>>> What if English is the bundle that has a missing key? >>>>>> >>>>>> Let's just put this to rest and solve it once and for all. The >>>>>> simplest solution I can think of is to just compare keys when a new bundle >>>>>> is loaded. If any bundle has a missing key or it has key not found in the >>>>>> previous loaded bundle, we throw a RuntimeException. I can submit a patch >>>>>> for that in just a few minutes. >>>>>> >>>>>> >>>>>> On 10/8/2015 1:28 PM, Stian Thorgersen wrote: >>>>>> >>>>>> I'm not sure I'm buying into the argument that displaying the key is >>>>>> better for developers. Having English suddenly pop-up in a German >>>>>> translation is just as obvious as a key. Besides as Stan points out you >>>>>> catch missing keys by comparing missing keys between English and German. >>>>>> >>>>>> However, if there is a mistake in a translation then a user may quite >>>>>> likely be able to interpret English text, while a user will not be able to >>>>>> interpret a key. So if a key is missing in a translation (which is >>>>>> obviously a "bug") it's better to display English than to display the key. >>>>>> >>>>>> On 8 October 2015 at 14:13, Stan Silvert wrote: >>>>>> >>>>>>> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >>>>>>> >>>>>>> >>>>>>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" >>>>>>> wrote: >>>>>>> > >>>>>>> > With regards to internationalization I have two questions: >>>>>>> > >>>>>>> > * Should we fallback to English messages if a key is missing in a >>>>>>> translation? Alternative is to show key, but that's not going to help anyone >>>>>>> >>>>>>> A missing key is a bug and showing the message in the default locale >>>>>>> may hide the problem. >>>>>>> >>>>>>> Even though showing the key does not help the end user it helps the >>>>>>> developer and identifies the problem. For this reason I think showing the >>>>>>> key would be a good idea. >>>>>>> >>>>>>> For our bundles, we could catch missing keys at build time. >>>>>>> >>>>>>> Failing that, I agree that displaying the key is better than falling >>>>>>> back to English. This is especially true right now while we haven't >>>>>>> completed the task of converting everything. If we fall back to English we >>>>>>> won't know if the problem is a missing key or if the text just hasn't been >>>>>>> converted yet. >>>>>>> >>>>>>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 >>>>>>> going to work for all languages? >>>>>>> >>>>>>> Depends what those all languages are :-) >>>>>>> >>>>>>> I think UTF-8 is the best choice as it will handle practically any >>>>>>> character. >>>>>>> >>>>>>> But if you're referring to Java resource bundles the encoding for >>>>>>> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >>>>>>> >>>>>>> Yes, an UTF-8 character can be encoded in ISO-8859-1. Java provides >>>>>>> a native2ascii tool for converting entire files. The resource bundle tools >>>>>>> in most IDE's do this for you automatically. So you just edit as UTF-8 and >>>>>>> it saves the bundle as ISO-8859-1. >>>>>>> >>>>>>> We can read our bundles as UTF-8 if we want to do that. I'd rather >>>>>>> not, because I'm not sure what we might run into down the road with Java >>>>>>> assuming resource bundles are always ISO-8859-1. >>>>>>> >>>>>>> But I'd like to get the perspective of people who have handled >>>>>>> resource bundles in languages that are not fully supported by ISO-8859-1. >>>>>>> Is it too much of a pain to do a conversion or do the tools make the >>>>>>> process seamless? >>>>>>> >>>>>>> Best regards, >>>>>>> Thomas >>>>>>> >>>>>>> > >>>>>>> > On 7 October 2015 at 18:42, Stan Silvert >>>>>>> wrote: >>>>>>> >> >>>>>>> >> Marko brought this to my attention yesterday. For some things, we >>>>>>> >> dynamically create UI. In this case, the java code contains the >>>>>>> English >>>>>>> >> text and it needs to be localized. Luckily, the solution was >>>>>>> pretty >>>>>>> >> straightforward. We just replace the English text with a key >>>>>>> into the >>>>>>> >> message bundle. The html template that displays this text >>>>>>> already pulls >>>>>>> >> from an Angular scope so we just leave that alone and pass it >>>>>>> through >>>>>>> >> the |translate filter. You do need to also add the double-colon. >>>>>>> >> >>>>>>> >> One nice side effect is that if the key is not found in the >>>>>>> bundle then >>>>>>> >> the output of the translate filter is the unchanged text. This >>>>>>> means >>>>>>> >> that any code which has not converted to using bundle keys will >>>>>>> still >>>>>>> >> work as expected. And, any third-party providers can just pass >>>>>>> in >>>>>>> >> plain text if they don't care about l10n. If they ever do care >>>>>>> about >>>>>>> >> l10n we will just need to provide a means for them to add >>>>>>> key/value >>>>>>> >> pairs to the resource bundles. >>>>>>> >> >>>>>>> >> Here is an example for anyone who needs to localize English text >>>>>>> >> embedded in java: >>>>>>> >> >>>>>>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>>>>>> >> >>>>>>> >> Stan >>>>>>> >> _______________________________________________ >>>>>>> >> keycloak-dev mailing list >>>>>>> >> keycloak-dev at lists.jboss.org >>>>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > keycloak-dev mailing list >>>>>>> > keycloak-dev at lists.jboss.org >>>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/efd37548/attachment-0001.html From sthorger at redhat.com Fri Oct 9 07:57:42 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Oct 2015 13:57:42 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> <5617A3DB.80200@redhat.com> <5617A8FC.50001@redhat.com> Message-ID: By the way I'm pretty sure our translation theme will take our English bundle and translate it to a language. They won't need to start/stop the server and open the admin console to check that they've translated all keys. They should have a tool/script for that. On 9 October 2015 at 13:56, Stian Thorgersen wrote: > > > On 9 October 2015 at 13:46, Stan Silvert wrote: > >> On 10/9/2015 7:32 AM, Stian Thorgersen wrote: >> >> #1 You're not going to catch all missing keys this way - as I said >> there's 2 types, custom defined as well which could be missing from default >> bundle >> >> It catches it at load time. As it loads each bundle, it checks against >> the previously loaded bundle. That will indeed catch all missing keys in >> any bundle you try to test. >> >> I don't know exactly what you mean by "custom defined". Somehow a >> third-party bundle must be merged with our default bundle. Unless I >> completely misunderstand, the code I wrote will still work. >> > > New keys can be defined by using keys in client descriptions, client > names, etc, etc.. These won't be in our message bundle, but would be in the > bundle in a customers theme. This is why message bundles inherit from the > parent theme. Custom providers and themes can further introduce new keys. > > >> >> #2 Rendering the whole bundle useless just because you're missing one key >> is just daft >> >> It is the correct thing to do. A missing key is like a null pointer. It >> deserves a RuntimeException. >> > > No it's not the correct thing to do. > > >> >> #3 There will quite likely be separate teams that do translations to >> those that do development, which means stack traces and log output is not >> the solution >> >> I don't see what that has to do with anything. You start with a set of >> bundles containing all the correct keys. Then you translate each bundle. >> If you accidentally delete a key then you want to know that right away. >> But we should indeed ask the translation team what they want to see. >> > > Sure, go ahead and ask them if they want to look for RuntimeExceptions in > the server log. > > >> >> #4 Doing a check each time you pull a message bundle to compare with the >> base bundle is probably not that expensive, but still pretty daft thing to >> do >> >> You only load each bundle once. So the check only happens the first time >> you request the bundle. >> >> #5 A proper util that's used to translate bundles is much better - we can >> implement a page in the admin console that allows you to validate a bundle >> and print out all missing bundles. This is something that would be more >> developer friendly and also would be usable by non-developers (aka people >> with other language skills than Java) >> >> We should ask the translation team what they want to see and how they do >> their work. I'm sure that they don't expect a tool to be built into the >> product. None of our other products have that. >> > > I don't just care about our translation team, they will translate the > built in keys, but they won't translate the ones introduced by users. > > > >> >> >> >> On 9 October 2015 at 13:24, Stan Silvert wrote: >> >>> On 10/9/2015 6:21 AM, Marko Strukelj wrote: >>> >>> And we can always log the missing key situation into server log - that >>> should be enough for developers to notice it, and fix it. >>> >>> This is basically what happens with the code I wrote for the fix: >>> https://github.com/keycloak/keycloak/pull/1690 >>> >>> You get an error in the console and then a stack trace on the server. >>> The stack trace tells you exactly which key is missing. But the console >>> doesn't crash or anything like that. You just switch back to your original >>> language and everything works fine. >>> >>> >>> On Fri, Oct 9, 2015 at 8:09 AM, Stian Thorgersen >>> wrote: >>> >>>> There's two places where keys can be missing: >>>> >>>> * In a translation - this can be an honest mistake, or the translation >>>> wasn't updated when KC was updated >>>> * Custom keys added - for example when keys are used for display names >>>> of clients, roles, etc.. >>>> >>>> Manually having to go through all sorts of pages to look for missing >>>> keys is very error prone and time consuming, so will not be the best option >>>> for developers. In both cases above the correct way to do this would be to >>>> have a way to verify a message bundle. We need a tool that can quickly >>>> identify if there are missing keys and we could expose that through the >>>> admin console. We currently have a student looking at providing a UI for >>>> defining locales and she is also going to look at adding some way of >>>> identifying if a locale is missing keys and also to easily list only >>>> missing keys. >>>> >>>> For end users as I've said they will have no clue what ???key??? is, >>>> and even worse if we throw an exception/error just because a missing key >>>> we'll actually break the whole console just because of a missing key. It's >>>> a much better option to look for the key in another translation and display >>>> that. Chances are they will be able to interpret one or two English words. >>>> Certainly higher chance of that then them being able to interpret ???key???. >>>> >>>> >>>> On 9 October 2015 at 07:51, Thomas Raehalme < >>>> thomas.raehalme at aitiofinland.com> wrote: >>>> >>>>> How about returning something noticeable like ???key??? for example? >>>>> On Oct 9, 2015 8:10 AM, "Stian Thorgersen" >>>>> wrote: >>>>> >>>>>> That's not putting it to rest at all! Throwing a RuntimeException and >>>>>> rendering the whole admin console useless just because there's a missing >>>>>> key is a horrible idea. >>>>>> >>>>>> On 8 October 2015 at 20:33, Stan Silvert wrote: >>>>>> >>>>>>> What if English is the bundle that has a missing key? >>>>>>> >>>>>>> Let's just put this to rest and solve it once and for all. The >>>>>>> simplest solution I can think of is to just compare keys when a new bundle >>>>>>> is loaded. If any bundle has a missing key or it has key not found in the >>>>>>> previous loaded bundle, we throw a RuntimeException. I can submit a patch >>>>>>> for that in just a few minutes. >>>>>>> >>>>>>> >>>>>>> On 10/8/2015 1:28 PM, Stian Thorgersen wrote: >>>>>>> >>>>>>> I'm not sure I'm buying into the argument that displaying the key is >>>>>>> better for developers. Having English suddenly pop-up in a German >>>>>>> translation is just as obvious as a key. Besides as Stan points out you >>>>>>> catch missing keys by comparing missing keys between English and German. >>>>>>> >>>>>>> However, if there is a mistake in a translation then a user may >>>>>>> quite likely be able to interpret English text, while a user will not be >>>>>>> able to interpret a key. So if a key is missing in a translation (which is >>>>>>> obviously a "bug") it's better to display English than to display the key. >>>>>>> >>>>>>> On 8 October 2015 at 14:13, Stan Silvert >>>>>>> wrote: >>>>>>> >>>>>>>> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > With regards to internationalization I have two questions: >>>>>>>> > >>>>>>>> > * Should we fallback to English messages if a key is missing in a >>>>>>>> translation? Alternative is to show key, but that's not going to help anyone >>>>>>>> >>>>>>>> A missing key is a bug and showing the message in the default >>>>>>>> locale may hide the problem. >>>>>>>> >>>>>>>> Even though showing the key does not help the end user it helps the >>>>>>>> developer and identifies the problem. For this reason I think showing the >>>>>>>> key would be a good idea. >>>>>>>> >>>>>>>> For our bundles, we could catch missing keys at build time. >>>>>>>> >>>>>>>> Failing that, I agree that displaying the key is better than >>>>>>>> falling back to English. This is especially true right now while we >>>>>>>> haven't completed the task of converting everything. If we fall back to >>>>>>>> English we won't know if the problem is a missing key or if the text just >>>>>>>> hasn't been converted yet. >>>>>>>> >>>>>>>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 >>>>>>>> going to work for all languages? >>>>>>>> >>>>>>>> Depends what those all languages are :-) >>>>>>>> >>>>>>>> I think UTF-8 is the best choice as it will handle practically any >>>>>>>> character. >>>>>>>> >>>>>>>> But if you're referring to Java resource bundles the encoding for >>>>>>>> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >>>>>>>> >>>>>>>> Yes, an UTF-8 character can be encoded in ISO-8859-1. Java >>>>>>>> provides a native2ascii tool for converting entire files. The resource >>>>>>>> bundle tools in most IDE's do this for you automatically. So you just edit >>>>>>>> as UTF-8 and it saves the bundle as ISO-8859-1. >>>>>>>> >>>>>>>> We can read our bundles as UTF-8 if we want to do that. I'd rather >>>>>>>> not, because I'm not sure what we might run into down the road with Java >>>>>>>> assuming resource bundles are always ISO-8859-1. >>>>>>>> >>>>>>>> But I'd like to get the perspective of people who have handled >>>>>>>> resource bundles in languages that are not fully supported by ISO-8859-1. >>>>>>>> Is it too much of a pain to do a conversion or do the tools make the >>>>>>>> process seamless? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Thomas >>>>>>>> >>>>>>>> > >>>>>>>> > On 7 October 2015 at 18:42, Stan Silvert >>>>>>>> wrote: >>>>>>>> >> >>>>>>>> >> Marko brought this to my attention yesterday. For some things, >>>>>>>> we >>>>>>>> >> dynamically create UI. In this case, the java code contains the >>>>>>>> English >>>>>>>> >> text and it needs to be localized. Luckily, the solution was >>>>>>>> pretty >>>>>>>> >> straightforward. We just replace the English text with a key >>>>>>>> into the >>>>>>>> >> message bundle. The html template that displays this text >>>>>>>> already pulls >>>>>>>> >> from an Angular scope so we just leave that alone and pass it >>>>>>>> through >>>>>>>> >> the |translate filter. You do need to also add the double-colon. >>>>>>>> >> >>>>>>>> >> One nice side effect is that if the key is not found in the >>>>>>>> bundle then >>>>>>>> >> the output of the translate filter is the unchanged text. This >>>>>>>> means >>>>>>>> >> that any code which has not converted to using bundle keys will >>>>>>>> still >>>>>>>> >> work as expected. And, any third-party providers can just pass >>>>>>>> in >>>>>>>> >> plain text if they don't care about l10n. If they ever do care >>>>>>>> about >>>>>>>> >> l10n we will just need to provide a means for them to add >>>>>>>> key/value >>>>>>>> >> pairs to the resource bundles. >>>>>>>> >> >>>>>>>> >> Here is an example for anyone who needs to localize English text >>>>>>>> >> embedded in java: >>>>>>>> >> >>>>>>>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>>>>>>> >> >>>>>>>> >> Stan >>>>>>>> >> _______________________________________________ >>>>>>>> >> keycloak-dev mailing list >>>>>>>> >> keycloak-dev at lists.jboss.org >>>>>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > keycloak-dev mailing list >>>>>>>> > keycloak-dev at lists.jboss.org >>>>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/1d0a1062/attachment-0001.html From sthorger at redhat.com Fri Oct 9 07:57:54 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 9 Oct 2015 13:57:54 +0200 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> <56165DFA.50707@redhat.com> <5616B6E4.3060906@redhat.com> <5617A3DB.80200@redhat.com> <5617A8FC.50001@redhat.com> Message-ID: Translation team that is On 9 October 2015 at 13:57, Stian Thorgersen wrote: > By the way I'm pretty sure our translation theme will take our English > bundle and translate it to a language. They won't need to start/stop the > server and open the admin console to check that they've translated all > keys. They should have a tool/script for that. > > On 9 October 2015 at 13:56, Stian Thorgersen wrote: > >> >> >> On 9 October 2015 at 13:46, Stan Silvert wrote: >> >>> On 10/9/2015 7:32 AM, Stian Thorgersen wrote: >>> >>> #1 You're not going to catch all missing keys this way - as I said >>> there's 2 types, custom defined as well which could be missing from default >>> bundle >>> >>> It catches it at load time. As it loads each bundle, it checks against >>> the previously loaded bundle. That will indeed catch all missing keys in >>> any bundle you try to test. >>> >>> I don't know exactly what you mean by "custom defined". Somehow a >>> third-party bundle must be merged with our default bundle. Unless I >>> completely misunderstand, the code I wrote will still work. >>> >> >> New keys can be defined by using keys in client descriptions, client >> names, etc, etc.. These won't be in our message bundle, but would be in the >> bundle in a customers theme. This is why message bundles inherit from the >> parent theme. Custom providers and themes can further introduce new keys. >> >> >>> >>> #2 Rendering the whole bundle useless just because you're missing one >>> key is just daft >>> >>> It is the correct thing to do. A missing key is like a null pointer. >>> It deserves a RuntimeException. >>> >> >> No it's not the correct thing to do. >> >> >>> >>> #3 There will quite likely be separate teams that do translations to >>> those that do development, which means stack traces and log output is not >>> the solution >>> >>> I don't see what that has to do with anything. You start with a set of >>> bundles containing all the correct keys. Then you translate each bundle. >>> If you accidentally delete a key then you want to know that right away. >>> But we should indeed ask the translation team what they want to see. >>> >> >> Sure, go ahead and ask them if they want to look for RuntimeExceptions in >> the server log. >> >> >>> >>> #4 Doing a check each time you pull a message bundle to compare with the >>> base bundle is probably not that expensive, but still pretty daft thing to >>> do >>> >>> You only load each bundle once. So the check only happens the first >>> time you request the bundle. >>> >>> #5 A proper util that's used to translate bundles is much better - we >>> can implement a page in the admin console that allows you to validate a >>> bundle and print out all missing bundles. This is something that would be >>> more developer friendly and also would be usable by non-developers (aka >>> people with other language skills than Java) >>> >>> We should ask the translation team what they want to see and how they do >>> their work. I'm sure that they don't expect a tool to be built into the >>> product. None of our other products have that. >>> >> >> I don't just care about our translation team, they will translate the >> built in keys, but they won't translate the ones introduced by users. >> >> >> >>> >>> >>> >>> On 9 October 2015 at 13:24, Stan Silvert wrote: >>> >>>> On 10/9/2015 6:21 AM, Marko Strukelj wrote: >>>> >>>> And we can always log the missing key situation into server log - that >>>> should be enough for developers to notice it, and fix it. >>>> >>>> This is basically what happens with the code I wrote for the fix: >>>> https://github.com/keycloak/keycloak/pull/1690 >>>> >>>> You get an error in the console and then a stack trace on the server. >>>> The stack trace tells you exactly which key is missing. But the console >>>> doesn't crash or anything like that. You just switch back to your original >>>> language and everything works fine. >>>> >>>> >>>> On Fri, Oct 9, 2015 at 8:09 AM, Stian Thorgersen >>>> wrote: >>>> >>>>> There's two places where keys can be missing: >>>>> >>>>> * In a translation - this can be an honest mistake, or the translation >>>>> wasn't updated when KC was updated >>>>> * Custom keys added - for example when keys are used for display names >>>>> of clients, roles, etc.. >>>>> >>>>> Manually having to go through all sorts of pages to look for missing >>>>> keys is very error prone and time consuming, so will not be the best option >>>>> for developers. In both cases above the correct way to do this would be to >>>>> have a way to verify a message bundle. We need a tool that can quickly >>>>> identify if there are missing keys and we could expose that through the >>>>> admin console. We currently have a student looking at providing a UI for >>>>> defining locales and she is also going to look at adding some way of >>>>> identifying if a locale is missing keys and also to easily list only >>>>> missing keys. >>>>> >>>>> For end users as I've said they will have no clue what ???key??? is, >>>>> and even worse if we throw an exception/error just because a missing key >>>>> we'll actually break the whole console just because of a missing key. It's >>>>> a much better option to look for the key in another translation and display >>>>> that. Chances are they will be able to interpret one or two English words. >>>>> Certainly higher chance of that then them being able to interpret ???key???. >>>>> >>>>> >>>>> On 9 October 2015 at 07:51, Thomas Raehalme < >>>>> thomas.raehalme at aitiofinland.com> wrote: >>>>> >>>>>> How about returning something noticeable like ???key??? for example? >>>>>> On Oct 9, 2015 8:10 AM, "Stian Thorgersen" >>>>>> wrote: >>>>>> >>>>>>> That's not putting it to rest at all! Throwing a RuntimeException >>>>>>> and rendering the whole admin console useless just because there's a >>>>>>> missing key is a horrible idea. >>>>>>> >>>>>>> On 8 October 2015 at 20:33, Stan Silvert >>>>>>> wrote: >>>>>>> >>>>>>>> What if English is the bundle that has a missing key? >>>>>>>> >>>>>>>> Let's just put this to rest and solve it once and for all. The >>>>>>>> simplest solution I can think of is to just compare keys when a new bundle >>>>>>>> is loaded. If any bundle has a missing key or it has key not found in the >>>>>>>> previous loaded bundle, we throw a RuntimeException. I can submit a patch >>>>>>>> for that in just a few minutes. >>>>>>>> >>>>>>>> >>>>>>>> On 10/8/2015 1:28 PM, Stian Thorgersen wrote: >>>>>>>> >>>>>>>> I'm not sure I'm buying into the argument that displaying the key >>>>>>>> is better for developers. Having English suddenly pop-up in a German >>>>>>>> translation is just as obvious as a key. Besides as Stan points out you >>>>>>>> catch missing keys by comparing missing keys between English and German. >>>>>>>> >>>>>>>> However, if there is a mistake in a translation then a user may >>>>>>>> quite likely be able to interpret English text, while a user will not be >>>>>>>> able to interpret a key. So if a key is missing in a translation (which is >>>>>>>> obviously a "bug") it's better to display English than to display the key. >>>>>>>> >>>>>>>> On 8 October 2015 at 14:13, Stan Silvert >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 10/8/2015 12:48 AM, Thomas Raehalme wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Oct 8, 2015 6:53 AM, "Stian Thorgersen" >>>>>>>>> wrote: >>>>>>>>> > >>>>>>>>> > With regards to internationalization I have two questions: >>>>>>>>> > >>>>>>>>> > * Should we fallback to English messages if a key is missing in >>>>>>>>> a translation? Alternative is to show key, but that's not going to help >>>>>>>>> anyone >>>>>>>>> >>>>>>>>> A missing key is a bug and showing the message in the default >>>>>>>>> locale may hide the problem. >>>>>>>>> >>>>>>>>> Even though showing the key does not help the end user it helps >>>>>>>>> the developer and identifies the problem. For this reason I think showing >>>>>>>>> the key would be a good idea. >>>>>>>>> >>>>>>>>> For our bundles, we could catch missing keys at build time. >>>>>>>>> >>>>>>>>> Failing that, I agree that displaying the key is better than >>>>>>>>> falling back to English. This is especially true right now while we >>>>>>>>> haven't completed the task of converting everything. If we fall back to >>>>>>>>> English we won't know if the problem is a missing key or if the text just >>>>>>>>> hasn't been converted yet. >>>>>>>>> >>>>>>>>> > * Should we change message bundles to UTF-8? Or is ISO 8859-1 >>>>>>>>> going to work for all languages? >>>>>>>>> >>>>>>>>> Depends what those all languages are :-) >>>>>>>>> >>>>>>>>> I think UTF-8 is the best choice as it will handle practically any >>>>>>>>> character. >>>>>>>>> >>>>>>>>> But if you're referring to Java resource bundles the encoding for >>>>>>>>> .properties is ISO-8859-1 but there are means to handle any UTF-8 character. >>>>>>>>> >>>>>>>>> Yes, an UTF-8 character can be encoded in ISO-8859-1. Java >>>>>>>>> provides a native2ascii tool for converting entire files. The resource >>>>>>>>> bundle tools in most IDE's do this for you automatically. So you just edit >>>>>>>>> as UTF-8 and it saves the bundle as ISO-8859-1. >>>>>>>>> >>>>>>>>> We can read our bundles as UTF-8 if we want to do that. I'd >>>>>>>>> rather not, because I'm not sure what we might run into down the road with >>>>>>>>> Java assuming resource bundles are always ISO-8859-1. >>>>>>>>> >>>>>>>>> But I'd like to get the perspective of people who have handled >>>>>>>>> resource bundles in languages that are not fully supported by ISO-8859-1. >>>>>>>>> Is it too much of a pain to do a conversion or do the tools make the >>>>>>>>> process seamless? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Thomas >>>>>>>>> >>>>>>>>> > >>>>>>>>> > On 7 October 2015 at 18:42, Stan Silvert >>>>>>>>> wrote: >>>>>>>>> >> >>>>>>>>> >> Marko brought this to my attention yesterday. For some things, >>>>>>>>> we >>>>>>>>> >> dynamically create UI. In this case, the java code contains >>>>>>>>> the English >>>>>>>>> >> text and it needs to be localized. Luckily, the solution was >>>>>>>>> pretty >>>>>>>>> >> straightforward. We just replace the English text with a key >>>>>>>>> into the >>>>>>>>> >> message bundle. The html template that displays this text >>>>>>>>> already pulls >>>>>>>>> >> from an Angular scope so we just leave that alone and pass it >>>>>>>>> through >>>>>>>>> >> the |translate filter. You do need to also add the >>>>>>>>> double-colon. >>>>>>>>> >> >>>>>>>>> >> One nice side effect is that if the key is not found in the >>>>>>>>> bundle then >>>>>>>>> >> the output of the translate filter is the unchanged text. This >>>>>>>>> means >>>>>>>>> >> that any code which has not converted to using bundle keys will >>>>>>>>> still >>>>>>>>> >> work as expected. And, any third-party providers can just >>>>>>>>> pass in >>>>>>>>> >> plain text if they don't care about l10n. If they ever do care >>>>>>>>> about >>>>>>>>> >> l10n we will just need to provide a means for them to add >>>>>>>>> key/value >>>>>>>>> >> pairs to the resource bundles. >>>>>>>>> >> >>>>>>>>> >> Here is an example for anyone who needs to localize English text >>>>>>>>> >> embedded in java: >>>>>>>>> >> >>>>>>>>> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 >>>>>>>>> >> >>>>>>>>> >> Stan >>>>>>>>> >> _______________________________________________ >>>>>>>>> >> keycloak-dev mailing list >>>>>>>>> >> keycloak-dev at lists.jboss.org >>>>>>>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > _______________________________________________ >>>>>>>>> > keycloak-dev mailing list >>>>>>>>> > keycloak-dev at lists.jboss.org >>>>>>>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/6d08be79/attachment-0001.html From bburke at redhat.com Fri Oct 9 09:05:19 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 9 Oct 2015 09:05:19 -0400 Subject: [keycloak-dev] Support for SSO bridge with shared user base In-Reply-To: <56178B48.2030603@redhat.com> References: <56178B48.2030603@redhat.com> Message-ID: <5617BB8F.1090505@redhat.com> I'd rather have the appropriate SPIs be extended then have this feature native in keycloak as it seems very specific to your deployment. BTW, why not just point the SAML website to Keycloak? Keycloak supports SAML. On 10/9/2015 5:39 AM, Vlastimil Elias wrote: > Hi, > > > I'd like to implement SSO bridge between Keycloak used for our website, > and other SAML 2 based SSO server used by another website. > > Both SSO servers share common user base (user federation provider in > keycloak against same user store as the SAML SSO server). > > What I want to achieve is that once user is logged in on other SAML SSO > server and then comes to Keycloak site I'd like to login him there > automatically. > > What I can do is to configure SAML Identity Provider in Keycloak and > enable "Authenticate By Default" for it. But I think this will always > lead to user creation conflict in Keycloak as we share user base. I have > to somehow force this "SAML Identity Provider" in keycloak to directly > use existing Keycloak users instead of creating new one and linking to them. > > Is this somehow achievable in Keycloak 1.5, eg. by development of some > extension? From what I know I think it s not achievable and feature must > be coded into keycloak core. > > > And one other question ;-) > When "Authenticate By Default" is used for some Identity Provider then I > believe that Keycloak redirects user's browser to this provider in > passive mode before showing own login page to get identity from it if > any. But what happen if the provider is unreachable? In this case user > finishes with erro page and is not able to login into Keycloak at all. > Is Keycloak able to detect provider failure and stop redirecting user > there? > > Thanks in advance > > Vlastimil > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jcain at redhat.com Fri Oct 9 09:22:59 2015 From: jcain at redhat.com (Josh Cain) Date: Fri, 9 Oct 2015 09:22:59 -0400 Subject: [keycloak-dev] Support for SSO bridge with shared user base In-Reply-To: <5617BB8F.1090505@redhat.com> References: <56178B48.2030603@redhat.com> <5617BB8F.1090505@redhat.com> Message-ID: We've got a similar use case - an externally managed SAML IDP is sending users our way, and we need to map them to an existing user base. There are no attributes that we can definitively use to map our users to incoming users from the external SAML IDP. We currently allow the users to authenticate on our side on their first trip, then store an association between internal/external users. This association is used on subsequent trips so that users don't have to sign in again. We've currently got this working in Picketlink, but will need to accommodate this use case with the keycloak migration coming up in the future. To your question of pointing the SAML website to keycloak, it is a third party's IDP. Is this sort of thing really that uncommon? I'd imagine we're not the only ones without a definitive mapping attribute, or a many-one mapping. Anyway, are the SPI's currently in place, or are there some out there that would do the trick for this? Thanks in advance! Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 On Fri, Oct 9, 2015 at 9:05 AM, Bill Burke wrote: > I'd rather have the appropriate SPIs be extended then have this feature > native in keycloak as it seems very specific to your deployment. > > BTW, why not just point the SAML website to Keycloak? Keycloak supports > SAML. > > On 10/9/2015 5:39 AM, Vlastimil Elias wrote: > > Hi, > > > > > > I'd like to implement SSO bridge between Keycloak used for our website, > > and other SAML 2 based SSO server used by another website. > > > > Both SSO servers share common user base (user federation provider in > > keycloak against same user store as the SAML SSO server). > > > > What I want to achieve is that once user is logged in on other SAML SSO > > server and then comes to Keycloak site I'd like to login him there > > automatically. > > > > What I can do is to configure SAML Identity Provider in Keycloak and > > enable "Authenticate By Default" for it. But I think this will always > > lead to user creation conflict in Keycloak as we share user base. I have > > to somehow force this "SAML Identity Provider" in keycloak to directly > > use existing Keycloak users instead of creating new one and linking to > them. > > > > Is this somehow achievable in Keycloak 1.5, eg. by development of some > > extension? From what I know I think it s not achievable and feature must > > be coded into keycloak core. > > > > > > And one other question ;-) > > When "Authenticate By Default" is used for some Identity Provider then I > > believe that Keycloak redirects user's browser to this provider in > > passive mode before showing own login page to get identity from it if > > any. But what happen if the provider is unreachable? In this case user > > finishes with erro page and is not able to login into Keycloak at all. > > Is Keycloak able to detect provider failure and stop redirecting user > > there? > > > > Thanks in advance > > > > Vlastimil > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/ffb0e1ea/attachment.html From joakim.lofgren at gmail.com Fri Oct 9 10:02:41 2015 From: joakim.lofgren at gmail.com (=?UTF-8?Q?Joakim_L=C3=B6fgren?=) Date: Fri, 09 Oct 2015 14:02:41 +0000 Subject: [keycloak-dev] Realm setting for email editable? Message-ID: Hey guys, I want to duplicate the "Edit username" setting under the "Login" tab but for email. What do you think? Is it a reasonable feature to implement? Sincerely, Joakim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151009/6a451108/attachment.html From gerbermichi at me.com Sun Oct 11 11:34:42 2015 From: gerbermichi at me.com (Michael Gerber) Date: Sun, 11 Oct 2015 17:34:42 +0200 Subject: [keycloak-dev] id_token_hint In-Reply-To: References: Message-ID: <58566F50-E6E9-40DB-B005-5F523CABFEA4@me.com> I?ve created a jira task for that: https://issues.jboss.org/browse/KEYCLOAK-1949 I already did an implementation proposal of that task, what do you think of it? https://github.com/gerbermichi/keycloak/commit/0ef36f0ac446fcf70272f2aed05320c3a5083635 > On 09.10.2015, at 07:46, Michael Gerber wrote: > > As far as I understand it, we just have to create a new authenticator, check for the id_token_hint, if it is valid than we set the authenticated user, otherwise we send attempted. > > I can create a PR for that if it is that simple ;) > > Am 09. Oktober 2015 um 07:41 schrieb Stian Thorgersen : > >> It wasn't on our road map, but it looks easy to add >> >> On 9 October 2015 at 07:16, Michael Gerber > wrote: >> Hi, >> Do you have any plans to include the id_token_hint in the near future? >> id_token_hintOPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value.If the ID Token received by the RP from the OP is encrypted, to use it as an id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the id_token_hint value. >> Best >> Michael >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151011/b9a7d644/attachment.html From sthorger at redhat.com Mon Oct 12 02:19:28 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 12 Oct 2015 08:19:28 +0200 Subject: [keycloak-dev] Realm setting for email editable? In-Reply-To: References: Message-ID: I assume you want to stop users from being able to change email? On 9 October 2015 at 16:02, Joakim L?fgren wrote: > Hey guys, > > I want to duplicate the "Edit username" setting under the "Login" tab but > for email. > > What do you think? Is it a reasonable feature to implement? > > Sincerely, > Joakim > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/65404247/attachment-0001.html From sthorger at redhat.com Mon Oct 12 02:21:34 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 12 Oct 2015 08:21:34 +0200 Subject: [keycloak-dev] id_token_hint In-Reply-To: <58566F50-E6E9-40DB-B005-5F523CABFEA4@me.com> References: <58566F50-E6E9-40DB-B005-5F523CABFEA4@me.com> Message-ID: I need some time to look into the use of id_token_hint as I'm not sure I fully understand it. From what I've read so far I don't think the user should be authenticated from the id_token_hint so no authenticator should be required. It's only about checking the current logged-in user and seeing if it's the same user has the application expects. On 11 October 2015 at 17:34, Michael Gerber wrote: > I?ve created a jira task for that: > https://issues.jboss.org/browse/KEYCLOAK-1949 > > I already did an implementation proposal of that task, what do you think > of it? > > https://github.com/gerbermichi/keycloak/commit/0ef36f0ac446fcf70272f2aed05320c3a5083635 > > On 09.10.2015, at 07:46, Michael Gerber wrote: > > As far as I understand it, we just have to create a new authenticator, > check for the id_token_hint, if it is valid than we set the authenticated > user, otherwise we send attempted. > > I can create a PR for that if it is that simple ;) > > Am 09. Oktober 2015 um 07:41 schrieb Stian Thorgersen >: > > It wasn't on our road map, but it looks easy to add > > On 9 October 2015 at 07:16, Michael Gerber wrote: > >> Hi, >> Do you have any plans to include the id_token_hint in the near future? >> id_token_hintOPTIONAL. ID Token previously issued by the Authorization >> Server being passed as a hint about the End-User's current or past >> authenticated session with the Client. If the End-User identified by the ID >> Token is logged in or is logged in by the request, then the Authorization >> Server returns a positive response; otherwise, it SHOULD return an error, >> such as login_required. When possible, an id_token_hint SHOULD be >> present when prompt=none is used and an invalid_request error MAY be >> returned if it is not; however, the server SHOULD respond successfully when >> possible, even if it is not present. The Authorization Server need not be >> listed as an audience of the ID Token when it is used as an id_token_hint >> value.If the ID Token received by the RP from the OP is encrypted, to >> use it as an id_token_hint, the Client MUST decrypt the signed ID Token >> contained within the encrypted ID Token. The Client MAY re-encrypt the >> signed ID token to the Authentication Server using a key that enables the >> server to decrypt the ID Token, and use the re-encrypted ID token as the >> id_token_hint value. >> Best >> Michael >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/eae2fa75/attachment.html From joakim.lofgren at gmail.com Mon Oct 12 02:25:06 2015 From: joakim.lofgren at gmail.com (=?UTF-8?Q?Joakim_L=C3=B6fgren?=) Date: Mon, 12 Oct 2015 06:25:06 +0000 Subject: [keycloak-dev] Realm setting for email editable? In-Reply-To: References: Message-ID: Yeah, exactly. On Mon, Oct 12, 2015, 08:19 Stian Thorgersen wrote: > I assume you want to stop users from being able to change email? > > On 9 October 2015 at 16:02, Joakim L?fgren > wrote: > >> Hey guys, >> >> I want to duplicate the "Edit username" setting under the "Login" tab but >> for email. >> >> What do you think? Is it a reasonable feature to implement? >> >> Sincerely, >> Joakim >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/e6794628/attachment.html From sthorger at redhat.com Mon Oct 12 02:28:58 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 12 Oct 2015 08:28:58 +0200 Subject: [keycloak-dev] Realm setting for email editable? In-Reply-To: References: Message-ID: I don't see a problem with introducing this as long as it's editable by default On 12 October 2015 at 08:25, Joakim L?fgren wrote: > Yeah, exactly. > > On Mon, Oct 12, 2015, 08:19 Stian Thorgersen wrote: > >> I assume you want to stop users from being able to change email? >> >> On 9 October 2015 at 16:02, Joakim L?fgren >> wrote: >> >>> Hey guys, >>> >>> I want to duplicate the "Edit username" setting under the "Login" tab >>> but for email. >>> >>> What do you think? Is it a reasonable feature to implement? >>> >>> Sincerely, >>> Joakim >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/0b1b82a0/attachment.html From sthorger at redhat.com Mon Oct 12 02:29:27 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 12 Oct 2015 08:29:27 +0200 Subject: [keycloak-dev] Realm setting for email editable? In-Reply-To: References: Message-ID: If you want to create a PR you'd also need to update account management console and write a test On 12 October 2015 at 08:28, Stian Thorgersen wrote: > I don't see a problem with introducing this as long as it's editable by > default > > On 12 October 2015 at 08:25, Joakim L?fgren > wrote: > >> Yeah, exactly. >> >> On Mon, Oct 12, 2015, 08:19 Stian Thorgersen wrote: >> >>> I assume you want to stop users from being able to change email? >>> >>> On 9 October 2015 at 16:02, Joakim L?fgren >>> wrote: >>> >>>> Hey guys, >>>> >>>> I want to duplicate the "Edit username" setting under the "Login" tab >>>> but for email. >>>> >>>> What do you think? Is it a reasonable feature to implement? >>>> >>>> Sincerely, >>>> Joakim >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/fd3064fc/attachment.html From joakim.lofgren at gmail.com Mon Oct 12 02:31:19 2015 From: joakim.lofgren at gmail.com (=?UTF-8?Q?Joakim_L=C3=B6fgren?=) Date: Mon, 12 Oct 2015 06:31:19 +0000 Subject: [keycloak-dev] Realm setting for email editable? In-Reply-To: References: Message-ID: So I'll create a keycloak ticket then? On Mon, Oct 12, 2015, 08:28 Stian Thorgersen wrote: > I don't see a problem with introducing this as long as it's editable by > default > > On 12 October 2015 at 08:25, Joakim L?fgren > wrote: > >> Yeah, exactly. >> >> On Mon, Oct 12, 2015, 08:19 Stian Thorgersen wrote: >> >>> I assume you want to stop users from being able to change email? >>> >>> On 9 October 2015 at 16:02, Joakim L?fgren >>> wrote: >>> >>>> Hey guys, >>>> >>>> I want to duplicate the "Edit username" setting under the "Login" tab >>>> but for email. >>>> >>>> What do you think? Is it a reasonable feature to implement? >>>> >>>> Sincerely, >>>> Joakim >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/59771321/attachment-0001.html From sthorger at redhat.com Mon Oct 12 02:58:05 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 12 Oct 2015 08:58:05 +0200 Subject: [keycloak-dev] Realm setting for email editable? In-Reply-To: References: Message-ID: Yes, please. You could also prepare a PR if you want ;) On 12 October 2015 at 08:31, Joakim L?fgren wrote: > So I'll create a keycloak ticket then? > > On Mon, Oct 12, 2015, 08:28 Stian Thorgersen wrote: > >> I don't see a problem with introducing this as long as it's editable by >> default >> >> On 12 October 2015 at 08:25, Joakim L?fgren >> wrote: >> >>> Yeah, exactly. >>> >>> On Mon, Oct 12, 2015, 08:19 Stian Thorgersen >>> wrote: >>> >>>> I assume you want to stop users from being able to change email? >>>> >>>> On 9 October 2015 at 16:02, Joakim L?fgren >>>> wrote: >>>> >>>>> Hey guys, >>>>> >>>>> I want to duplicate the "Edit username" setting under the "Login" tab >>>>> but for email. >>>>> >>>>> What do you think? Is it a reasonable feature to implement? >>>>> >>>>> Sincerely, >>>>> Joakim >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/86ebe551/attachment.html From gerbermichi at me.com Mon Oct 12 03:10:52 2015 From: gerbermichi at me.com (Michael Gerber) Date: Mon, 12 Oct 2015 07:10:52 +0000 (GMT) Subject: [keycloak-dev] id_token_hint Message-ID: Ok, so I probably misunderstood it. I thought it's the reverse of the logout, where you can use any id token of a logged in user to log him out. Am 12. Oktober 2015 um 08:21 schrieb Stian Thorgersen : I need some time to look into the use of id_token_hint as I'm not sure I fully understand it. From what I've read so far I don't think the user should be authenticated from the id_token_hint so no authenticator should be required. It's only about checking the current logged-in user and seeing if it's the same user has the application expects. On 11 October 2015 at 17:34, Michael Gerber wrote: I?ve created a jira task for that: https://issues.jboss.org/browse/KEYCLOAK-1949 I already did an implementation proposal of that task, what do you think of it? https://github.com/gerbermichi/keycloak/commit/0ef36f0ac446fcf70272f2aed05320c3a5083635 On 09.10.2015, at 07:46, Michael Gerber wrote: As far as I understand it, we just have to create a new authenticator, check for the?id_token_hint, if it is valid than we set the authenticated user, otherwise we send attempted. I can create a PR for that if it is that simple ;) Am 09. Oktober 2015 um 07:41 schrieb Stian Thorgersen : It wasn't on our road map, but it looks easy to add On 9 October 2015 at 07:16, Michael Gerber wrote: Hi, Do you have any plans to include the id_token_hint in the near future? id_token_hintOPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as?login_required. When possible, an?id_token_hint?SHOULD be present when?prompt=none?is used and an?invalid_request?error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an?id_token_hint?value.If the ID Token received by the RP from the OP is encrypted, to use it as an?id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the?id_token_hint?value. Best Michael _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/dc86e609/attachment.html From joakim.lofgren at gmail.com Mon Oct 12 03:24:38 2015 From: joakim.lofgren at gmail.com (=?UTF-8?Q?Joakim_L=C3=B6fgren?=) Date: Mon, 12 Oct 2015 07:24:38 +0000 Subject: [keycloak-dev] Realm setting for email editable? In-Reply-To: References: Message-ID: KEYCLOAK-1950 does the ticket look alright? On Mon, Oct 12, 2015, 08:58 Stian Thorgersen wrote: > Yes, please. You could also prepare a PR if you want ;) > > On 12 October 2015 at 08:31, Joakim L?fgren > wrote: > >> So I'll create a keycloak ticket then? >> >> On Mon, Oct 12, 2015, 08:28 Stian Thorgersen wrote: >> >>> I don't see a problem with introducing this as long as it's editable by >>> default >>> >>> On 12 October 2015 at 08:25, Joakim L?fgren >>> wrote: >>> >>>> Yeah, exactly. >>>> >>>> On Mon, Oct 12, 2015, 08:19 Stian Thorgersen >>>> wrote: >>>> >>>>> I assume you want to stop users from being able to change email? >>>>> >>>>> On 9 October 2015 at 16:02, Joakim L?fgren >>>>> wrote: >>>>> >>>>>> Hey guys, >>>>>> >>>>>> I want to duplicate the "Edit username" setting under the "Login" tab >>>>>> but for email. >>>>>> >>>>>> What do you think? Is it a reasonable feature to implement? >>>>>> >>>>>> Sincerely, >>>>>> Joakim >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/38e29c9d/attachment.html From sthorger at redhat.com Mon Oct 12 03:42:15 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 12 Oct 2015 09:42:15 +0200 Subject: [keycloak-dev] Realm setting for email editable? In-Reply-To: References: Message-ID: Looks good On 12 October 2015 at 09:24, Joakim L?fgren wrote: > KEYCLOAK-1950 does the ticket look alright? > > On Mon, Oct 12, 2015, 08:58 Stian Thorgersen wrote: > >> Yes, please. You could also prepare a PR if you want ;) >> >> On 12 October 2015 at 08:31, Joakim L?fgren >> wrote: >> >>> So I'll create a keycloak ticket then? >>> >>> On Mon, Oct 12, 2015, 08:28 Stian Thorgersen >>> wrote: >>> >>>> I don't see a problem with introducing this as long as it's editable by >>>> default >>>> >>>> On 12 October 2015 at 08:25, Joakim L?fgren >>>> wrote: >>>> >>>>> Yeah, exactly. >>>>> >>>>> On Mon, Oct 12, 2015, 08:19 Stian Thorgersen >>>>> wrote: >>>>> >>>>>> I assume you want to stop users from being able to change email? >>>>>> >>>>>> On 9 October 2015 at 16:02, Joakim L?fgren >>>>>> wrote: >>>>>> >>>>>>> Hey guys, >>>>>>> >>>>>>> I want to duplicate the "Edit username" setting under the "Login" >>>>>>> tab but for email. >>>>>>> >>>>>>> What do you think? Is it a reasonable feature to implement? >>>>>>> >>>>>>> Sincerely, >>>>>>> Joakim >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>> >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/47ab631f/attachment-0001.html From velias at redhat.com Mon Oct 12 03:59:41 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 12 Oct 2015 09:59:41 +0200 Subject: [keycloak-dev] Support for SSO bridge with shared user base In-Reply-To: <5617BB8F.1090505@redhat.com> References: <56178B48.2030603@redhat.com> <5617BB8F.1090505@redhat.com> Message-ID: <561B686D.3070107@redhat.com> Hi On 9.10.2015 15:05, Bill Burke wrote: > I'd rather have the appropriate SPIs be extended then have this feature > native in keycloak as it seems very specific to your deployment. yep, I agree, but I'm not sure which SPI should be extended. It should be ideal to have some SPI responsible for reading/storing links between keycloak internal user and user from identity provider. I think methods for this are now directly part of UserStore provider. Moving these methods to separate SPI will allow storing links information independently (eg in another store or service) and also will allow implementation of special cases as is my one when usernames are same, or when eg. username off keycloak user is passed as some attribute from the identity provider. > BTW, why not just point the SAML website to Keycloak? Keycloak supports > SAML. It's not possible due organizational reasons. SAML SSO server is managed by other department and other websites have agreement with that department, not with us ;-) Thanks Vlastimil > > On 10/9/2015 5:39 AM, Vlastimil Elias wrote: >> Hi, >> >> >> I'd like to implement SSO bridge between Keycloak used for our website, >> and other SAML 2 based SSO server used by another website. >> >> Both SSO servers share common user base (user federation provider in >> keycloak against same user store as the SAML SSO server). >> >> What I want to achieve is that once user is logged in on other SAML SSO >> server and then comes to Keycloak site I'd like to login him there >> automatically. >> >> What I can do is to configure SAML Identity Provider in Keycloak and >> enable "Authenticate By Default" for it. But I think this will always >> lead to user creation conflict in Keycloak as we share user base. I have >> to somehow force this "SAML Identity Provider" in keycloak to directly >> use existing Keycloak users instead of creating new one and linking to them. >> >> Is this somehow achievable in Keycloak 1.5, eg. by development of some >> extension? From what I know I think it s not achievable and feature must >> be coded into keycloak core. >> >> >> And one other question ;-) >> When "Authenticate By Default" is used for some Identity Provider then I >> believe that Keycloak redirects user's browser to this provider in >> passive mode before showing own login page to get identity from it if >> any. But what happen if the provider is unreachable? In this case user >> finishes with erro page and is not able to login into Keycloak at all. >> Is Keycloak able to detect provider failure and stop redirecting user >> there? >> >> Thanks in advance >> >> Vlastimil >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From velias at redhat.com Mon Oct 12 04:23:10 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 12 Oct 2015 10:23:10 +0200 Subject: [keycloak-dev] Support for SSO bridge with shared user base In-Reply-To: References: <56178B48.2030603@redhat.com> <5617BB8F.1090505@redhat.com> Message-ID: <561B6DEE.80809@redhat.com> Hi Josh, On 9.10.2015 15:22, Josh Cain wrote: > We've got a similar use case - an externally managed SAML IDP is > sending users our way, and we need to map them to an existing user > base. There are no attributes that we can definitively use to map our > users to incoming users from the external SAML IDP. We currently > allow the users to authenticate on our side on their first trip, then > store an association between internal/external users. This association > is used on subsequent trips so that users don't have to sign in again. I believe Keycloak is able to do what you need (which is a bit different from wtat I need), it allows linking of external users to internal ones definitely. But there are some gotchas in user linking flows. Keycloak implementation assumes that external users are primarily new users and is trying to create new Keycloak accounts for them without any GUI interaction. But this is not very good in case when users primarily exist in the Keycloak and you can only link additional external accounts to them. There are also some problems with user conflict resolution. I created next two issues related to these problems based on our experiences: https://issues.jboss.org/browse/KEYCLOAK-1374 https://issues.jboss.org/browse/KEYCLOAK-1540 There was also some discussions about this topic on Keycloak mailing list two or three months ago and there is other issue for this topic https://issues.jboss.org/browse/KEYCLOAK-1750 Hope this topic will be resolved soon. Vlastimil > We've currently got this working in Picketlink, but will need to > accommodate this use case with the keycloak migration coming up in the > future. > > To your question of pointing the SAML website to keycloak, it is a > third party's IDP. > > Is this sort of thing really that uncommon? I'd imagine we're not the > only ones without a definitive mapping attribute, or a many-one > mapping. Anyway, are the SPI's currently in place, or are there some > out there that would do the trick for this? > > Thanks in advance! > > Josh Cain | Software Applications Engineer > /Identity and Access Management/ > *Red Hat* > +1 843-737-1735 > > > On Fri, Oct 9, 2015 at 9:05 AM, Bill Burke > wrote: > > I'd rather have the appropriate SPIs be extended then have this > feature > native in keycloak as it seems very specific to your deployment. > > BTW, why not just point the SAML website to Keycloak? Keycloak > supports > SAML. > > On 10/9/2015 5:39 AM, Vlastimil Elias wrote: > > Hi, > > > > > > I'd like to implement SSO bridge between Keycloak used for our > website, > > and other SAML 2 based SSO server used by another website. > > > > Both SSO servers share common user base (user federation provider in > > keycloak against same user store as the SAML SSO server). > > > > What I want to achieve is that once user is logged in on other > SAML SSO > > server and then comes to Keycloak site I'd like to login him there > > automatically. > > > > What I can do is to configure SAML Identity Provider in Keycloak and > > enable "Authenticate By Default" for it. But I think this will > always > > lead to user creation conflict in Keycloak as we share user > base. I have > > to somehow force this "SAML Identity Provider" in keycloak to > directly > > use existing Keycloak users instead of creating new one and > linking to them. > > > > Is this somehow achievable in Keycloak 1.5, eg. by development > of some > > extension? From what I know I think it s not achievable and > feature must > > be coded into keycloak core. > > > > > > And one other question ;-) > > When "Authenticate By Default" is used for some Identity > Provider then I > > believe that Keycloak redirects user's browser to this provider in > > passive mode before showing own login page to get identity from > it if > > any. But what happen if the provider is unreachable? In this > case user > > finishes with erro page and is not able to login into Keycloak > at all. > > Is Keycloak able to detect provider failure and stop redirecting > user > > there? > > > > Thanks in advance > > > > Vlastimil > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/72f39607/attachment.html From sthorger at redhat.com Mon Oct 12 08:48:14 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 12 Oct 2015 14:48:14 +0200 Subject: [keycloak-dev] 1.7 release Message-ID: I'm hoping to tag 1.7 on Friday and release on Monday. Are there any outstanding issues not already in JIRA? We have quite a lot of outstanding issues (~33) most of these are minor bugs. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/114155bc/attachment.html From bburke at redhat.com Mon Oct 12 09:00:55 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 12 Oct 2015 09:00:55 -0400 Subject: [keycloak-dev] 1.7 release In-Reply-To: References: Message-ID: <561BAF07.8030600@redhat.com> you mean 1.6 On 10/12/2015 8:48 AM, Stian Thorgersen wrote: > I'm hoping to tag 1.7 on Friday and release on Monday. > > Are there any outstanding issues not already in JIRA? We have quite a > lot of outstanding issues (~33) most of these are minor bugs. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From joakim.lofgren at gmail.com Mon Oct 12 09:12:11 2015 From: joakim.lofgren at gmail.com (=?UTF-8?Q?Joakim_L=C3=B6fgren?=) Date: Mon, 12 Oct 2015 13:12:11 +0000 Subject: [keycloak-dev] Missing enum for execute actions error Message-ID: I added a bug ticket KEYCLOAK-1953 Seems like a one liner right? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/0f340258/attachment.html From drieden at redhat.com Mon Oct 12 15:04:07 2015 From: drieden at redhat.com (Deborah Rieden) Date: Mon, 12 Oct 2015 15:04:07 -0400 (EDT) Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: References: <56154B92.1030804@redhat.com> <5617A3DB.80200@redhat.com> <5617A8FC.50001@redhat.com> Message-ID: <1112014579.30750358.1444676647629.JavaMail.zimbra@redhat.com> The translation team will expect the key/value pairs to be in a po file. Developers push this to Zanata. The translation is done by the globalization team in Zanata. The translated po files are then incorporated into a build. The I18N QE team takes the build which has the translated po file and does 2 things. 1. They verify that the translated string appears as expected. 2. They verify that the translation is appropriate in the context in which it is presented. Hope this helps, Debi ----- Original Message ----- > From: "Stian Thorgersen" > To: "Stian Thorgersen" > Cc: "keycloak-dev" > Sent: Friday, October 9, 2015 7:57:54 AM > Subject: Re: [keycloak-dev] i18n/l10n: English text in java code > Translation team that is > On 9 October 2015 at 13:57, Stian Thorgersen < sthorger at redhat.com > wrote: > > By the way I'm pretty sure our translation theme will take our English > > bundle > > and translate it to a language. They won't need to start/stop the server > > and > > open the admin console to check that they've translated all keys. They > > should have a tool/script for that. > > > On 9 October 2015 at 13:56, Stian Thorgersen < sthorger at redhat.com > wrote: > > > > On 9 October 2015 at 13:46, Stan Silvert < ssilvert at redhat.com > wrote: > > > > > > > On 10/9/2015 7:32 AM, Stian Thorgersen wrote: > > > > > > > > > > > #1 You're not going to catch all missing keys this way - as I said > > > > > there's > > > > > 2 > > > > > types, custom defined as well which could be missing from default > > > > > bundle > > > > > > > > > > > > > > It catches it at load time. As it loads each bundle, it checks against > > > > the > > > > previously loaded bundle. That will indeed catch all missing keys in > > > > any > > > > bundle you try to test. > > > > > > > > > > I don't know exactly what you mean by "custom defined". Somehow a > > > > third-party > > > > bundle must be merged with our default bundle. Unless I completely > > > > misunderstand, the code I wrote will still work. > > > > > > > > > New keys can be defined by using keys in client descriptions, client > > > names, > > > etc, etc.. These won't be in our message bundle, but would be in the > > > bundle > > > in a customers theme. This is why message bundles inherit from the parent > > > theme. Custom providers and themes can further introduce new keys. > > > > > > > > #2 Rendering the whole bundle useless just because you're missing one > > > > > key > > > > > is > > > > > just daft > > > > > > > > > > > > > > It is the correct thing to do. A missing key is like a null pointer. It > > > > deserves a RuntimeException. > > > > > > > > > No it's not the correct thing to do. > > > > > > > > #3 There will quite likely be separate teams that do translations to > > > > > those > > > > > that do development, which means stack traces and log output is not > > > > > the > > > > > solution > > > > > > > > > > > > > > I don't see what that has to do with anything. You start with a set of > > > > bundles containing all the correct keys. Then you translate each > > > > bundle. > > > > If > > > > you accidentally delete a key then you want to know that right away. > > > > But > > > > we > > > > should indeed ask the translation team what they want to see. > > > > > > > > > Sure, go ahead and ask them if they want to look for RuntimeExceptions in > > > the > > > server log. > > > > > > > > #4 Doing a check each time you pull a message bundle to compare with > > > > > the > > > > > base > > > > > bundle is probably not that expensive, but still pretty daft thing to > > > > > do > > > > > > > > > > > > > > You only load each bundle once. So the check only happens the first > > > > time > > > > you > > > > request the bundle. > > > > > > > > > > > #5 A proper util that's used to translate bundles is much better - we > > > > > can > > > > > implement a page in the admin console that allows you to validate a > > > > > bundle > > > > > and print out all missing bundles. This is something that would be > > > > > more > > > > > developer friendly and also would be usable by non-developers (aka > > > > > people > > > > > with other language skills than Java) > > > > > > > > > > > > > > We should ask the translation team what they want to see and how they > > > > do > > > > their work. I'm sure that they don't expect a tool to be built into the > > > > product. None of our other products have that. > > > > > > > > > I don't just care about our translation team, they will translate the > > > built > > > in keys, but they won't translate the ones introduced by users. > > > > > > > > On 9 October 2015 at 13:24, Stan Silvert < ssilvert at redhat.com > > > > > > wrote: > > > > > > > > > > > > > > > > On 10/9/2015 6:21 AM, Marko Strukelj wrote: > > > > > > > > > > > > > > > > > > > > > > And we can always log the missing key situation into server log - > > > > > > > that > > > > > > > should > > > > > > > be enough for developers to notice it, and fix it. > > > > > > > > > > > > > > > > > > > > > > > > > > > This is basically what happens with the code I wrote for the fix: > > > > > > > > > > > > > > > > > > > > > https://github.com/keycloak/keycloak/pull/1690 > > > > > > > > > > > > > > > > > > > > > You get an error in the console and then a stack trace on the > > > > > > server. > > > > > > The > > > > > > stack trace tells you exactly which key is missing. But the console > > > > > > doesn't > > > > > > crash or anything like that. You just switch back to your original > > > > > > language > > > > > > and everything works fine. > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 9, 2015 at 8:09 AM, Stian Thorgersen < > > > > > > > sthorger at redhat.com > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There's two places where keys can be missing: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * In a translation - this can be an honest mistake, or the > > > > > > > > translation > > > > > > > > wasn't > > > > > > > > updated when KC was updated > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Custom keys added - for example when keys are used for > > > > > > > > display > > > > > > > > names > > > > > > > > of > > > > > > > > clients, roles, etc.. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Manually having to go through all sorts of pages to look for > > > > > > > > missing > > > > > > > > keys > > > > > > > > is > > > > > > > > very error prone and time consuming, so will not be the best > > > > > > > > option > > > > > > > > for > > > > > > > > developers. In both cases above the correct way to do this > > > > > > > > would > > > > > > > > be > > > > > > > > to > > > > > > > > have > > > > > > > > a way to verify a message bundle. We need a tool that can > > > > > > > > quickly > > > > > > > > identify > > > > > > > > if there are missing keys and we could expose that through the > > > > > > > > admin > > > > > > > > console. We currently have a student looking at providing a UI > > > > > > > > for > > > > > > > > defining > > > > > > > > locales and she is also going to look at adding some way of > > > > > > > > identifying > > > > > > > > if > > > > > > > > a > > > > > > > > locale is missing keys and also to easily list only missing > > > > > > > > keys. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For end users as I've said they will have no clue what > > > > > > > > ???key??? > > > > > > > > is, > > > > > > > > and > > > > > > > > even > > > > > > > > worse if we throw an exception/error just because a missing key > > > > > > > > we'll > > > > > > > > actually break the whole console just because of a missing key. > > > > > > > > It's > > > > > > > > a > > > > > > > > much > > > > > > > > better option to look for the key in another translation and > > > > > > > > display > > > > > > > > that. > > > > > > > > Chances are they will be able to interpret one or two English > > > > > > > > words. > > > > > > > > Certainly higher chance of that then them being able to > > > > > > > > interpret > > > > > > > > ???key???. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9 October 2015 at 07:51, Thomas Raehalme < > > > > > > > > thomas.raehalme at aitiofinland.com > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > How about returning something noticeable like ???key??? for > > > > > > > > > example? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Oct 9, 2015 8:10 AM, "Stian Thorgersen" < > > > > > > > > > sthorger at redhat.com > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That's not putting it to rest at all! Throwing a > > > > > > > > > > RuntimeException > > > > > > > > > > and > > > > > > > > > > rendering the whole admin console useless just because > > > > > > > > > > there's > > > > > > > > > > a > > > > > > > > > > missing > > > > > > > > > > key > > > > > > > > > > is a horrible idea. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8 October 2015 at 20:33, Stan Silvert < > > > > > > > > > > ssilvert at redhat.com > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What if English is the bundle that has a missing key? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Let's just put this to rest and solve it once and for > > > > > > > > > > > all. > > > > > > > > > > > The > > > > > > > > > > > simplest > > > > > > > > > > > solution I can think of is to just compare keys when a > > > > > > > > > > > new > > > > > > > > > > > bundle > > > > > > > > > > > is > > > > > > > > > > > loaded. > > > > > > > > > > > If any bundle has a missing key or it has key not found > > > > > > > > > > > in > > > > > > > > > > > the > > > > > > > > > > > previous > > > > > > > > > > > loaded bundle, we throw a RuntimeException. I can submit > > > > > > > > > > > a > > > > > > > > > > > patch > > > > > > > > > > > for > > > > > > > > > > > that > > > > > > > > > > > in > > > > > > > > > > > just a few minutes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/8/2015 1:28 PM, Stian Thorgersen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not sure I'm buying into the argument that > > > > > > > > > > > > displaying > > > > > > > > > > > > the > > > > > > > > > > > > key > > > > > > > > > > > > is > > > > > > > > > > > > better > > > > > > > > > > > > for developers. Having English suddenly pop-up in a > > > > > > > > > > > > German > > > > > > > > > > > > translation > > > > > > > > > > > > is > > > > > > > > > > > > just as obvious as a key. Besides as Stan points out > > > > > > > > > > > > you > > > > > > > > > > > > catch > > > > > > > > > > > > missing > > > > > > > > > > > > keys > > > > > > > > > > > > by comparing missing keys between English and German. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, if there is a mistake in a translation then a > > > > > > > > > > > > user > > > > > > > > > > > > may > > > > > > > > > > > > quite > > > > > > > > > > > > likely > > > > > > > > > > > > be able to interpret English text, while a user will > > > > > > > > > > > > not > > > > > > > > > > > > be > > > > > > > > > > > > able > > > > > > > > > > > > to > > > > > > > > > > > > interpret a key. So if a key is missing in a > > > > > > > > > > > > translation > > > > > > > > > > > > (which > > > > > > > > > > > > is > > > > > > > > > > > > obviously > > > > > > > > > > > > a "bug") it's better to display English than to display > > > > > > > > > > > > the > > > > > > > > > > > > key. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 8 October 2015 at 14:13, Stan Silvert < > > > > > > > > > > > > ssilvert at redhat.com > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/8/2015 12:48 AM, Thomas Raehalme wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Oct 8, 2015 6:53 AM, "Stian Thorgersen" < > > > > > > > > > > > > > > sthorger at redhat.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With regards to internationalization I have two > > > > > > > > > > > > > > > questions: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Should we fallback to English messages if a key > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > missing > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > translation? Alternative is to show key, but > > > > > > > > > > > > > > > that's > > > > > > > > > > > > > > > not > > > > > > > > > > > > > > > going > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > help > > > > > > > > > > > > > > > anyone > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A missing key is a bug and showing the message in > > > > > > > > > > > > > > the > > > > > > > > > > > > > > default > > > > > > > > > > > > > > locale > > > > > > > > > > > > > > may > > > > > > > > > > > > > > hide > > > > > > > > > > > > > > the problem. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Even though showing the key does not help the end > > > > > > > > > > > > > > user > > > > > > > > > > > > > > it > > > > > > > > > > > > > > helps > > > > > > > > > > > > > > the > > > > > > > > > > > > > > developer > > > > > > > > > > > > > > and identifies the problem. For this reason I think > > > > > > > > > > > > > > showing > > > > > > > > > > > > > > the > > > > > > > > > > > > > > key > > > > > > > > > > > > > > would > > > > > > > > > > > > > > be > > > > > > > > > > > > > > a good idea. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For our bundles, we could catch missing keys at build > > > > > > > > > > > > > time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Failing that, I agree that displaying the key is > > > > > > > > > > > > > better > > > > > > > > > > > > > than > > > > > > > > > > > > > falling > > > > > > > > > > > > > back > > > > > > > > > > > > > to > > > > > > > > > > > > > English. This is especially true right now while we > > > > > > > > > > > > > haven't > > > > > > > > > > > > > completed > > > > > > > > > > > > > the > > > > > > > > > > > > > task of converting everything. If we fall back to > > > > > > > > > > > > > English > > > > > > > > > > > > > we > > > > > > > > > > > > > won't > > > > > > > > > > > > > know > > > > > > > > > > > > > if > > > > > > > > > > > > > the problem is a missing key or if the text just > > > > > > > > > > > > > hasn't > > > > > > > > > > > > > been > > > > > > > > > > > > > converted > > > > > > > > > > > > > yet. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Should we change message bundles to UTF-8? Or > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > ISO > > > > > > > > > > > > > > > 8859-1 > > > > > > > > > > > > > > > going > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > work > > > > > > > > > > > > > > > for all languages? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Depends what those all languages are :-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think UTF-8 is the best choice as it will handle > > > > > > > > > > > > > > practically > > > > > > > > > > > > > > any > > > > > > > > > > > > > > character. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But if you're referring to Java resource bundles > > > > > > > > > > > > > > the > > > > > > > > > > > > > > encoding > > > > > > > > > > > > > > for > > > > > > > > > > > > > > .properties > > > > > > > > > > > > > > is ISO-8859-1 but there are means to handle any > > > > > > > > > > > > > > UTF-8 > > > > > > > > > > > > > > character. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, an UTF-8 character can be encoded in ISO-8859-1. > > > > > > > > > > > > > Java > > > > > > > > > > > > > provides > > > > > > > > > > > > > a > > > > > > > > > > > > > native2ascii tool for converting entire files. The > > > > > > > > > > > > > resource > > > > > > > > > > > > > bundle > > > > > > > > > > > > > tools > > > > > > > > > > > > > in > > > > > > > > > > > > > most IDE's do this for you automatically. So you just > > > > > > > > > > > > > edit > > > > > > > > > > > > > as > > > > > > > > > > > > > UTF-8 > > > > > > > > > > > > > and > > > > > > > > > > > > > it > > > > > > > > > > > > > saves the bundle as ISO-8859-1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We can read our bundles as UTF-8 if we want to do > > > > > > > > > > > > > that. > > > > > > > > > > > > > I'd > > > > > > > > > > > > > rather > > > > > > > > > > > > > not, > > > > > > > > > > > > > because I'm not sure what we might run into down the > > > > > > > > > > > > > road > > > > > > > > > > > > > with > > > > > > > > > > > > > Java > > > > > > > > > > > > > assuming > > > > > > > > > > > > > resource bundles are always ISO-8859-1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But I'd like to get the perspective of people who > > > > > > > > > > > > > have > > > > > > > > > > > > > handled > > > > > > > > > > > > > resource > > > > > > > > > > > > > bundles in languages that are not fully supported by > > > > > > > > > > > > > ISO-8859-1. > > > > > > > > > > > > > Is > > > > > > > > > > > > > it > > > > > > > > > > > > > too > > > > > > > > > > > > > much of a pain to do a conversion or do the tools > > > > > > > > > > > > > make > > > > > > > > > > > > > the > > > > > > > > > > > > > process > > > > > > > > > > > > > seamless? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 7 October 2015 at 18:42, Stan Silvert < > > > > > > > > > > > > > > > ssilvert at redhat.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Marko brought this to my attention yesterday. > > > > > > > > > > > > > > >> For > > > > > > > > > > > > > > >> some > > > > > > > > > > > > > > >> things, > > > > > > > > > > > > > > >> we > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> dynamically create UI. In this case, the java > > > > > > > > > > > > > > >> code > > > > > > > > > > > > > > >> contains > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > >> English > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> text and it needs to be localized. Luckily, the > > > > > > > > > > > > > > >> solution > > > > > > > > > > > > > > >> was > > > > > > > > > > > > > > >> pretty > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> straightforward. We just replace the English > > > > > > > > > > > > > > >> text > > > > > > > > > > > > > > >> with > > > > > > > > > > > > > > >> a > > > > > > > > > > > > > > >> key > > > > > > > > > > > > > > >> into > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> message bundle. The html template that displays > > > > > > > > > > > > > > >> this > > > > > > > > > > > > > > >> text > > > > > > > > > > > > > > >> already > > > > > > > > > > > > > > >> pulls > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> from an Angular scope so we just leave that > > > > > > > > > > > > > > >> alone > > > > > > > > > > > > > > >> and > > > > > > > > > > > > > > >> pass > > > > > > > > > > > > > > >> it > > > > > > > > > > > > > > >> through > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> the |translate filter. You do need to also add > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > >> double-colon. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> One nice side effect is that if the key is not > > > > > > > > > > > > > > >> found > > > > > > > > > > > > > > >> in > > > > > > > > > > > > > > >> the > > > > > > > > > > > > > > >> bundle > > > > > > > > > > > > > > >> then > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> the output of the translate filter is the > > > > > > > > > > > > > > >> unchanged > > > > > > > > > > > > > > >> text. > > > > > > > > > > > > > > >> This > > > > > > > > > > > > > > >> means > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> that any code which has not converted to using > > > > > > > > > > > > > > >> bundle > > > > > > > > > > > > > > >> keys > > > > > > > > > > > > > > >> will > > > > > > > > > > > > > > >> still > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> work as expected. And, any third-party providers > > > > > > > > > > > > > > >> can > > > > > > > > > > > > > > >> just > > > > > > > > > > > > > > >> pass > > > > > > > > > > > > > > >> in > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> plain text if they don't care about l10n. If > > > > > > > > > > > > > > >> they > > > > > > > > > > > > > > >> ever > > > > > > > > > > > > > > >> do > > > > > > > > > > > > > > >> care > > > > > > > > > > > > > > >> about > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> l10n we will just need to provide a means for > > > > > > > > > > > > > > >> them > > > > > > > > > > > > > > >> to > > > > > > > > > > > > > > >> add > > > > > > > > > > > > > > >> key/value > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> pairs to the resource bundles. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Here is an example for anyone who needs to > > > > > > > > > > > > > > >> localize > > > > > > > > > > > > > > >> English > > > > > > > > > > > > > > >> text > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> embedded in java: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> Stan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> keycloak-dev mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> keycloak-dev at lists.jboss.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > > > > > > > > keycloak-dev mailing list keycloak-dev at lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org > > > > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Debi Rieden Program Manager for JBoss Data Virtualization and JBoss Identity (Keycloak) Westford (3S391) http://westford-map.itos.redhat.com/index.html#3S391 Office: 978-392-1023; Cell 617-669-2934 drieden at redhat.com #program, #boston -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/d7e688a2/attachment-0001.html From ssilvert at redhat.com Mon Oct 12 15:35:16 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 12 Oct 2015 15:35:16 -0400 Subject: [keycloak-dev] i18n/l10n: English text in java code In-Reply-To: <1112014579.30750358.1444676647629.JavaMail.zimbra@redhat.com> References: <56154B92.1030804@redhat.com> <5617A3DB.80200@redhat.com> <5617A8FC.50001@redhat.com> <1112014579.30750358.1444676647629.JavaMail.zimbra@redhat.com> Message-ID: <561C0B74.90901@redhat.com> Thanks for the clarification Debi. Like most Java applications, properties files are used for the key/value pairs. Can your team handle those? Stan On 10/12/2015 3:04 PM, Deborah Rieden wrote: > The translation team will expect the key/value pairs to be in a po file. > Developers push this to Zanata. > The translation is done by the globalization team in Zanata. > The translated po files are then incorporated into a build. > > The I18N QE team takes the build which has the translated po file and > does 2 things. > 1. They verify that the translated string appears as expected. > 2. They verify that the translation is appropriate in the context in > which it is presented. > > Hope this helps, > Debi > > > > ------------------------------------------------------------------------ > > *From: *"Stian Thorgersen" > *To: *"Stian Thorgersen" > *Cc: *"keycloak-dev" > *Sent: *Friday, October 9, 2015 7:57:54 AM > *Subject: *Re: [keycloak-dev] i18n/l10n: English text in java code > > Translation team that is > > On 9 October 2015 at 13:57, Stian Thorgersen > wrote: > > By the way I'm pretty sure our translation theme will take our > English bundle and translate it to a language. They won't need > to start/stop the server and open the admin console to check > that they've translated all keys. They should have a > tool/script for that. > > On 9 October 2015 at 13:56, Stian Thorgersen > > wrote: > > > > On 9 October 2015 at 13:46, Stan Silvert > > wrote: > > On 10/9/2015 7:32 AM, Stian Thorgersen wrote: > > #1 You're not going to catch all missing keys this > way - as I said there's 2 types, custom defined as > well which could be missing from default bundle > > It catches it at load time. As it loads each bundle, > it checks against the previously loaded bundle. That > will indeed catch all missing keys in any bundle you > try to test. > > I don't know exactly what you mean by "custom > defined". Somehow a third-party bundle must be merged > with our default bundle. Unless I completely > misunderstand, the code I wrote will still work. > > > New keys can be defined by using keys in client > descriptions, client names, etc, etc.. These won't be in > our message bundle, but would be in the bundle in a > customers theme. This is why message bundles inherit from > the parent theme. Custom providers and themes can further > introduce new keys. > > > #2 Rendering the whole bundle useless just because > you're missing one key is just daft > > It is the correct thing to do. A missing key is like > a null pointer. It deserves a RuntimeException. > > > No it's not the correct thing to do. > > > #3 There will quite likely be separate teams that > do translations to those that do development, > which means stack traces and log output is not the > solution > > I don't see what that has to do with anything. You > start with a set of bundles containing all the correct > keys. Then you translate each bundle. If you > accidentally delete a key then you want to know that > right away. But we should indeed ask the translation > team what they want to see. > > > Sure, go ahead and ask them if they want to look for > RuntimeExceptions in the server log. > > > #4 Doing a check each time you pull a message > bundle to compare with the base bundle is probably > not that expensive, but still pretty daft thing to do > > You only load each bundle once. So the check only > happens the first time you request the bundle. > > #5 A proper util that's used to translate bundles > is much better - we can implement a page in the > admin console that allows you to validate a bundle > and print out all missing bundles. This is > something that would be more developer friendly > and also would be usable by non-developers (aka > people with other language skills than Java) > > We should ask the translation team what they want to > see and how they do their work. I'm sure that they > don't expect a tool to be built into the product. > None of our other products have that. > > > I don't just care about our translation team, they will > translate the built in keys, but they won't translate the > ones introduced by users. > > > > > On 9 October 2015 at 13:24, Stan Silvert > > > wrote: > > On 10/9/2015 6:21 AM, Marko Strukelj wrote: > > And we can always log the missing key > situation into server log - that should be > enough for developers to notice it, and > fix it. > > This is basically what happens with the code I > wrote for the fix: > https://github.com/keycloak/keycloak/pull/1690 > > You get an error in the console and then a > stack trace on the server. The stack trace > tells you exactly which key is missing. But > the console doesn't crash or anything like > that. You just switch back to your original > language and everything works fine. > > > On Fri, Oct 9, 2015 at 8:09 AM, Stian > Thorgersen > wrote: > > There's two places where keys can be > missing: > > * In a translation - this can be an > honest mistake, or the translation > wasn't updated when KC was updated > * Custom keys added - for example when > keys are used for display names of > clients, roles, etc.. > > Manually having to go through all > sorts of pages to look for missing > keys is very error prone and time > consuming, so will not be the best > option for developers. In both cases > above the correct way to do this would > be to have a way to verify a message > bundle. We need a tool that can > quickly identify if there are missing > keys and we could expose that through > the admin console. We currently have a > student looking at providing a UI for > defining locales and she is also going > to look at adding some way of > identifying if a locale is missing > keys and also to easily list only > missing keys. > > For end users as I've said they will > have no clue what ???key??? is, and > even worse if we throw an > exception/error just because a missing > key we'll actually break the whole > console just because of a missing key. > It's a much better option to look for > the key in another translation and > display that. Chances are they will be > able to interpret one or two English > words. Certainly higher chance of that > then them being able to interpret > ???key???. > > > On 9 October 2015 at 07:51, Thomas > Raehalme > > > wrote: > > How about returning something > noticeable like ???key??? for example? > > On Oct 9, 2015 8:10 AM, "Stian > Thorgersen" > wrote: > > That's not putting it to rest > at all! Throwing a > RuntimeException and rendering > the whole admin console > useless just because there's a > missing key is a horrible idea. > > On 8 October 2015 at 20:33, > Stan Silvert > > > wrote: > > What if English is the > bundle that has a missing key? > > Let's just put this to > rest and solve it once and > for all. The simplest > solution I can think of is > to just compare keys when > a new bundle is loaded. > If any bundle has a > missing key or it has key > not found in the previous > loaded bundle, we throw a > RuntimeException. I can > submit a patch for that in > just a few minutes. > > > On 10/8/2015 1:28 PM, > Stian Thorgersen wrote: > > I'm not sure I'm > buying into the > argument that > displaying the key is > better for developers. > Having English > suddenly pop-up in a > German translation is > just as obvious as a > key. Besides as Stan > points out you catch > missing keys by > comparing missing keys > between English and > German. > > However, if there is a > mistake in a > translation then a > user may quite likely > be able to interpret > English text, while a > user will not be able > to interpret a key. So > if a key is missing in > a translation (which > is obviously a "bug") > it's better to display > English than to > display the key. > > On 8 October 2015 at > 14:13, Stan Silvert > > > wrote: > > On 10/8/2015 12:48 > AM, Thomas > Raehalme wrote: > > > On Oct 8, 2015 > 6:53 AM, > "Stian > Thorgersen" > > > wrote: > > > > With regards > to > internationalization > I have two > questions: > > > > * Should we > fallback to > English > messages if a > key is missing > in a > translation? > Alternative is > to show key, > but that's not > going to help > anyone > > A missing key > is a bug and > showing the > message in the > default locale > may hide the > problem. > > Even though > showing the > key does not > help the end > user it helps > the developer > and identifies > the problem. > For this > reason I think > showing the > key would be a > good idea. > > For our bundles, > we could catch > missing keys at > build time. > > Failing that, I > agree that > displaying the key > is better than > falling back to > English. This is > especially true > right now while we > haven't completed > the task of > converting > everything. If we > fall back to > English we won't > know if the > problem is a > missing key or if > the text just > hasn't been > converted yet. > > > * Should we > change message > bundles to > UTF-8? Or > is ISO 8859-1 > going to work > for all languages? > > Depends what > those all > languages are :-) > > I think UTF-8 > is the best > choice as it > will handle > practically > any character. > > But if you're > referring to > Java resource > bundles the > encoding for > .properties is > ISO-8859-1 but > there are > means to > handle any > UTF-8 character. > > Yes, an UTF-8 > character can be > encoded in > ISO-8859-1. Java > provides a > native2ascii tool > for converting > entire files. The > resource bundle > tools in most > IDE's do this for > you automatically. > So you just edit > as UTF-8 and it > saves the bundle > as ISO-8859-1. > > We can read our > bundles as UTF-8 > if we want to do > that. I'd rather > not, because I'm > not sure what we > might run into > down the road with > Java assuming > resource bundles > are always ISO-8859-1. > > But I'd like to > get the > perspective of > people who have > handled resource > bundles in > languages that are > not fully > supported by > ISO-8859-1. Is it > too much of a pain > to do a conversion > or do the tools > make the process > seamless? > > Best regards, > Thomas > > > > > On 7 October > 2015 at 18:42, > Stan Silvert > > > wrote: > >> > >> Marko > brought this > to my > attention > yesterday. For > some things, we > >> dynamically > create UI. In > this case, the > java code > contains the > English > >> text and it > needs to be > localized. > Luckily, the > solution was > pretty > >> > straightforward. > We just > replace the > English text > with a key > into the > >> message > bundle. The > html template > that displays > this text > already pulls > >> from an > Angular scope > so we just > leave that > alone and pass > it through > >> the > |translate > filter. You > do need to > also add the > double-colon. > >> > >> One nice > side effect is > that if the > key is not > found in the > bundle then > >> the output > of the > translate > filter is the > unchanged > text. This means > >> that any > code which has > not converted > to using > bundle keys > will still > >> work as > expected. > And, any > third-party > providers can > just pass in > >> plain text > if they don't > care about > l10n. If they > ever do care about > >> l10n we > will just need > to provide a > means for them > to add key/value > >> pairs to > the resource > bundles. > >> > >> Here is an > example for > anyone who > needs to > localize > English text > >> embedded in > java: > >> > https://github.com/ssilvert/keycloak/commit/c9437595b70810c4472325373dd8833c37be8549 > >> > >> Stan > >> > _______________________________________________ > >> > keycloak-dev > mailing list > >> > keycloak-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > _______________________________________________ > > keycloak-dev > mailing list > > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > Debi Rieden > > Program Manager for JBoss Data Virtualization and JBoss Identity > (Keycloak) > > Westford (3S391) http://westford-map.itos.redhat.com/index.html#3S391 > Office: 978-392-1023; Cell 617-669-2934 > drieden at redhat.com > #program, #boston > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151012/0aaf9e43/attachment-0001.html From j.kamal at ymail.com Mon Oct 12 20:26:01 2015 From: j.kamal at ymail.com (Kamal Jagadevan) Date: Tue, 13 Oct 2015 00:26:01 +0000 (UTC) Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: References: Message-ID: <1774067821.2822207.1444695961101.JavaMail.yahoo@mail.yahoo.com> Hi Stian/Marek,? Thanks for your attention in the matter.Probably you are referring to one other issue in client level, but Mike & I are referring at User level within or across client. User John Doe authenticates with his credentials and obtains token pair A1R1 - After A1 expires, app refreshes the token pair to A2R2 USING R1 - After A2 expires, app refreshes the token pair to A3R3 USING R1 (ideally it is should use R2 as it is the latest refresh token) ???? In order to achieve this functionality, I was wondering why can't we use existing last refresh time from User session rather then checking it in the client session.IMHO, adding one more validation in the ValidateToken method in TokenManager class like this should resolve the problem. ??????? // after userSession is determined either for offline token or online token... ??????? if(oldToken.getIssuedAt() < userSession.getLastSessionRefresh()) { ??????? ??? throw new OAuthErrorException(OAuthErrorException.INVALID_GRANT, "Stale refresh token - already used"); ??????? } Please let me know if you see any pitfalls other than the backward compatibility for existing keycloak users. I can work with you to merge this change & test it in the master. BestKamal From: Stian Thorgersen To: Marek Posolda Cc: "Jagadevan, Kamal" ; "keycloak-dev at lists.jboss.org" Sent: Wednesday, October 7, 2015 8:38 AM Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token You're right, we'd have to introduce a lastRefresh on ClientSession On 7 October 2015 at 14:35, Marek Posolda wrote: On 07/10/15 14:23, Stian Thorgersen wrote: We should make this configurable. For those worried about security they can enforce new refresh tokens as well as offline tokens will replace the old tokens. It would be fairly simply to implement. If enabled we would only allow refresh token where iat is >= the last session refresh time. I was also thinking about this possibility. However if you have 2 clients and you refresh the token for client1, the refresh token of client2 won't be valid as his "iat" will be older. Also SSO login currently refreshes lastSessionRefresh on UserSession. However maybe we can introduce lastSessionRefresh to ClientSession as well? Marek I wouldn't make it default behavior for two reasons: * It would break existing clients if they expect to continue using the old refresh token * It comes at a performance cost as clients will have to store the new refresh tokens and offline tokens each time they refresh the token * For offline tokens Keycloak would also have to persist the last refresh time each time the offline token is refreshed I think we'd need to make it a realm wide configuration option. On 7 October 2015 at 14:12, Marek Posolda wrote: The points are valid and security can be always improved, however sometimes improving security makes things complicated with the not-so-big advantage... IMO admin should always protect the machine to make sure that nobody unauthorized has access to refresh tokens. And for the transport, HTTPS should be always used. But feel free to create JIRA and we will see... When user or client is deleted, all refresh/offline tokens will defacto become invalid as well and can't be used anymore. You're right that offline token is still valid after user logout. User can revoke it manually in account management or admin can revoke it in admin console. However refresh token is invalid after user logout. All refresh/offline tokens for particular client can be revoked by admin by set notBefore policy to now, which can be done in admin console in "Revocation" tab of particular client. Marek On 07/10/15 04:27, Raghuram Prabhala wrote: Very valid points Mike and even I have similar concerns. But please do understand that even if the refresh token is stolen or compromised,it cannot be used by any client unless both the client_id and client_secret are also compromised/stolen. But nevertheless, it is a good practice to assume the worst and add in protective measures to minimize the chances.? Marek/Bill/Stian - Even our organization is very particular that such potential security issues be addressed. Can this be taken up? BTW I am not sure if you have an API/End point to invalidate tokens for those that are either compromised or must be invalidated as either the user or client is no longer active. If you do not have one then it is a good idea to make one available. Thanks, Raghu From: "Kuznetsov, Mike" To: "keycloak-dev at lists.jboss.org" Cc: "Jagadevan, Kamal" Sent: Tuesday, October 6, 2015 4:34 PM Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token Hello, ? The reason I brought this up is that we are currently working on migrating out authentication from a commercially available product called Ping to Keycloak. We noticed that Ping invalidates the refresh token after it is used once, while Keycloak does not. ? I and my colleague, Kamal are concerned that by not invalidating the refresh token after first use, we may be opening a security hole. While SSL may protect the token in transit, we can see a scenario where the refresh token would be compromised or stolen from the client itself. In this case, the stolen refresh token could be used to get new access tokens without the owner of the client machine knowing. ? However, if the behavior was changed so that the refresh token could only be used once, then either: 1.?????? If the owner of the client machine would use the refresh token first, then the stolen refresh token could not be used 2.?????? If the stolen refresh token would be used first, then the client machine would not be able to use it and the user of that client machine could be alerted that something was wrong. This user could then reset their password or invalidate all of their access and refresh tokens. ? Furthermore, we are concerned about this same scenario, but with the offline token. My understanding is that the offline token does not expire and that it can?t be invalidated by logging out the user or changing the user?s password. Have you thought about this scenario? ? Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise ? From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Tuesday, October 06, 2015 1:16 PM To: Raghu Prabhala Cc: Kuznetsov, Mike; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token ? Hi Raghu, >From the specs, it looks to me that this is not anything mandatory. The paragraph is starting "For example". Feel free to create JIRA, but I personally can't promise anything regarding this... Marek On 06/10/15 17:37, Raghu Prabhala wrote: Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh token should be invalidated but retained by the server - to handle compromise of refresh tokens as they are long lived.? ? Thanks, Raghu Sent from my iPhone On Oct 6, 2015, at 10:53 AM, Marek Posolda wrote: You're right, same refresh token can be used more times. However it is still better to use refresh token R2 in your step 3 instead of using old refresh token R1 because R2 has updated timestamp (each token is valid just for 30 minutes or so, depends on the configured SSO session idle timeout). Or are you referring that this is security issue and potential possibility to Man in the middle? If you use HTTPS (which is recommended for production environment, and especially if you have unsecured/untrusted networkl), this shouldn't be an issue. Marek On 06/10/15 16:34, Kuznetsov, Mike wrote: Hello, ? I noticed that with Keycloak, it seems that refresh tokens are still valid after they are used once. This means that Keycloak does not invalidate Refresh Tokens after they have been used once. ? I am able to successfully execute the following flow: 1.?????? Obtain Access Token (A1) and Refresh Token (R1) 2.?????? Use Refresh Token (R1) to obtain new Access Token (A2) and Refresh Token (R2) 3.?????? Use same Refresh Token (R1) again to obtain new Access Token (A3) and Refresh Token (R3) ? ? Can you please tell me if this is the intended functionality? ? Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise ? _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev ? _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev ? _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151013/592806f7/attachment-0001.html From sthorger at redhat.com Tue Oct 13 00:12:03 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Oct 2015 06:12:03 +0200 Subject: [keycloak-dev] 1.7 release In-Reply-To: <561BAF07.8030600@redhat.com> References: <561BAF07.8030600@redhat.com> Message-ID: Yep On 12 October 2015 at 15:00, Bill Burke wrote: > you mean 1.6 > > On 10/12/2015 8:48 AM, Stian Thorgersen wrote: > > I'm hoping to tag 1.7 on Friday and release on Monday. > > > > Are there any outstanding issues not already in JIRA? We have quite a > > lot of outstanding issues (~33) most of these are minor bugs. > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151013/02990e37/attachment.html From sthorger at redhat.com Tue Oct 13 00:42:49 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Oct 2015 06:42:49 +0200 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <1774067821.2822207.1444695961101.JavaMail.yahoo@mail.yahoo.com> References: <1774067821.2822207.1444695961101.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi Kamal, Each client gets their own token and they refresh the tokens independently. Last session refresh in the user session is the last time any clients in that user session refreshed the token. It's used to know if a users session is active or not and we don't care what client it was the user used. With regards to refresh tokens we need to expire/invalidate the last refresh for a specific client session within the user session. So we would need a note on each client session when they refreshed last. If we did what you proposed it would basically break SSO and only one client would be able to maintain a working session. On 13 October 2015 at 02:26, Kamal Jagadevan wrote: > Hi Stian/Marek, > Thanks for your attention in the matter. > Probably you are referring to one other issue in client level, but Mike & > I are referring at User level within or across client. > > User John Doe authenticates with his credentials and obtains token pair > *A1R1* > > 1. After A1 expires, app refreshes the token pair to *A2R2 *USING R1 > 2. After A2 expires, app refreshes the token pair to *A3R3 **USING R1* (ideally > it is should use R2 as it is the latest refresh token) > > > In order to achieve this functionality, I was wondering why can't we use > existing last refresh time from User session rather then checking it in the > client session. > IMHO, adding one more validation in the ValidateToken method in > TokenManager class like this should resolve the problem. > > // after userSession is determined either for offline token or > online token... > if(oldToken.getIssuedAt() < userSession.getLastSessionRefresh()) { > throw new > OAuthErrorException(OAuthErrorException.INVALID_GRANT, "Stale refresh token > - already used"); > } > > > Please let me know if you see any pitfalls other than the backward > compatibility for existing keycloak users. I can work with you to merge > this change & test it in the master. > > Best > Kamal > > > ------------------------------ > *From:* Stian Thorgersen > *To:* Marek Posolda > *Cc:* "Jagadevan, Kamal" ; " > keycloak-dev at lists.jboss.org" > *Sent:* Wednesday, October 7, 2015 8:38 AM > > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > You're right, we'd have to introduce a lastRefresh on ClientSession > > > > On 7 October 2015 at 14:35, Marek Posolda wrote: > > On 07/10/15 14:23, Stian Thorgersen wrote: > > We should make this configurable. For those worried about security they > can enforce new refresh tokens as well as offline tokens will replace the > old tokens. It would be fairly simply to implement. If enabled we would > only allow refresh token where iat is >= the last session refresh time. > > I was also thinking about this possibility. However if you have 2 clients > and you refresh the token for client1, the refresh token of client2 won't > be valid as his "iat" will be older. Also SSO login currently refreshes > lastSessionRefresh on UserSession. However maybe we can introduce > lastSessionRefresh to ClientSession as well? > > Marek > > I wouldn't make it default behavior for two reasons: > > * It would break existing clients if they expect to continue using the old > refresh token > * It comes at a performance cost as clients will have to store the new > refresh tokens and offline tokens each time they refresh the token > * For offline tokens Keycloak would also have to persist the last refresh > time each time the offline token is refreshed > > I think we'd need to make it a realm wide configuration option. > > On 7 October 2015 at 14:12, Marek Posolda wrote: > > The points are valid and security can be always improved, however > sometimes improving security makes things complicated with the not-so-big > advantage... IMO admin should always protect the machine to make sure that > nobody unauthorized has access to refresh tokens. And for the transport, > HTTPS should be always used. But feel free to create JIRA and we will see... > > When user or client is deleted, all refresh/offline tokens will defacto > become invalid as well and can't be used anymore. You're right that offline > token is still valid after user logout. User can revoke it manually in > account management or admin can revoke it in admin console. However refresh > token is invalid after user logout. All refresh/offline tokens for > particular client can be revoked by admin by set notBefore policy to now, > which can be done in admin console in "Revocation" tab of particular client. > > Marek > > > On 07/10/15 04:27, Raghuram Prabhala wrote: > > Very valid points Mike and even I have similar concerns. But please do > understand that even if the refresh token is stolen or compromised,it > cannot be used by any client unless both the client_id and client_secret > are also compromised/stolen. But nevertheless, it is a good practice to > assume the worst and add in protective measures to minimize the chances. > > Marek/Bill/Stian - Even our organization is very particular that such > potential security issues be addressed. Can this be taken up? BTW I am not > sure if you have an API/End point to invalidate tokens for those that are > either compromised or must be invalidated as either the user or client is > no longer active. If you do not have one then it is a good idea to make one > available. > > Thanks, > Raghu > > ------------------------------ > *From:* "Kuznetsov, Mike" > > *To:* "keycloak-dev at lists.jboss.org" > > *Cc:* "Jagadevan, Kamal" > > *Sent:* Tuesday, October 6, 2015 4:34 PM > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > Hello, > > The reason I brought this up is that we are currently working on migrating > out authentication from a commercially available product called Ping to > Keycloak. We noticed that Ping invalidates the refresh token after it is > used once, while Keycloak does not. > > I and my colleague, Kamal are concerned that by not invalidating the > refresh token after first use, we may be opening a security hole. While SSL > may protect the token in transit, we can see a scenario where the refresh > token would be compromised or stolen from the client itself. In this case, > the stolen refresh token could be used to get new access tokens without the > owner of the client machine knowing. > > However, if the behavior was changed so that the refresh token could only > be used once, then either: > 1. If the owner of the client machine would use the refresh token > first, then the stolen refresh token could not be used > 2. If the stolen refresh token would be used first, then the client > machine would not be able to use it and the user of that client machine > could be alerted that something was wrong. This user could then reset their > password or invalidate all of their access and refresh tokens. > > Furthermore, we are concerned about this same scenario, but with the > offline token. My understanding is that the offline token does not expire > and that it can?t be invalidated by logging out the user or changing the > user?s password. Have you thought about this scenario? > > Thank You, > > *Mikhail Kuznetsov* > Software Engineer > Hewlett Packard Enterprise > > > > *From:* Marek Posolda [mailto:mposolda at redhat.com ] > *Sent:* Tuesday, October 06, 2015 1:16 PM > *To:* Raghu Prabhala > *Cc:* Kuznetsov, Mike; > keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > Hi Raghu, > > >From the specs, it looks to me that this is not anything mandatory. The > paragraph is starting "For example". Feel free to create JIRA, but I > personally can't promise anything regarding this... > > Marek > > > On 06/10/15 17:37, Raghu Prabhala wrote: > > Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh token > should be invalidated but retained by the server - to handle compromise of > refresh tokens as they are long lived. > > Thanks, > Raghu > > Sent from my iPhone > > On Oct 6, 2015, at 10:53 AM, Marek Posolda < > mposolda at redhat.com> wrote: > > You're right, same refresh token can be used more times. However it is > still better to use refresh token R2 in your step 3 instead of using old > refresh token R1 because R2 has updated timestamp (each token is valid just > for 30 minutes or so, depends on the configured SSO session idle timeout). > > Or are you referring that this is security issue and potential possibility > to Man in the middle? If you use HTTPS (which is recommended for production > environment, and especially if you have unsecured/untrusted networkl), this > shouldn't be an issue. > > Marek > > On 06/10/15 16:34, Kuznetsov, Mike wrote: > > Hello, > > I noticed that with Keycloak, it seems that refresh tokens are still valid > after they are used once. This means that Keycloak does *not* invalidate > Refresh Tokens after they have been used once. > > I am able to successfully execute the following flow: > 1. Obtain Access Token (A1) and Refresh Token (R1) > 2. Use Refresh Token (R1) to obtain new Access Token (A2) and > Refresh Token (R2) > 3. Use same Refresh Token (R1) again to obtain new Access Token > (A3) and Refresh Token (R3) > > > Can you please tell me if this is the intended functionality? > > Thank You, > > *Mikhail Kuznetsov* > Software Engineer > Hewlett Packard Enterprise > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151013/3bde7d61/attachment-0001.html From sthorger at redhat.com Tue Oct 13 09:00:37 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 13 Oct 2015 15:00:37 +0200 Subject: [keycloak-dev] Keycloak 1.5.1 Released Message-ID: We've just released Keycloak 1.5.1. This release contains a moderate impact security fix and we recommend everyone that are currently using 1.5.0 to upgrade as soon as possible. The security issue does not affect older releases. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151013/68bf776c/attachment.html From mikhail.kuznetsov at hpe.com Tue Oct 13 15:03:35 2015 From: mikhail.kuznetsov at hpe.com (Kuznetsov, Mike) Date: Tue, 13 Oct 2015 19:03:35 +0000 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <1774067821.2822207.1444695961101.JavaMail.yahoo@mail.yahoo.com> References: <1774067821.2822207.1444695961101.JavaMail.yahoo@mail.yahoo.com> Message-ID: <66122567ABACCC42B5B568EC7E90551A1A747A05@G2W2432.americas.hpqcorp.net> Hello, As advised earlier, I have put a JIRA ticket for this issue: https://issues.jboss.org/browse/KEYCLOAK-1961 We are excited to start using Keycloak to support our product, but right now we are blocked due to this issue because it has been flagged by our security team when they were reviewing our design. Over the past few days, we have tried to overcome this issue by trying to revoke either the specific access token / refresh token if it is used more than once, or trying to revoke all the tokens for the user. However, we were unable to find a mechanism that would let us do this. Do you know if there is any mechanism to revoke a specific token, or to revoke all tokens for a user? Are there any plans to implement this in the future? Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Kamal Jagadevan Sent: Monday, October 12, 2015 8:26 PM To: stian at redhat.com; Marek Posolda Cc: keycloak-dev at lists.jboss.org; Jagadevan, Kamal Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token Hi Stian/Marek, Thanks for your attention in the matter. Probably you are referring to one other issue in client level, but Mike & I are referring at User level within or across client. User John Doe authenticates with his credentials and obtains token pair A1R1 1. After A1 expires, app refreshes the token pair to A2R2 USING R1 2. After A2 expires, app refreshes the token pair to A3R3 USING R1 (ideally it is should use R2 as it is the latest refresh token) In order to achieve this functionality, I was wondering why can't we use existing last refresh time from User session rather then checking it in the client session. IMHO, adding one more validation in the ValidateToken method in TokenManager class like this should resolve the problem. // after userSession is determined either for offline token or online token... if(oldToken.getIssuedAt() < userSession.getLastSessionRefresh()) { throw new OAuthErrorException(OAuthErrorException.INVALID_GRANT, "Stale refresh token - already used"); } Please let me know if you see any pitfalls other than the backward compatibility for existing keycloak users. I can work with you to merge this change & test it in the master. Best Kamal ________________________________ From: Stian Thorgersen > To: Marek Posolda > Cc: "Jagadevan, Kamal" >; "keycloak-dev at lists.jboss.org" > Sent: Wednesday, October 7, 2015 8:38 AM Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token You're right, we'd have to introduce a lastRefresh on ClientSession On 7 October 2015 at 14:35, Marek Posolda > wrote: On 07/10/15 14:23, Stian Thorgersen wrote: We should make this configurable. For those worried about security they can enforce new refresh tokens as well as offline tokens will replace the old tokens. It would be fairly simply to implement. If enabled we would only allow refresh token where iat is >= the last session refresh time. I was also thinking about this possibility. However if you have 2 clients and you refresh the token for client1, the refresh token of client2 won't be valid as his "iat" will be older. Also SSO login currently refreshes lastSessionRefresh on UserSession. However maybe we can introduce lastSessionRefresh to ClientSession as well? Marek I wouldn't make it default behavior for two reasons: * It would break existing clients if they expect to continue using the old refresh token * It comes at a performance cost as clients will have to store the new refresh tokens and offline tokens each time they refresh the token * For offline tokens Keycloak would also have to persist the last refresh time each time the offline token is refreshed I think we'd need to make it a realm wide configuration option. On 7 October 2015 at 14:12, Marek Posolda > wrote: The points are valid and security can be always improved, however sometimes improving security makes things complicated with the not-so-big advantage... IMO admin should always protect the machine to make sure that nobody unauthorized has access to refresh tokens. And for the transport, HTTPS should be always used. But feel free to create JIRA and we will see... When user or client is deleted, all refresh/offline tokens will defacto become invalid as well and can't be used anymore. You're right that offline token is still valid after user logout. User can revoke it manually in account management or admin can revoke it in admin console. However refresh token is invalid after user logout. All refresh/offline tokens for particular client can be revoked by admin by set notBefore policy to now, which can be done in admin console in "Revocation" tab of particular client. Marek On 07/10/15 04:27, Raghuram Prabhala wrote: Very valid points Mike and even I have similar concerns. But please do understand that even if the refresh token is stolen or compromised,it cannot be used by any client unless both the client_id and client_secret are also compromised/stolen. But nevertheless, it is a good practice to assume the worst and add in protective measures to minimize the chances. Marek/Bill/Stian - Even our organization is very particular that such potential security issues be addressed. Can this be taken up? BTW I am not sure if you have an API/End point to invalidate tokens for those that are either compromised or must be invalidated as either the user or client is no longer active. If you do not have one then it is a good idea to make one available. Thanks, Raghu ________________________________ From: "Kuznetsov, Mike" To: "keycloak-dev at lists.jboss.org" Cc: "Jagadevan, Kamal" Sent: Tuesday, October 6, 2015 4:34 PM Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token Hello, The reason I brought this up is that we are currently working on migrating out authentication from a commercially available product called Ping to Keycloak. We noticed that Ping invalidates the refresh token after it is used once, while Keycloak does not. I and my colleague, Kamal are concerned that by not invalidating the refresh token after first use, we may be opening a security hole. While SSL may protect the token in transit, we can see a scenario where the refresh token would be compromised or stolen from the client itself. In this case, the stolen refresh token could be used to get new access tokens without the owner of the client machine knowing. However, if the behavior was changed so that the refresh token could only be used once, then either: 1. If the owner of the client machine would use the refresh token first, then the stolen refresh token could not be used 2. If the stolen refresh token would be used first, then the client machine would not be able to use it and the user of that client machine could be alerted that something was wrong. This user could then reset their password or invalidate all of their access and refresh tokens. Furthermore, we are concerned about this same scenario, but with the offline token. My understanding is that the offline token does not expire and that it can?t be invalidated by logging out the user or changing the user?s password. Have you thought about this scenario? Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Tuesday, October 06, 2015 1:16 PM To: Raghu Prabhala Cc: Kuznetsov, Mike; keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token Hi Raghu, >From the specs, it looks to me that this is not anything mandatory. The paragraph is starting "For example". Feel free to create JIRA, but I personally can't promise anything regarding this... Marek On 06/10/15 17:37, Raghu Prabhala wrote: Hi Marek - section 10.4 of rfc6749 mentions that the prior refresh token should be invalidated but retained by the server - to handle compromise of refresh tokens as they are long lived. Thanks, Raghu Sent from my iPhone On Oct 6, 2015, at 10:53 AM, Marek Posolda > wrote: You're right, same refresh token can be used more times. However it is still better to use refresh token R2 in your step 3 instead of using old refresh token R1 because R2 has updated timestamp (each token is valid just for 30 minutes or so, depends on the configured SSO session idle timeout). Or are you referring that this is security issue and potential possibility to Man in the middle? If you use HTTPS (which is recommended for production environment, and especially if you have unsecured/untrusted networkl), this shouldn't be an issue. Marek On 06/10/15 16:34, Kuznetsov, Mike wrote: Hello, I noticed that with Keycloak, it seems that refresh tokens are still valid after they are used once. This means that Keycloak does not invalidate Refresh Tokens after they have been used once. I am able to successfully execute the following flow: 1. Obtain Access Token (A1) and Refresh Token (R1) 2. Use Refresh Token (R1) to obtain new Access Token (A2) and Refresh Token (R2) 3. Use same Refresh Token (R1) again to obtain new Access Token (A3) and Refresh Token (R3) Can you please tell me if this is the intended functionality? Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151013/514883fc/attachment-0001.html From bburke at redhat.com Tue Oct 13 15:50:01 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 13 Oct 2015 15:50:01 -0400 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <66122567ABACCC42B5B568EC7E90551A1A747A05@G2W2432.americas.hpqcorp.net> References: <1774067821.2822207.1444695961101.JavaMail.yahoo@mail.yahoo.com> <66122567ABACCC42B5B568EC7E90551A1A747A05@G2W2432.americas.hpqcorp.net> Message-ID: <561D6069.7070205@redhat.com> tokens are associated with sessions. Log out the user's sessions, and the tokens are now invalid. You can also push out a a not-before revocation policy. Applications will deny any tokens issued prior to the not-before timestamp. All this is doable in the admin console. There is an issue though with bearer-only REST services and access tokens. They do not get notified of logout events as they are stateless and instead rely on expiration of the access token (which is why access tokens should be short lived). You'd have to rely on pushing out a not-before revocation policy. IMO, because you can logout users and/or push out a revocation policy, I really don't see this as a high priority security issue for 1.6. I'll see if I can get it in before Friday. On 10/13/2015 3:03 PM, Kuznetsov, Mike wrote: > Hello, > > As advised earlier, I have put a JIRA ticket for this issue: > https://issues.jboss.org/browse/KEYCLOAK-1961 > > We are excited to start using Keycloak to support our product, but right > now we are blocked due to this issue because it has been flagged by our > security team when they were reviewing our design. > > Over the past few days, we have tried to overcome this issue by trying > to revoke either the specific access token / refresh token if it is used > more than once, or trying to revoke all the tokens for the user. > However, we were unable to find a mechanism that would let us do this. > *Do you know if there is any mechanism to revoke a specific token, or to > revoke all tokens for a user? Are there any plans to implement this in > the future?* > > ** > > Thank You, > > > *Mikhail Kuznetsov* > > Software Engineer > > Hewlett Packard Enterprise > > *From:*keycloak-dev-bounces at lists.jboss.org > [mailto:keycloak-dev-bounces at lists.jboss.org] *On Behalf Of *Kamal Jagadevan > *Sent:* Monday, October 12, 2015 8:26 PM > *To:* stian at redhat.com; Marek Posolda > *Cc:* keycloak-dev at lists.jboss.org; Jagadevan, Kamal > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > Hi Stian/Marek, > > Thanks for your attention in the matter. > > Probably you are referring to one other issue in client level, but Mike > & I are referring at User level within or across client. > > User John Doe authenticates with his credentials and obtains token pair > *A1R1* > > 1. After A1 expires, app refreshes the token pair to *A2R2 *USING R1 > 2. After A2 expires, app refreshes the token pair to *A3R3 USING > **R1***(ideally it is should use R2 as it is the latest refresh token) > > In order to achieve this functionality, I was wondering why can't we use > existing last refresh time from User session rather then checking it in > the client session. > > IMHO, adding one more validation in the ValidateToken method in > TokenManager class like this should resolve the problem. > > // after userSession is determined either for offline token or > online token... > > if(oldToken.getIssuedAt() < userSession.getLastSessionRefresh()) { > throw new > OAuthErrorException(OAuthErrorException.INVALID_GRANT, "Stale refresh > token - already used"); > } > > Please let me know if you see any pitfalls other than the backward > compatibility for existing keycloak users. I can work with you to merge > this change & test it in the master. > > Best > > Kamal > > ------------------------------------------------------------------------ > > *From:*Stian Thorgersen > > *To:* Marek Posolda > > *Cc:* "Jagadevan, Kamal" >; "keycloak-dev at lists.jboss.org > " > > *Sent:* Wednesday, October 7, 2015 8:38 AM > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > You're right, we'd have to introduce a lastRefresh on ClientSession > > On 7 October 2015 at 14:35, Marek Posolda > wrote: > > On 07/10/15 14:23, Stian Thorgersen wrote: > > We should make this configurable. For those worried about > security they can enforce new refresh tokens as well as offline > tokens will replace the old tokens. It would be fairly simply to > implement. If enabled we would only allow refresh token where > iat is >= the last session refresh time. > > I was also thinking about this possibility. However if you have 2 > clients and you refresh the token for client1, the refresh token of > client2 won't be valid as his "iat" will be older. Also SSO login > currently refreshes lastSessionRefresh on UserSession. However maybe > we can introduce lastSessionRefresh to ClientSession as well? > > Marek > > > > I wouldn't make it default behavior for two reasons: > > * It would break existing clients if they expect to continue > using the old refresh token > > * It comes at a performance cost as clients will have to store > the new refresh tokens and offline tokens each time they refresh > the token > > * For offline tokens Keycloak would also have to persist the > last refresh time each time the offline token is refreshed > > I think we'd need to make it a realm wide configuration option. > > On 7 October 2015 at 14:12, Marek Posolda > wrote: > > The points are valid and security can be always improved, > however sometimes improving security makes things > complicated with the not-so-big advantage... IMO admin > should always protect the machine to make sure that nobody > unauthorized has access to refresh tokens. And for the > transport, HTTPS should be always used. But feel free to > create JIRA and we will see... > > When user or client is deleted, all refresh/offline tokens > will defacto become invalid as well and can't be used > anymore. You're right that offline token is still valid > after user logout. User can revoke it manually in account > management or admin can revoke it in admin console. However > refresh token is invalid after user logout. All > refresh/offline tokens for particular client can be revoked > by admin by set notBefore policy to now, which can be done > in admin console in "Revocation" tab of particular client. > > Marek > > > > On 07/10/15 04:27, Raghuram Prabhala wrote: > > Very valid points Mike and even I have similar concerns. > But please do understand that even if the refresh token > is stolen or compromised,it cannot be used by any client > unless both the client_id and client_secret are also > compromised/stolen. But nevertheless, it is a good > practice to assume the worst and add in protective > measures to minimize the chances. > > Marek/Bill/Stian - Even our organization is very > particular that such potential security issues be > addressed. Can this be taken up? BTW I am not sure if > you have an API/End point to invalidate tokens for those > that are either compromised or must be invalidated as > either the user or client is no longer active. If you do > not have one then it is a good idea to make one available. > > Thanks, > > Raghu > > ------------------------------------------------------------------------ > > *From:*"Kuznetsov, Mike" > > *To:* "keycloak-dev at lists.jboss.org" > > > > *Cc:* "Jagadevan, Kamal" > > > *Sent:* Tuesday, October 6, 2015 4:34 PM > *Subject:* Re: [keycloak-dev] Same Refresh token can be > used multiple times to obtain access token > > Hello, > > The reason I brought this up is that we are currently > working on migrating out authentication from a > commercially available product called Ping to Keycloak. > We noticed that Ping invalidates the refresh token after > it is used once, while Keycloak does not. > > I and my colleague, Kamal are concerned that by not > invalidating the refresh token after first use, we may > be opening a security hole. While SSL may protect the > token in transit, we can see a scenario where the > refresh token would be compromised or stolen from the > client itself. In this case, the stolen refresh token > could be used to get new access tokens without the owner > of the client machine knowing. > > However, if the behavior was changed so that the refresh > token could only be used once, then either: > > 1.If the owner of the client machine would use the > refresh token first, then the stolen refresh token could > not be used > > 2.If the stolen refresh token would be used first, then > the client machine would not be able to use it and the > user of that client machine could be alerted that > something was wrong. This user could then reset their > password or invalidate all of their access and refresh > tokens. > > Furthermore, we are concerned about this same scenario, > but with the offline token. My understanding is that the > offline token does not expire and that it can?t be > invalidated by logging out the user or changing the > user?s password. Have you thought about this scenario? > > Thank You, > > > *Mikhail Kuznetsov* > > Software Engineer > > Hewlett Packard Enterprise > > *From:*Marek Posolda [mailto:mposolda at redhat.com] > *Sent:* Tuesday, October 06, 2015 1:16 PM > *To:* Raghu Prabhala > *Cc:* Kuznetsov, Mike; keycloak-dev at lists.jboss.org > > *Subject:* Re: [keycloak-dev] Same Refresh token can be > used multiple times to obtain access token > > Hi Raghu, > > >From the specs, it looks to me that this is not anything mandatory. The paragraph is starting "For example". Feel free to create JIRA, but I personally can't promise anything regarding this... > > Marek > > > On 06/10/15 17:37, Raghu Prabhala wrote: > > Hi Marek - section 10.4 of rfc6749 mentions that the > prior refresh token should be invalidated but > retained by the server - to handle compromise of > refresh tokens as they are long lived. > > Thanks, > > Raghu > > Sent from my iPhone > > > On Oct 6, 2015, at 10:53 AM, Marek Posolda > > > wrote: > > You're right, same refresh token can be used > more times. However it is still better to use > refresh token R2 in your step 3 instead of using > old refresh token R1 because R2 has updated > timestamp (each token is valid just for 30 > minutes or so, depends on the configured SSO > session idle timeout). > > Or are you referring that this is security issue > and potential possibility to Man in the middle? > If you use HTTPS (which is recommended for > production environment, and especially if you > have unsecured/untrusted networkl), this > shouldn't be an issue. > > Marek > > On 06/10/15 16:34, Kuznetsov, Mike wrote: > > Hello, > > I noticed that with Keycloak, it seems that > refresh tokens are still valid after they > are used once. This means that Keycloak does > *not* invalidate Refresh Tokens after they > have been used once. > > I am able to successfully execute the > following flow: > > 1.Obtain Access Token (A1) and Refresh Token > (R1) > > 2.Use Refresh Token (R1) to obtain new > Access Token (A2) and Refresh Token (R2) > > 3.Use same Refresh Token (R1) again to > obtain new Access Token (A3) and Refresh > Token (R3) > > Can you please tell me if this is the > intended functionality? > > Thank You, > > > *Mikhail Kuznetsov* > > Software Engineer > > Hewlett Packard Enterprise > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mikhail.kuznetsov at hpe.com Tue Oct 13 16:56:36 2015 From: mikhail.kuznetsov at hpe.com (Kuznetsov, Mike) Date: Tue, 13 Oct 2015 20:56:36 +0000 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <561D6069.7070205@redhat.com> References: <1774067821.2822207.1444695961101.JavaMail.yahoo@mail.yahoo.com> <66122567ABACCC42B5B568EC7E90551A1A747A05@G2W2432.americas.hpqcorp.net> <561D6069.7070205@redhat.com> Message-ID: <66122567ABACCC42B5B568EC7E90551A1A748AD4@G2W2432.americas.hpqcorp.net> Hello Bill, It is my understanding that revoking the session will log out the user, so I'm not sure that it will address the problem. I think what we want is to revoke a specific refresh token after we use it once so that it cannot be used again. I'm also not sure how we would use a not-before policy, since we would need to update this policy every time we get a new access token / refresh token pair. Thank You, Mikhail Kuznetsov Software Engineer Hewlett Packard Enterprise -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke Sent: Tuesday, October 13, 2015 3:50 PM To: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token tokens are associated with sessions. Log out the user's sessions, and the tokens are now invalid. You can also push out a a not-before revocation policy. Applications will deny any tokens issued prior to the not-before timestamp. All this is doable in the admin console. There is an issue though with bearer-only REST services and access tokens. They do not get notified of logout events as they are stateless and instead rely on expiration of the access token (which is why access tokens should be short lived). You'd have to rely on pushing out a not-before revocation policy. IMO, because you can logout users and/or push out a revocation policy, I really don't see this as a high priority security issue for 1.6. I'll see if I can get it in before Friday. On 10/13/2015 3:03 PM, Kuznetsov, Mike wrote: > Hello, > > As advised earlier, I have put a JIRA ticket for this issue: > https://issues.jboss.org/browse/KEYCLOAK-1961 > > We are excited to start using Keycloak to support our product, but > right now we are blocked due to this issue because it has been flagged > by our security team when they were reviewing our design. > > Over the past few days, we have tried to overcome this issue by trying > to revoke either the specific access token / refresh token if it is > used more than once, or trying to revoke all the tokens for the user. > However, we were unable to find a mechanism that would let us do this. > *Do you know if there is any mechanism to revoke a specific token, or > to revoke all tokens for a user? Are there any plans to implement this > in the future?* > > ** > > Thank You, > > > *Mikhail Kuznetsov* > > Software Engineer > > Hewlett Packard Enterprise > > *From:*keycloak-dev-bounces at lists.jboss.org > [mailto:keycloak-dev-bounces at lists.jboss.org] *On Behalf Of *Kamal > Jagadevan > *Sent:* Monday, October 12, 2015 8:26 PM > *To:* stian at redhat.com; Marek Posolda > *Cc:* keycloak-dev at lists.jboss.org; Jagadevan, Kamal > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > Hi Stian/Marek, > > Thanks for your attention in the matter. > > Probably you are referring to one other issue in client level, but > Mike & I are referring at User level within or across client. > > User John Doe authenticates with his credentials and obtains token > pair > *A1R1* > > 1. After A1 expires, app refreshes the token pair to *A2R2 *USING R1 > 2. After A2 expires, app refreshes the token pair to *A3R3 USING > **R1***(ideally it is should use R2 as it is the latest refresh > token) > > In order to achieve this functionality, I was wondering why can't we > use existing last refresh time from User session rather then checking > it in the client session. > > IMHO, adding one more validation in the ValidateToken method in > TokenManager class like this should resolve the problem. > > // after userSession is determined either for offline token > or online token... > > if(oldToken.getIssuedAt() < userSession.getLastSessionRefresh()) { > throw new > OAuthErrorException(OAuthErrorException.INVALID_GRANT, "Stale refresh > token - already used"); > } > > Please let me know if you see any pitfalls other than the backward > compatibility for existing keycloak users. I can work with you to > merge this change & test it in the master. > > Best > > Kamal > > ---------------------------------------------------------------------- > -- > > *From:*Stian Thorgersen > > *To:* Marek Posolda > > *Cc:* "Jagadevan, Kamal" >; > "keycloak-dev at lists.jboss.org " > > > *Sent:* Wednesday, October 7, 2015 8:38 AM > *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > You're right, we'd have to introduce a lastRefresh on ClientSession > > On 7 October 2015 at 14:35, Marek Posolda > wrote: > > On 07/10/15 14:23, Stian Thorgersen wrote: > > We should make this configurable. For those worried about > security they can enforce new refresh tokens as well as offline > tokens will replace the old tokens. It would be fairly simply to > implement. If enabled we would only allow refresh token where > iat is >= the last session refresh time. > > I was also thinking about this possibility. However if you have 2 > clients and you refresh the token for client1, the refresh token of > client2 won't be valid as his "iat" will be older. Also SSO login > currently refreshes lastSessionRefresh on UserSession. However maybe > we can introduce lastSessionRefresh to ClientSession as well? > > Marek > > > > I wouldn't make it default behavior for two reasons: > > * It would break existing clients if they expect to continue > using the old refresh token > > * It comes at a performance cost as clients will have to store > the new refresh tokens and offline tokens each time they refresh > the token > > * For offline tokens Keycloak would also have to persist the > last refresh time each time the offline token is refreshed > > I think we'd need to make it a realm wide configuration option. > > On 7 October 2015 at 14:12, Marek Posolda > wrote: > > The points are valid and security can be always improved, > however sometimes improving security makes things > complicated with the not-so-big advantage... IMO admin > should always protect the machine to make sure that nobody > unauthorized has access to refresh tokens. And for the > transport, HTTPS should be always used. But feel free to > create JIRA and we will see... > > When user or client is deleted, all refresh/offline tokens > will defacto become invalid as well and can't be used > anymore. You're right that offline token is still valid > after user logout. User can revoke it manually in account > management or admin can revoke it in admin console. However > refresh token is invalid after user logout. All > refresh/offline tokens for particular client can be revoked > by admin by set notBefore policy to now, which can be done > in admin console in "Revocation" tab of particular client. > > Marek > > > > On 07/10/15 04:27, Raghuram Prabhala wrote: > > Very valid points Mike and even I have similar concerns. > But please do understand that even if the refresh token > is stolen or compromised,it cannot be used by any client > unless both the client_id and client_secret are also > compromised/stolen. But nevertheless, it is a good > practice to assume the worst and add in protective > measures to minimize the chances. > > Marek/Bill/Stian - Even our organization is very > particular that such potential security issues be > addressed. Can this be taken up? BTW I am not sure if > you have an API/End point to invalidate tokens for those > that are either compromised or must be invalidated as > either the user or client is no longer active. If you do > not have one then it is a good idea to make one available. > > Thanks, > > Raghu > > > ---------------------------------------------------------------------- > -- > > *From:*"Kuznetsov, Mike" > > *To:* "keycloak-dev at lists.jboss.org" > > > > *Cc:* "Jagadevan, Kamal" > > > *Sent:* Tuesday, October 6, 2015 4:34 PM > *Subject:* Re: [keycloak-dev] Same Refresh token can be > used multiple times to obtain access token > > Hello, > > The reason I brought this up is that we are currently > working on migrating out authentication from a > commercially available product called Ping to Keycloak. > We noticed that Ping invalidates the refresh token after > it is used once, while Keycloak does not. > > I and my colleague, Kamal are concerned that by not > invalidating the refresh token after first use, we may > be opening a security hole. While SSL may protect the > token in transit, we can see a scenario where the > refresh token would be compromised or stolen from the > client itself. In this case, the stolen refresh token > could be used to get new access tokens without the owner > of the client machine knowing. > > However, if the behavior was changed so that the refresh > token could only be used once, then either: > > 1.If the owner of the client machine would use the > refresh token first, then the stolen refresh token could > not be used > > 2.If the stolen refresh token would be used first, then > the client machine would not be able to use it and the > user of that client machine could be alerted that > something was wrong. This user could then reset their > password or invalidate all of their access and refresh > tokens. > > Furthermore, we are concerned about this same scenario, > but with the offline token. My understanding is that the > offline token does not expire and that it can't be > invalidated by logging out the user or changing the > user's password. Have you thought about this scenario? > > Thank You, > > > *Mikhail Kuznetsov* > > Software Engineer > > Hewlett Packard Enterprise > > *From:*Marek Posolda [mailto:mposolda at redhat.com] > *Sent:* Tuesday, October 06, 2015 1:16 PM > *To:* Raghu Prabhala > *Cc:* Kuznetsov, Mike; keycloak-dev at lists.jboss.org > > *Subject:* Re: [keycloak-dev] Same Refresh token can be > used multiple times to obtain access token > > Hi Raghu, > > >From the specs, it looks to me that this is not anything mandatory. The paragraph is starting "For example". Feel free to create JIRA, but I personally can't promise anything regarding this... > > Marek > > > On 06/10/15 17:37, Raghu Prabhala wrote: > > Hi Marek - section 10.4 of rfc6749 mentions that the > prior refresh token should be invalidated but > retained by the server - to handle compromise of > refresh tokens as they are long lived. > > Thanks, > > Raghu > > Sent from my iPhone > > > On Oct 6, 2015, at 10:53 AM, Marek Posolda > > > wrote: > > You're right, same refresh token can be used > more times. However it is still better to use > refresh token R2 in your step 3 instead of using > old refresh token R1 because R2 has updated > timestamp (each token is valid just for 30 > minutes or so, depends on the configured SSO > session idle timeout). > > Or are you referring that this is security issue > and potential possibility to Man in the middle? > If you use HTTPS (which is recommended for > production environment, and especially if you > have unsecured/untrusted networkl), this > shouldn't be an issue. > > Marek > > On 06/10/15 16:34, Kuznetsov, Mike wrote: > > Hello, > > I noticed that with Keycloak, it seems that > refresh tokens are still valid after they > are used once. This means that Keycloak does > *not* invalidate Refresh Tokens after they > have been used once. > > I am able to successfully execute the > following flow: > > 1.Obtain Access Token (A1) and Refresh Token > (R1) > > 2.Use Refresh Token (R1) to obtain new > Access Token (A2) and Refresh Token (R2) > > 3.Use same Refresh Token (R1) again to > obtain new Access Token (A3) and Refresh > Token (R3) > > Can you please tell me if this is the > intended functionality? > > Thank You, > > > *Mikhail Kuznetsov* > > Software Engineer > > Hewlett Packard Enterprise > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Tue Oct 13 19:53:25 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 13 Oct 2015 19:53:25 -0400 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <66122567ABACCC42B5B568EC7E90551A1A748AD4@G2W2432.americas.hpqcorp.net> References: <1774067821.2822207.1444695961101.JavaMail.yahoo@mail.yahoo.com> <66122567ABACCC42B5B568EC7E90551A1A747A05@G2W2432.americas.hpqcorp.net> <561D6069.7070205@redhat.com> <66122567ABACCC42B5B568EC7E90551A1A748AD4@G2W2432.americas.hpqcorp.net> Message-ID: <561D9975.90203@redhat.com> If your application is careless with refresh tokens, there's not much Keycloak can do other than session management and revocation policies. Refresh tokens are not supposed to be distributed or shared. But, I've scheduled a jira for this. It may get done 1.6, 1.7 at the latest. On 10/13/2015 4:56 PM, Kuznetsov, Mike wrote: > Hello Bill, > > It is my understanding that revoking the session will log out the user, so I'm not sure that it will address the problem. I think what we want is to revoke a specific refresh token after we use it once so that it cannot be used again. > > I'm also not sure how we would use a not-before policy, since we would need to update this policy every time we get a new access token / refresh token pair. > > Thank You, > > Mikhail Kuznetsov > Software Engineer > Hewlett Packard Enterprise > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke > Sent: Tuesday, October 13, 2015 3:50 PM > To: keycloak-dev at lists.jboss.org > Subject: Re: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token > > tokens are associated with sessions. Log out the user's sessions, and the tokens are now invalid. You can also push out a a not-before revocation policy. Applications will deny any tokens issued prior to the not-before timestamp. All this is doable in the admin console. > > There is an issue though with bearer-only REST services and access tokens. They do not get notified of logout events as they are stateless and instead rely on expiration of the access token (which is why access tokens should be short lived). You'd have to rely on pushing out a not-before revocation policy. > > IMO, because you can logout users and/or push out a revocation policy, I really don't see this as a high priority security issue for 1.6. I'll see if I can get it in before Friday. > > On 10/13/2015 3:03 PM, Kuznetsov, Mike wrote: >> Hello, >> >> As advised earlier, I have put a JIRA ticket for this issue: >> https://issues.jboss.org/browse/KEYCLOAK-1961 >> >> We are excited to start using Keycloak to support our product, but >> right now we are blocked due to this issue because it has been flagged >> by our security team when they were reviewing our design. >> >> Over the past few days, we have tried to overcome this issue by trying >> to revoke either the specific access token / refresh token if it is >> used more than once, or trying to revoke all the tokens for the user. >> However, we were unable to find a mechanism that would let us do this. >> *Do you know if there is any mechanism to revoke a specific token, or >> to revoke all tokens for a user? Are there any plans to implement this >> in the future?* >> >> ** >> >> Thank You, >> >> >> *Mikhail Kuznetsov* >> >> Software Engineer >> >> Hewlett Packard Enterprise >> >> *From:*keycloak-dev-bounces at lists.jboss.org >> [mailto:keycloak-dev-bounces at lists.jboss.org] *On Behalf Of *Kamal >> Jagadevan >> *Sent:* Monday, October 12, 2015 8:26 PM >> *To:* stian at redhat.com; Marek Posolda >> *Cc:* keycloak-dev at lists.jboss.org; Jagadevan, Kamal >> *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple >> times to obtain access token >> >> Hi Stian/Marek, >> >> Thanks for your attention in the matter. >> >> Probably you are referring to one other issue in client level, but >> Mike & I are referring at User level within or across client. >> >> User John Doe authenticates with his credentials and obtains token >> pair >> *A1R1* >> >> 1. After A1 expires, app refreshes the token pair to *A2R2 *USING R1 >> 2. After A2 expires, app refreshes the token pair to *A3R3 USING >> **R1***(ideally it is should use R2 as it is the latest refresh >> token) >> >> In order to achieve this functionality, I was wondering why can't we >> use existing last refresh time from User session rather then checking >> it in the client session. >> >> IMHO, adding one more validation in the ValidateToken method in >> TokenManager class like this should resolve the problem. >> >> // after userSession is determined either for offline token >> or online token... >> >> if(oldToken.getIssuedAt() < userSession.getLastSessionRefresh()) { >> throw new >> OAuthErrorException(OAuthErrorException.INVALID_GRANT, "Stale refresh >> token - already used"); >> } >> >> Please let me know if you see any pitfalls other than the backward >> compatibility for existing keycloak users. I can work with you to >> merge this change & test it in the master. >> >> Best >> >> Kamal >> >> ---------------------------------------------------------------------- >> -- >> >> *From:*Stian Thorgersen > > >> *To:* Marek Posolda > >> *Cc:* "Jagadevan, Kamal" > >; >> "keycloak-dev at lists.jboss.org " >> > >> *Sent:* Wednesday, October 7, 2015 8:38 AM >> *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple >> times to obtain access token >> >> You're right, we'd have to introduce a lastRefresh on ClientSession >> >> On 7 October 2015 at 14:35, Marek Posolda > > wrote: >> >> On 07/10/15 14:23, Stian Thorgersen wrote: >> >> We should make this configurable. For those worried about >> security they can enforce new refresh tokens as well as offline >> tokens will replace the old tokens. It would be fairly simply to >> implement. If enabled we would only allow refresh token where >> iat is >= the last session refresh time. >> >> I was also thinking about this possibility. However if you have 2 >> clients and you refresh the token for client1, the refresh token of >> client2 won't be valid as his "iat" will be older. Also SSO login >> currently refreshes lastSessionRefresh on UserSession. However maybe >> we can introduce lastSessionRefresh to ClientSession as well? >> >> Marek >> >> >> >> I wouldn't make it default behavior for two reasons: >> >> * It would break existing clients if they expect to continue >> using the old refresh token >> >> * It comes at a performance cost as clients will have to store >> the new refresh tokens and offline tokens each time they refresh >> the token >> >> * For offline tokens Keycloak would also have to persist the >> last refresh time each time the offline token is refreshed >> >> I think we'd need to make it a realm wide configuration option. >> >> On 7 October 2015 at 14:12, Marek Posolda > > wrote: >> >> The points are valid and security can be always improved, >> however sometimes improving security makes things >> complicated with the not-so-big advantage... IMO admin >> should always protect the machine to make sure that nobody >> unauthorized has access to refresh tokens. And for the >> transport, HTTPS should be always used. But feel free to >> create JIRA and we will see... >> >> When user or client is deleted, all refresh/offline tokens >> will defacto become invalid as well and can't be used >> anymore. You're right that offline token is still valid >> after user logout. User can revoke it manually in account >> management or admin can revoke it in admin console. However >> refresh token is invalid after user logout. All >> refresh/offline tokens for particular client can be revoked >> by admin by set notBefore policy to now, which can be done >> in admin console in "Revocation" tab of particular client. >> >> Marek >> >> >> >> On 07/10/15 04:27, Raghuram Prabhala wrote: >> >> Very valid points Mike and even I have similar concerns. >> But please do understand that even if the refresh token >> is stolen or compromised,it cannot be used by any client >> unless both the client_id and client_secret are also >> compromised/stolen. But nevertheless, it is a good >> practice to assume the worst and add in protective >> measures to minimize the chances. >> >> Marek/Bill/Stian - Even our organization is very >> particular that such potential security issues be >> addressed. Can this be taken up? BTW I am not sure if >> you have an API/End point to invalidate tokens for those >> that are either compromised or must be invalidated as >> either the user or client is no longer active. If you do >> not have one then it is a good idea to make one available. >> >> Thanks, >> >> Raghu >> >> >> ---------------------------------------------------------------------- >> -- >> >> *From:*"Kuznetsov, Mike" >> >> *To:* "keycloak-dev at lists.jboss.org" >> >> >> >> *Cc:* "Jagadevan, Kamal" >> >> >> *Sent:* Tuesday, October 6, 2015 4:34 PM >> *Subject:* Re: [keycloak-dev] Same Refresh token can be >> used multiple times to obtain access token >> >> Hello, >> >> The reason I brought this up is that we are currently >> working on migrating out authentication from a >> commercially available product called Ping to Keycloak. >> We noticed that Ping invalidates the refresh token after >> it is used once, while Keycloak does not. >> >> I and my colleague, Kamal are concerned that by not >> invalidating the refresh token after first use, we may >> be opening a security hole. While SSL may protect the >> token in transit, we can see a scenario where the >> refresh token would be compromised or stolen from the >> client itself. In this case, the stolen refresh token >> could be used to get new access tokens without the owner >> of the client machine knowing. >> >> However, if the behavior was changed so that the refresh >> token could only be used once, then either: >> >> 1.If the owner of the client machine would use the >> refresh token first, then the stolen refresh token could >> not be used >> >> 2.If the stolen refresh token would be used first, then >> the client machine would not be able to use it and the >> user of that client machine could be alerted that >> something was wrong. This user could then reset their >> password or invalidate all of their access and refresh >> tokens. >> >> Furthermore, we are concerned about this same scenario, >> but with the offline token. My understanding is that the >> offline token does not expire and that it can't be >> invalidated by logging out the user or changing the >> user's password. Have you thought about this scenario? >> >> Thank You, >> >> >> *Mikhail Kuznetsov* >> >> Software Engineer >> >> Hewlett Packard Enterprise >> >> *From:*Marek Posolda [mailto:mposolda at redhat.com] >> *Sent:* Tuesday, October 06, 2015 1:16 PM >> *To:* Raghu Prabhala >> *Cc:* Kuznetsov, Mike; keycloak-dev at lists.jboss.org >> >> *Subject:* Re: [keycloak-dev] Same Refresh token can be >> used multiple times to obtain access token >> >> Hi Raghu, >> >> >From the specs, it looks to me that this is not anything mandatory. The paragraph is starting "For example". Feel free to create JIRA, but I personally can't promise anything regarding this... >> >> Marek >> >> >> On 06/10/15 17:37, Raghu Prabhala wrote: >> >> Hi Marek - section 10.4 of rfc6749 mentions that the >> prior refresh token should be invalidated but >> retained by the server - to handle compromise of >> refresh tokens as they are long lived. >> >> Thanks, >> >> Raghu >> >> Sent from my iPhone >> >> >> On Oct 6, 2015, at 10:53 AM, Marek Posolda >> > >> wrote: >> >> You're right, same refresh token can be used >> more times. However it is still better to use >> refresh token R2 in your step 3 instead of using >> old refresh token R1 because R2 has updated >> timestamp (each token is valid just for 30 >> minutes or so, depends on the configured SSO >> session idle timeout). >> >> Or are you referring that this is security issue >> and potential possibility to Man in the middle? >> If you use HTTPS (which is recommended for >> production environment, and especially if you >> have unsecured/untrusted networkl), this >> shouldn't be an issue. >> >> Marek >> >> On 06/10/15 16:34, Kuznetsov, Mike wrote: >> >> Hello, >> >> I noticed that with Keycloak, it seems that >> refresh tokens are still valid after they >> are used once. This means that Keycloak does >> *not* invalidate Refresh Tokens after they >> have been used once. >> >> I am able to successfully execute the >> following flow: >> >> 1.Obtain Access Token (A1) and Refresh Token >> (R1) >> >> 2.Use Refresh Token (R1) to obtain new >> Access Token (A2) and Refresh Token (R2) >> >> 3.Use same Refresh Token (R1) again to >> obtain new Access Token (A3) and Refresh >> Token (R3) >> >> Can you please tell me if this is the >> intended functionality? >> >> Thank You, >> >> >> *Mikhail Kuznetsov* >> >> Software Engineer >> >> Hewlett Packard Enterprise >> >> >> >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Wed Oct 14 00:45:16 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Oct 2015 06:45:16 +0200 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <561D9975.90203@redhat.com> References: <1774067821.2822207.1444695961101.JavaMail.yahoo@mail.yahoo.com> <66122567ABACCC42B5B568EC7E90551A1A747A05@G2W2432.americas.hpqcorp.net> <561D6069.7070205@redhat.com> <66122567ABACCC42B5B568EC7E90551A1A748AD4@G2W2432.americas.hpqcorp.net> <561D9975.90203@redhat.com> Message-ID: We've already discussed how to implement this. We'll add a lastRefresh for a client session and only permit refresh/offline tokens if the iat time is => lastRefresh for the client session. Simple to implement. However, our current adapters do not update the refresh tokens they use so this would have to be updated as well. Also, it could potentially break existing functionality. So we should probably make it a configurable option for a realm under token settings and have it disabled by default initially. In a future release we could then enable it by default for new installations. On 14 October 2015 at 01:53, Bill Burke wrote: > If your application is careless with refresh tokens, there's not much > Keycloak can do other than session management and revocation policies. > Refresh tokens are not supposed to be distributed or shared. > > But, I've scheduled a jira for this. It may get done 1.6, 1.7 at the > latest. > > On 10/13/2015 4:56 PM, Kuznetsov, Mike wrote: > > Hello Bill, > > > > It is my understanding that revoking the session will log out the user, > so I'm not sure that it will address the problem. I think what we want is > to revoke a specific refresh token after we use it once so that it cannot > be used again. > > > > I'm also not sure how we would use a not-before policy, since we would > need to update this policy every time we get a new access token / refresh > token pair. > > > > Thank You, > > > > Mikhail Kuznetsov > > Software Engineer > > Hewlett Packard Enterprise > > > > -----Original Message----- > > From: keycloak-dev-bounces at lists.jboss.org [mailto: > keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke > > Sent: Tuesday, October 13, 2015 3:50 PM > > To: keycloak-dev at lists.jboss.org > > Subject: Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > > > tokens are associated with sessions. Log out the user's sessions, and > the tokens are now invalid. You can also push out a a not-before > revocation policy. Applications will deny any tokens issued prior to the > not-before timestamp. All this is doable in the admin console. > > > > There is an issue though with bearer-only REST services and access > tokens. They do not get notified of logout events as they are stateless > and instead rely on expiration of the access token (which is why access > tokens should be short lived). You'd have to rely on pushing out a > not-before revocation policy. > > > > IMO, because you can logout users and/or push out a revocation policy, I > really don't see this as a high priority security issue for 1.6. I'll see > if I can get it in before Friday. > > > > On 10/13/2015 3:03 PM, Kuznetsov, Mike wrote: > >> Hello, > >> > >> As advised earlier, I have put a JIRA ticket for this issue: > >> https://issues.jboss.org/browse/KEYCLOAK-1961 > >> > >> We are excited to start using Keycloak to support our product, but > >> right now we are blocked due to this issue because it has been flagged > >> by our security team when they were reviewing our design. > >> > >> Over the past few days, we have tried to overcome this issue by trying > >> to revoke either the specific access token / refresh token if it is > >> used more than once, or trying to revoke all the tokens for the user. > >> However, we were unable to find a mechanism that would let us do this. > >> *Do you know if there is any mechanism to revoke a specific token, or > >> to revoke all tokens for a user? Are there any plans to implement this > >> in the future?* > >> > >> ** > >> > >> Thank You, > >> > >> > >> *Mikhail Kuznetsov* > >> > >> Software Engineer > >> > >> Hewlett Packard Enterprise > >> > >> *From:*keycloak-dev-bounces at lists.jboss.org > >> [mailto:keycloak-dev-bounces at lists.jboss.org] *On Behalf Of *Kamal > >> Jagadevan > >> *Sent:* Monday, October 12, 2015 8:26 PM > >> *To:* stian at redhat.com; Marek Posolda > >> *Cc:* keycloak-dev at lists.jboss.org; Jagadevan, Kamal > >> *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > >> times to obtain access token > >> > >> Hi Stian/Marek, > >> > >> Thanks for your attention in the matter. > >> > >> Probably you are referring to one other issue in client level, but > >> Mike & I are referring at User level within or across client. > >> > >> User John Doe authenticates with his credentials and obtains token > >> pair > >> *A1R1* > >> > >> 1. After A1 expires, app refreshes the token pair to *A2R2 *USING R1 > >> 2. After A2 expires, app refreshes the token pair to *A3R3 USING > >> **R1***(ideally it is should use R2 as it is the latest refresh > >> token) > >> > >> In order to achieve this functionality, I was wondering why can't we > >> use existing last refresh time from User session rather then checking > >> it in the client session. > >> > >> IMHO, adding one more validation in the ValidateToken method in > >> TokenManager class like this should resolve the problem. > >> > >> // after userSession is determined either for offline token > >> or online token... > >> > >> if(oldToken.getIssuedAt() < > userSession.getLastSessionRefresh()) { > >> throw new > >> OAuthErrorException(OAuthErrorException.INVALID_GRANT, "Stale refresh > >> token - already used"); > >> } > >> > >> Please let me know if you see any pitfalls other than the backward > >> compatibility for existing keycloak users. I can work with you to > >> merge this change & test it in the master. > >> > >> Best > >> > >> Kamal > >> > >> ---------------------------------------------------------------------- > >> -- > >> > >> *From:*Stian Thorgersen >> > > >> *To:* Marek Posolda > > >> *Cc:* "Jagadevan, Kamal" >> >; > >> "keycloak-dev at lists.jboss.org " > >> > > >> *Sent:* Wednesday, October 7, 2015 8:38 AM > >> *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > >> times to obtain access token > >> > >> You're right, we'd have to introduce a lastRefresh on ClientSession > >> > >> On 7 October 2015 at 14:35, Marek Posolda >> > wrote: > >> > >> On 07/10/15 14:23, Stian Thorgersen wrote: > >> > >> We should make this configurable. For those worried about > >> security they can enforce new refresh tokens as well as offline > >> tokens will replace the old tokens. It would be fairly simply > to > >> implement. If enabled we would only allow refresh token where > >> iat is >= the last session refresh time. > >> > >> I was also thinking about this possibility. However if you have 2 > >> clients and you refresh the token for client1, the refresh token of > >> client2 won't be valid as his "iat" will be older. Also SSO login > >> currently refreshes lastSessionRefresh on UserSession. However > maybe > >> we can introduce lastSessionRefresh to ClientSession as well? > >> > >> Marek > >> > >> > >> > >> I wouldn't make it default behavior for two reasons: > >> > >> * It would break existing clients if they expect to continue > >> using the old refresh token > >> > >> * It comes at a performance cost as clients will have to store > >> the new refresh tokens and offline tokens each time they > refresh > >> the token > >> > >> * For offline tokens Keycloak would also have to persist the > >> last refresh time each time the offline token is refreshed > >> > >> I think we'd need to make it a realm wide configuration option. > >> > >> On 7 October 2015 at 14:12, Marek Posolda >> > wrote: > >> > >> The points are valid and security can be always improved, > >> however sometimes improving security makes things > >> complicated with the not-so-big advantage... IMO admin > >> should always protect the machine to make sure that nobody > >> unauthorized has access to refresh tokens. And for the > >> transport, HTTPS should be always used. But feel free to > >> create JIRA and we will see... > >> > >> When user or client is deleted, all refresh/offline tokens > >> will defacto become invalid as well and can't be used > >> anymore. You're right that offline token is still valid > >> after user logout. User can revoke it manually in account > >> management or admin can revoke it in admin console. However > >> refresh token is invalid after user logout. All > >> refresh/offline tokens for particular client can be revoked > >> by admin by set notBefore policy to now, which can be done > >> in admin console in "Revocation" tab of particular client. > >> > >> Marek > >> > >> > >> > >> On 07/10/15 04:27, Raghuram Prabhala wrote: > >> > >> Very valid points Mike and even I have similar > concerns. > >> But please do understand that even if the refresh token > >> is stolen or compromised,it cannot be used by any > client > >> unless both the client_id and client_secret are also > >> compromised/stolen. But nevertheless, it is a good > >> practice to assume the worst and add in protective > >> measures to minimize the chances. > >> > >> Marek/Bill/Stian - Even our organization is very > >> particular that such potential security issues be > >> addressed. Can this be taken up? BTW I am not sure if > >> you have an API/End point to invalidate tokens for > those > >> that are either compromised or must be invalidated as > >> either the user or client is no longer active. If you > do > >> not have one then it is a good idea to make one > available. > >> > >> Thanks, > >> > >> Raghu > >> > >> > >> ---------------------------------------------------------------------- > >> -- > >> > >> *From:*"Kuznetsov, Mike" > >> > >> *To:* "keycloak-dev at lists.jboss.org" > >> > >> > >> > >> *Cc:* "Jagadevan, Kamal" > >> > >> > >> *Sent:* Tuesday, October 6, 2015 4:34 PM > >> *Subject:* Re: [keycloak-dev] Same Refresh token can be > >> used multiple times to obtain access token > >> > >> Hello, > >> > >> The reason I brought this up is that we are currently > >> working on migrating out authentication from a > >> commercially available product called Ping to Keycloak. > >> We noticed that Ping invalidates the refresh token > after > >> it is used once, while Keycloak does not. > >> > >> I and my colleague, Kamal are concerned that by not > >> invalidating the refresh token after first use, we may > >> be opening a security hole. While SSL may protect the > >> token in transit, we can see a scenario where the > >> refresh token would be compromised or stolen from the > >> client itself. In this case, the stolen refresh token > >> could be used to get new access tokens without the > owner > >> of the client machine knowing. > >> > >> However, if the behavior was changed so that the > refresh > >> token could only be used once, then either: > >> > >> 1.If the owner of the client machine would use the > >> refresh token first, then the stolen refresh token > could > >> not be used > >> > >> 2.If the stolen refresh token would be used first, then > >> the client machine would not be able to use it and the > >> user of that client machine could be alerted that > >> something was wrong. This user could then reset their > >> password or invalidate all of their access and refresh > >> tokens. > >> > >> Furthermore, we are concerned about this same scenario, > >> but with the offline token. My understanding is that > the > >> offline token does not expire and that it can't be > >> invalidated by logging out the user or changing the > >> user's password. Have you thought about this scenario? > >> > >> Thank You, > >> > >> > >> *Mikhail Kuznetsov* > >> > >> Software Engineer > >> > >> Hewlett Packard Enterprise > >> > >> *From:*Marek Posolda [mailto:mposolda at redhat.com] > >> *Sent:* Tuesday, October 06, 2015 1:16 PM > >> *To:* Raghu Prabhala > >> *Cc:* Kuznetsov, Mike; keycloak-dev at lists.jboss.org > >> > >> *Subject:* Re: [keycloak-dev] Same Refresh token can be > >> used multiple times to obtain access token > >> > >> Hi Raghu, > >> > >> >From the specs, it looks to me that this is not > anything mandatory. The paragraph is starting "For example". Feel free to > create JIRA, but I personally can't promise anything regarding this... > >> > >> Marek > >> > >> > >> On 06/10/15 17:37, Raghu Prabhala wrote: > >> > >> Hi Marek - section 10.4 of rfc6749 mentions that > the > >> prior refresh token should be invalidated but > >> retained by the server - to handle compromise of > >> refresh tokens as they are long lived. > >> > >> Thanks, > >> > >> Raghu > >> > >> Sent from my iPhone > >> > >> > >> On Oct 6, 2015, at 10:53 AM, Marek Posolda > >> > > >> wrote: > >> > >> You're right, same refresh token can be used > >> more times. However it is still better to use > >> refresh token R2 in your step 3 instead of > using > >> old refresh token R1 because R2 has updated > >> timestamp (each token is valid just for 30 > >> minutes or so, depends on the configured SSO > >> session idle timeout). > >> > >> Or are you referring that this is security > issue > >> and potential possibility to Man in the middle? > >> If you use HTTPS (which is recommended for > >> production environment, and especially if you > >> have unsecured/untrusted networkl), this > >> shouldn't be an issue. > >> > >> Marek > >> > >> On 06/10/15 16:34, Kuznetsov, Mike wrote: > >> > >> Hello, > >> > >> I noticed that with Keycloak, it seems that > >> refresh tokens are still valid after they > >> are used once. This means that Keycloak > does > >> *not* invalidate Refresh Tokens after they > >> have been used once. > >> > >> I am able to successfully execute the > >> following flow: > >> > >> 1.Obtain Access Token (A1) and Refresh > Token > >> (R1) > >> > >> 2.Use Refresh Token (R1) to obtain new > >> Access Token (A2) and Refresh Token (R2) > >> > >> 3.Use same Refresh Token (R1) again to > >> obtain new Access Token (A3) and Refresh > >> Token (R3) > >> > >> Can you please tell me if this is the > >> intended functionality? > >> > >> Thank You, > >> > >> > >> *Mikhail Kuznetsov* > >> > >> Software Engineer > >> > >> Hewlett Packard Enterprise > >> > >> > >> > >> > >> _______________________________________________ > >> > >> keycloak-dev mailing list > >> > >> keycloak-dev at lists.jboss.org > >> > >> > >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> > >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> > >> _______________________________________________ > >> > >> keycloak-dev mailing list > >> > >> keycloak-dev at lists.jboss.org > >> > >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/0271ba85/attachment-0001.html From mposolda at redhat.com Wed Oct 14 06:22:09 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 14 Oct 2015 12:22:09 +0200 Subject: [keycloak-dev] Offline sessions persistence changes Message-ID: <561E2CD1.3040002@redhat.com> I've sent PR https://github.com/keycloak/keycloak/pull/1726 with the persistent changes for offline tokens according to what we discussed with Stian. Summary: - Offline userSessions and clientSessiona are now stored in infinispan, but also in DB. - DB storage is done through UserSessionPersisterProvider SPI. I've added implementations based on JPA and Mongo. - When new offline userSession and clientSessions needs to be stored, it is added to both infinispan and persistent storage through UserSessionPersisterProvider. Revocation/removing of offline session is also propagated to both infinispan and persister. - All requests to auth-server (ie. refreshing token etc) interacts with infinispan storage. Persister is used just during startup to pre-load infinispan storage with the sessions from DB. This allows that sessions survive server restart. - New cache "offlineSessions" was added to the Infinispan. This is separate to the "sessions" cache as both can have stored sessions with same IDs, so this is to not clash with each other. - I've looked at how to best implement the pre-loading of infinispan with the sessions from persister storage. The infinispan builtin CacheStore/CacheLoader was my first attempt, however it turned to not very good for various reasons (For example CacheStore SPI is incompatible between Infinispan 5 and 6, same for the format of data etc). In the end I used infinispan DistributionService http://infinispan.org/docs/5.0.x/user_guide/user_guide.html#_infinispan_distributed_execution_framework . The impl is done in a way that parallel startup of cluster nodes is not a problem, but an advantage as each cluster node prefills different sessions. For example if you have 1000.000 userSessions in DB, the node1 will preload around 500.000 sessions and node2 another 500.000 sessions. If one of the nodes crashes at startup, it's not a problem as well, even if it's coordinator node. Similarly when new node joins cluster when other nodes are still starting and pre-loading, new node will immediatelly start to help with pre-loading. I wonder we can reuse this stuff for other long-running tasks as well (for example export/import of big number of users at startup etc) - MemUserSessionProvider was updated too, so EAP 6.4 in local mode works fine as well. - The persister saves offline sessions data into DB partially serialized into JSON. Just the columns, which are needed for quick DB search (id, realm_id, user_id, client_id) are saved as DB columns. I think this should simplify migration and amount of needed work when new field is added to UserSession / ClientSession. - It's possible to have more offline sessions / tokens per user+client Still TODO: - Add "Offline token idle timeout" . The offline sessions not refreshed during specified time will be cleared from both infinispan and storage. Not sure about default value, 7 days? - Export/import of offline sessions. - Minor Juca's reported bug: https://issues.jboss.org/browse/KEYCLOAK-1959 - Reduce some INFO logging I've added - Maybe more if you have additional feedback? I expect to have it done by Thursday. It seems I will need to postpone some LDAP enhancements I planned for this release :/ But none of them are critical. Still need to doublecheck export/import and fix fuse for this release. Marek From sthorger at redhat.com Wed Oct 14 07:10:50 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Oct 2015 13:10:50 +0200 Subject: [keycloak-dev] Same Refresh token can be used multiple times to obtain access token In-Reply-To: <000f4247.06f2219f4636ed42@hp.com> References: <1774067821.2822207.1444695961101.JavaMail.yahoo@mail.yahoo.com> <66122567ABACCC42B5B568EC7E90551A1A747A05@G2W2432.americas.hpqcorp.net> <561D6069.7070205@redhat.com> <66122567ABACCC42B5B568EC7E90551A1A748AD4@G2W2432.americas.hpqcorp.net> <561D9975.90203@redhat.com> <000f4247.06f2219f4636ed42@hp.com> Message-ID: I'll try to add it tonight, unless I run into any issues it will be included in 1.6. On 14 October 2015 at 11:24, Jain, Rahul (Rahul Jain) wrote: > Could you please tell if this will be done in 1.6 release? > > > Rahul > > > Sent from my LG G3, an AT&T 4G LTE smartphone > > > ------ Original message------ > > From: Stian Thorgersen > > Date: Wed, Oct 14, 2015 12:45 AM > > To: Bill Burke; > > Cc: Kuznetsov, Mike;keycloak-dev at lists.jboss.org;Jagadevan, Kamal;Jain, > Rahul (Rahul Jain); > > Subject:Re: [keycloak-dev] Same Refresh token can be used multiple times > to obtain access token > > > We've already discussed how to implement this. We'll add a lastRefresh for > a client session and only permit refresh/offline tokens if the iat time is > => lastRefresh for the client session. Simple to implement. However, our > current adapters do not update the refresh tokens they use so this would > have to be updated as well. Also, it could potentially break existing > functionality. So we should probably make it a configurable option for a > realm under token settings and have it disabled by default initially. In a > future release we could then enable it by default for new installations. > > On 14 October 2015 at 01:53, Bill Burke bburke at redhat.com>> wrote: > If your application is careless with refresh tokens, there's not much > Keycloak can do other than session management and revocation policies. > Refresh tokens are not supposed to be distributed or shared. > > But, I've scheduled a jira for this. It may get done 1.6, 1.7 at the > latest. > > On 10/13/2015 4:56 PM, Kuznetsov, Mike wrote: > > Hello Bill, > > > > It is my understanding that revoking the session will log out the user, > so I'm not sure that it will address the problem. I think what we want is > to revoke a specific refresh token after we use it once so that it cannot > be used again. > > > > I'm also not sure how we would use a not-before policy, since we would > need to update this policy every time we get a new access token / refresh > token pair. > > > > Thank You, > > > > Mikhail Kuznetsov > > Software Engineer > > Hewlett Packard Enterprise > > > > -----Original Message----- > > From: keycloak-dev-bounces at lists.jboss.org keycloak-dev-bounces at lists.jboss.org> [mailto: > keycloak-dev-bounces at lists.jboss.org keycloak-dev-bounces at lists.jboss.org>] On Behalf Of Bill Burke > > Sent: Tuesday, October 13, 2015 3:50 PM > > To: keycloak-dev at lists.jboss.org > > Subject: Re: [keycloak-dev] Same Refresh token can be used multiple > times to obtain access token > > > > tokens are associated with sessions. Log out the user's sessions, and > the tokens are now invalid. You can also push out a a not-before > revocation policy. Applications will deny any tokens issued prior to the > not-before timestamp. All this is doable in the admin console. > > > > There is an issue though with bearer-only REST services and access > tokens. They do not get notified of logout events as they are stateless > and instead rely on expiration of the access token (which is why access > tokens should be short lived). You'd have to rely on pushing out a > not-before revocation policy. > > > > IMO, because you can logout users and/or push out a revocation policy, I > really don't see this as a high priority security issue for 1.6. I'll see > if I can get it in before Friday. > > > > On 10/13/2015 3:03 PM, Kuznetsov, Mike wrote: > >> Hello, > >> > >> As advised earlier, I have put a JIRA ticket for this issue: > >> https://issues.jboss.org/browse/KEYCLOAK-1961 > >> > >> We are excited to start using Keycloak to support our product, but > >> right now we are blocked due to this issue because it has been flagged > >> by our security team when they were reviewing our design. > >> > >> Over the past few days, we have tried to overcome this issue by trying > >> to revoke either the specific access token / refresh token if it is > >> used more than once, or trying to revoke all the tokens for the user. > >> However, we were unable to find a mechanism that would let us do this. > >> *Do you know if there is any mechanism to revoke a specific token, or > >> to revoke all tokens for a user? Are there any plans to implement this > >> in the future?* > >> > >> ** > >> > >> Thank You, > >> > >> > >> *Mikhail Kuznetsov* > >> > >> Software Engineer > >> > >> Hewlett Packard Enterprise > >> > >> *From:*keycloak-dev-bounces at lists.jboss.org keycloak-dev-bounces at lists.jboss.org> > >> [mailto:keycloak-dev-bounces at lists.jboss.org keycloak-dev-bounces at lists.jboss.org>] *On Behalf Of *Kamal > >> Jagadevan > >> *Sent:* Monday, October 12, 2015 8:26 PM > >> *To:* stian at redhat.com; Marek Posolda > >> *Cc:* keycloak-dev at lists.jboss.org; > Jagadevan, Kamal > >> *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > >> times to obtain access token > >> > >> Hi Stian/Marek, > >> > >> Thanks for your attention in the matter. > >> > >> Probably you are referring to one other issue in client level, but > >> Mike & I are referring at User level within or across client. > >> > >> User John Doe authenticates with his credentials and obtains token > >> pair > >> *A1R1* > >> > >> 1. After A1 expires, app refreshes the token pair to *A2R2 *USING R1 > >> 2. After A2 expires, app refreshes the token pair to *A3R3 USING > >> **R1***(ideally it is should use R2 as it is the latest refresh > >> token) > >> > >> In order to achieve this functionality, I was wondering why can't we > >> use existing last refresh time from User session rather then checking > >> it in the client session. > >> > >> IMHO, adding one more validation in the ValidateToken method in > >> TokenManager class like this should resolve the problem. > >> > >> // after userSession is determined either for offline token > >> or online token... > >> > >> if(oldToken.getIssuedAt() < > userSession.getLastSessionRefresh()) { > >> throw new > >> OAuthErrorException(OAuthErrorException.INVALID_GRANT, "Stale refresh > >> token - already used"); > >> } > >> > >> Please let me know if you see any pitfalls other than the backward > >> compatibility for existing keycloak users. I can work with you to > >> merge this change & test it in the master. > >> > >> Best > >> > >> Kamal > >> > >> ---------------------------------------------------------------------- > >> -- > >> > >> *From:*Stian Thorgersen > > >> >> > >> *To:* Marek Posolda > >> > >> *Cc:* "Jagadevan, Kamal" kamalakannan.jagadevan at hpe.com> > >> kamalakannan.jagadevan at hpe.com>>>; > >> "keycloak-dev at lists.jboss.org > >>" > >> > >>> > >> *Sent:* Wednesday, October 7, 2015 8:38 AM > >> *Subject:* Re: [keycloak-dev] Same Refresh token can be used multiple > >> times to obtain access token > >> > >> You're right, we'd have to introduce a lastRefresh on ClientSession > >> > >> On 7 October 2015 at 14:35, Marek Posolda mposolda at redhat.com> > >> >> wrote: > >> > >> On 07/10/15 14:23, Stian Thorgersen wrote: > >> > >> We should make this configurable. For those worried about > >> security they can enforce new refresh tokens as well as offline > >> tokens will replace the old tokens. It would be fairly simply > to > >> implement. If enabled we would only allow refresh token where > >> iat is >= the last session refresh time. > >> > >> I was also thinking about this possibility. However if you have 2 > >> clients and you refresh the token for client1, the refresh token of > >> client2 won't be valid as his "iat" will be older. Also SSO login > >> currently refreshes lastSessionRefresh on UserSession. However > maybe > >> we can introduce lastSessionRefresh to ClientSession as well? > >> > >> Marek > >> > >> > >> > >> I wouldn't make it default behavior for two reasons: > >> > >> * It would break existing clients if they expect to continue > >> using the old refresh token > >> > >> * It comes at a performance cost as clients will have to store > >> the new refresh tokens and offline tokens each time they > refresh > >> the token > >> > >> * For offline tokens Keycloak would also have to persist the > >> last refresh time each time the offline token is refreshed > >> > >> I think we'd need to make it a realm wide configuration option. > >> > >> On 7 October 2015 at 14:12, Marek Posolda > >> >> > wrote: > >> > >> The points are valid and security can be always improved, > >> however sometimes improving security makes things > >> complicated with the not-so-big advantage... IMO admin > >> should always protect the machine to make sure that nobody > >> unauthorized has access to refresh tokens. And for the > >> transport, HTTPS should be always used. But feel free to > >> create JIRA and we will see... > >> > >> When user or client is deleted, all refresh/offline tokens > >> will defacto become invalid as well and can't be used > >> anymore. You're right that offline token is still valid > >> after user logout. User can revoke it manually in account > >> management or admin can revoke it in admin console. However > >> refresh token is invalid after user logout. All > >> refresh/offline tokens for particular client can be revoked > >> by admin by set notBefore policy to now, which can be done > >> in admin console in "Revocation" tab of particular client. > >> > >> Marek > >> > >> > >> > >> On 07/10/15 04:27, Raghuram Prabhala wrote: > >> > >> Very valid points Mike and even I have similar > concerns. > >> But please do understand that even if the refresh token > >> is stolen or compromised,it cannot be used by any > client > >> unless both the client_id and client_secret are also > >> compromised/stolen. But nevertheless, it is a good > >> practice to assume the worst and add in protective > >> measures to minimize the chances. > >> > >> Marek/Bill/Stian - Even our organization is very > >> particular that such potential security issues be > >> addressed. Can this be taken up? BTW I am not sure if > >> you have an API/End point to invalidate tokens for > those > >> that are either compromised or must be invalidated as > >> either the user or client is no longer active. If you > do > >> not have one then it is a good idea to make one > available. > >> > >> Thanks, > >> > >> Raghu > >> > >> > >> ---------------------------------------------------------------------- > >> -- > >> > >> *From:*"Kuznetsov, Mike" > > >> mikhail.kuznetsov at hpe.com>> > >> *To:* "keycloak-dev at lists.jboss.org keycloak-dev at lists.jboss.org>" > >> keycloak-dev at lists.jboss.org>> > >> keycloak-dev at lists.jboss.org>> > >> keycloak-dev at lists.jboss.org>> > >> *Cc:* "Jagadevan, Kamal" > >> kamalakannan.jagadevan at hpe.com>> > >> kamalakannan.jagadevan at hpe.com>> > >> *Sent:* Tuesday, October 6, 2015 4:34 PM > >> *Subject:* Re: [keycloak-dev] Same Refresh token can be > >> used multiple times to obtain access token > >> > >> Hello, > >> > >> The reason I brought this up is that we are currently > >> working on migrating out authentication from a > >> commercially available product called Ping to Keycloak. > >> We noticed that Ping invalidates the refresh token > after > >> it is used once, while Keycloak does not. > >> > >> I and my colleague, Kamal are concerned that by not > >> invalidating the refresh token after first use, we may > >> be opening a security hole. While SSL may protect the > >> token in transit, we can see a scenario where the > >> refresh token would be compromised or stolen from the > >> client itself. In this case, the stolen refresh token > >> could be used to get new access tokens without the > owner > >> of the client machine knowing. > >> > >> However, if the behavior was changed so that the > refresh > >> token could only be used once, then either: > >> > >> 1.If the owner of the client machine would use the > >> refresh token first, then the stolen refresh token > could > >> not be used > >> > >> 2.If the stolen refresh token would be used first, then > >> the client machine would not be able to use it and the > >> user of that client machine could be alerted that > >> something was wrong. This user could then reset their > >> password or invalidate all of their access and refresh > >> tokens. > >> > >> Furthermore, we are concerned about this same scenario, > >> but with the offline token. My understanding is that > the > >> offline token does not expire and that it can't be > >> invalidated by logging out the user or changing the > >> user's password. Have you thought about this scenario? > >> > >> Thank You, > >> > >> > >> *Mikhail Kuznetsov* > >> > >> Software Engineer > >> > >> Hewlett Packard Enterprise > >> > >> *From:*Marek Posolda [mailto:mposolda at redhat.com > ] > >> *Sent:* Tuesday, October 06, 2015 1:16 PM > >> *To:* Raghu Prabhala > >> *Cc:* Kuznetsov, Mike; keycloak-dev at lists.jboss.org > > >> keycloak-dev at lists.jboss.org>> > >> *Subject:* Re: [keycloak-dev] Same Refresh token can be > >> used multiple times to obtain access token > >> > >> Hi Raghu, > >> > >> >From the specs, it looks to me that this is not > anything mandatory. The paragraph is starting "For example". Feel free to > create JIRA, but I personally can't promise anything regarding this... > >> > >> Marek > >> > >> > >> On 06/10/15 17:37, Raghu Prabhala wrote: > >> > >> Hi Marek - section 10.4 of rfc6749 mentions that > the > >> prior refresh token should be invalidated but > >> retained by the server - to handle compromise of > >> refresh tokens as they are long lived. > >> > >> Thanks, > >> > >> Raghu > >> > >> Sent from my iPhone > >> > >> > >> On Oct 6, 2015, at 10:53 AM, Marek Posolda > >> > >> > >> wrote: > >> > >> You're right, same refresh token can be used > >> more times. However it is still better to use > >> refresh token R2 in your step 3 instead of > using > >> old refresh token R1 because R2 has updated > >> timestamp (each token is valid just for 30 > >> minutes or so, depends on the configured SSO > >> session idle timeout). > >> > >> Or are you referring that this is security > issue > >> and potential possibility to Man in the middle? > >> If you use HTTPS (which is recommended for > >> production environment, and especially if you > >> have unsecured/untrusted networkl), this > >> shouldn't be an issue. > >> > >> Marek > >> > >> On 06/10/15 16:34, Kuznetsov, Mike wrote: > >> > >> Hello, > >> > >> I noticed that with Keycloak, it seems that > >> refresh tokens are still valid after they > >> are used once. This means that Keycloak > does > >> *not* invalidate Refresh Tokens after they > >> have been used once. > >> > >> I am able to successfully execute the > >> following flow: > >> > >> 1.Obtain Access Token (A1) and Refresh > Token > >> (R1) > >> > >> 2.Use Refresh Token (R1) to obtain new > >> Access Token (A2) and Refresh Token (R2) > >> > >> 3.Use same Refresh Token (R1) again to > >> obtain new Access Token (A3) and Refresh > >> Token (R3) > >> > >> Can you please tell me if this is the > >> intended functionality? > >> > >> Thank You, > >> > >> > >> *Mikhail Kuznetsov* > >> > >> Software Engineer > >> > >> Hewlett Packard Enterprise > >> > >> > >> > >> > >> _______________________________________________ > >> > >> keycloak-dev mailing list > >> > >> keycloak-dev at lists.jboss.org keycloak-dev at lists.jboss.org> > >> > > >> > >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org keycloak-dev at lists.jboss.org> > >> keycloak-dev at lists.jboss.org>> > >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org keycloak-dev at lists.jboss.org> > >> keycloak-dev at lists.jboss.org>> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> > >> _______________________________________________ > >> > >> keycloak-dev mailing list > >> > >> keycloak-dev at lists.jboss.org keycloak-dev at lists.jboss.org> > >> keycloak-dev at lists.jboss.org>> > >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org keycloak-dev at lists.jboss.org> > >> keycloak-dev at lists.jboss.org>> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/5dc93fe6/attachment-0001.html From sthorger at redhat.com Wed Oct 14 07:20:10 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Oct 2015 13:20:10 +0200 Subject: [keycloak-dev] Offline sessions persistence changes In-Reply-To: <561E2CD1.3040002@redhat.com> References: <561E2CD1.3040002@redhat.com> Message-ID: On 14 October 2015 at 12:22, Marek Posolda wrote: > I've sent PR https://github.com/keycloak/keycloak/pull/1726 with the > persistent changes for offline tokens according to what we discussed > with Stian. > > Summary: > > - Offline userSessions and clientSessiona are now stored in infinispan, > but also in DB. > > - DB storage is done through UserSessionPersisterProvider SPI. I've > added implementations based on JPA and Mongo. > > - When new offline userSession and clientSessions needs to be stored, it > is added to both infinispan and persistent storage through > UserSessionPersisterProvider. Revocation/removing of offline session is > also propagated to both infinispan and persister. > > - All requests to auth-server (ie. refreshing token etc) interacts with > infinispan storage. Persister is used just during startup to pre-load > infinispan storage with the sessions from DB. This allows that sessions > survive server restart. > > - New cache "offlineSessions" was added to the Infinispan. This is > separate to the "sessions" cache as both can have stored sessions with > same IDs, so this is to not clash with each other. > > - I've looked at how to best implement the pre-loading of infinispan > with the sessions from persister storage. The infinispan builtin > CacheStore/CacheLoader was my first attempt, however it turned to not > very good for various reasons (For example CacheStore SPI is > incompatible between Infinispan 5 and 6, same for the format of data > etc). In the end I used infinispan DistributionService > > http://infinispan.org/docs/5.0.x/user_guide/user_guide.html#_infinispan_distributed_execution_framework > . The impl is done in a way that parallel startup of cluster nodes is > not a problem, but an advantage as each cluster node prefills different > sessions. For example if you have 1000.000 userSessions in DB, the node1 > will preload around 500.000 sessions and node2 another 500.000 sessions. > If one of the nodes crashes at startup, it's not a problem as well, even > if it's coordinator node. Similarly when new node joins cluster when > other nodes are still starting and pre-loading, new node will > immediatelly start to help with pre-loading. I wonder we can reuse this > stuff for other long-running tasks as well (for example export/import of > big number of users at startup etc) > > - MemUserSessionProvider was updated too, so EAP 6.4 in local mode works > fine as well. > > - The persister saves offline sessions data into DB partially serialized > into JSON. Just the columns, which are needed for quick DB search (id, > realm_id, user_id, client_id) are saved as DB columns. I think this > should simplify migration and amount of needed work when new field is > added to UserSession / ClientSession. > > - It's possible to have more offline sessions / tokens per user+client > > > Still TODO: > > - Add "Offline token idle timeout" . The offline sessions not refreshed > during specified time will be cleared from both infinispan and storage. > Not sure about default value, 7 days? > I'd say more - 30 days? > > - Export/import of offline sessions. > > - Minor Juca's reported bug: https://issues.jboss.org/browse/KEYCLOAK-1959 > > - Reduce some INFO logging I've added > > - Maybe more if you have additional feedback? > > > I expect to have it done by Thursday. It seems I will need to postpone > some LDAP enhancements I planned for this release :/ > But none of them are critical. Still need to doublecheck export/import > and fix fuse for this release. > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/aa7a9d64/attachment.html From johan.heylen.public at gmail.com Wed Oct 14 07:36:14 2015 From: johan.heylen.public at gmail.com (Johan Heylen) Date: Wed, 14 Oct 2015 13:36:14 +0200 Subject: [keycloak-dev] Feature request: Include user (attributes) in FreeMarkerEmailProvider Message-ID: Hello, I have a feature request regarding some emails being sent out, like the password-reset mail. It currently looks like this: Your administrator has just requested that you update your account. Click on the link below to start this process. This link will expire within minutes. If you are unaware that your admin has requested this, just ignore this message and nothing will be changed. I would like to include the username, and the user full name, and have already figured out how to do this by updating the messages file and the *.ftl files in the email theme. But the list of attributes to be used is limited to what is provide through the implementation, and I would like to have it include the user as well. Either a few properties of the user or the full user resource, so I can use any field of the user. I know I can fix it by writing a custom module and loading it into my keycloak, overruling the default provider, with a one-liner: attributes.put("username", user.getUsername()); or attributes.put("user", user); but rather like to see this as the default behaviour, as this would increase the options of message customisation for everyone What do you guys think? Worthy of a JIRA ticket? I can organise a pull request if you need it. Kind regards, Johan Heylen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/dbb72b4f/attachment.html From sthorger at redhat.com Wed Oct 14 08:07:14 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Oct 2015 14:07:14 +0200 Subject: [keycloak-dev] Feature request: Include user (attributes) in FreeMarkerEmailProvider In-Reply-To: References: Message-ID: Sure create a jira, it's easy to add On 14 October 2015 at 13:36, Johan Heylen wrote: > Hello, > > I have a feature request regarding some emails being sent out, like the > password-reset mail. It currently looks like this: > > Your administrator has just requested that you update your > account. Click on the link below to start this process. > > > > This link will expire within minutes. > > If you are unaware that your admin has requested this, just ignore this > message and nothing will be changed. > > I would like to include the username, and the user full name, and have > already figured out how to do this by updating the messages file and the > *.ftl files in the email theme. > > But the list of attributes to be used is limited to what is provide > through the implementation, and I would like to have it include the user as > well. Either a few properties of the user or the full user resource, so I > can use any field of the user. > > I know I can fix it by writing a custom module and loading it into my > keycloak, overruling the default provider, with a one-liner: > > attributes.put("username", user.getUsername()); > > or > > attributes.put("user", user); > > but rather like to see this as the default behaviour, as this would > increase the options of message customisation for everyone > > What do you guys think? Worthy of a JIRA ticket? > > I can organise a pull request if you need it. > > > Kind regards, > > Johan Heylen > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/c2849dff/attachment.html From mposolda at redhat.com Wed Oct 14 08:39:49 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 14 Oct 2015 14:39:49 +0200 Subject: [keycloak-dev] Offline sessions persistence changes In-Reply-To: References: <561E2CD1.3040002@redhat.com> Message-ID: <561E4D15.9040601@redhat.com> Oki, I will do 30 days. Not really sure about best value, for example if someone restarts the server (or whole cluster) at least once per 30 days, the idle sessions won't never be cleared as restart updates lastSessionRefresh of persisted sessions in database too. However I suppose that people are not restarting that often in production (otherwise they can change timeout...) So going with 30 days. Marek On 14/10/15 13:20, Stian Thorgersen wrote: > > Still TODO: > > - Add "Offline token idle timeout" . The offline sessions not > refreshed > during specified time will be cleared from both infinispan and > storage. > Not sure about default value, 7 days? > > > I'd say more - 30 days? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/872b3130/attachment-0001.html From psilva at redhat.com Wed Oct 14 09:40:25 2015 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 14 Oct 2015 09:40:25 -0400 (EDT) Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: <1932006692.46216128.1444829886159.JavaMail.zimbra@redhat.com> Message-ID: <1630521586.46217988.1444830025050.JavaMail.zimbra@redhat.com> Hi, Would like to know your thoughts about which model implementations I must support for the authz model. Both Database/JPA and MongoDB ? Regards. Pedro Igor From bburke at redhat.com Wed Oct 14 11:44:54 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 14 Oct 2015 11:44:54 -0400 Subject: [keycloak-dev] cancel button added to OTP Message-ID: <561E7876.50302@redhat.com> FYI, I know we removed 'cancel' button from uername password and OTP, but I brought it back to the OTP page. User wanted ability to cancel login at OTP page if they decided they didn't want to login with that account. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From vramik at redhat.com Wed Oct 14 12:21:52 2015 From: vramik at redhat.com (Vlasta Ramik) Date: Wed, 14 Oct 2015 18:21:52 +0200 Subject: [keycloak-dev] model to representation in flows Message-ID: <561E8120.1000304@redhat.com> Hi, In Keycloak REST Service there is List > as a return type when you call GET /admin/realms/{realm}/authentication/flows. When you call GET /admin/realms/{realm}/clients or GET /admin/realms/{realm}/users there is list of corresponding representation. Representations are created https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UsersResource.java#L268 for users. Shouldn't be flows also converted from model to representation. Thanks, Vlasta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/7bf263db/attachment.html From bburke at redhat.com Wed Oct 14 12:23:29 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 14 Oct 2015 12:23:29 -0400 Subject: [keycloak-dev] model to representation in flows In-Reply-To: <561E8120.1000304@redhat.com> References: <561E8120.1000304@redhat.com> Message-ID: <561E8181.3060100@redhat.com> I was lazy. didn't create a separate authenticationflow rep class. Jackson will just marshal the properties if there are no jackson annotations. On 10/14/2015 12:21 PM, Vlasta Ramik wrote: > Hi, > > In Keycloak REST Service there is List > > > as a return type when you call GET > /admin/realms/{realm}/authentication/flows. > > When you call GET /admin/realms/{realm}/clients or GET > /admin/realms/{realm}/users there is list of corresponding representation. > > Representations are created > https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UsersResource.java#L268 > for users. > > Shouldn't be flows also converted from model to representation. > > Thanks, > Vlasta > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From d.rami85 at gmail.com Wed Oct 14 12:35:32 2015 From: d.rami85 at gmail.com (=?UTF-8?Q?David_Ram=C3=ADrez?=) Date: Wed, 14 Oct 2015 18:35:32 +0200 Subject: [keycloak-dev] Keycloak doubts Message-ID: Hi guys, I'm new with Keyloack server, after read the official documentation I have a couple of questions. Following the Oauth2 flow: +--------+ +---------------+ | |--(A)------- Authorization Grant --------->| | | | | | | |<-(B)----------- Access Token -------------| | | | & Refresh Token | | | | | | | | +----------+ | | | |--(C)---- Access Token ---->| | | | | | | | | | | |<-(D)- Protected Resource --| Resource | | Authorization | | Client | | Server | | Server | | |--(E)---- Access Token ---->| | | | | | | | | | | |<-(F)- Invalid Token Error -| | | | | | +----------+ | | | | | | | |--(G)----------- Refresh Token ----------->| | | | | | | |<-(H)----------- Access Token -------------| | +--------+ & Optional Refresh Token +---------------+ are 'Client' and 'Resource Server' Keycloaks' clients? For example, I have an Android App and a Service (Java Rest service), should both be registered in Keycloak Server like clients? The last question is about Refresh token. When I'm authenticated for achieving an access token through 'http://localhost:8080/auth/realms/demo/protocol/openid-connect/token', I received a refresh token too. If I try to get a protected resource by the refresh token I will get access to it... Why is it possible? I thought that refresh token was only for generate new access token. I'm a bit confussed. I will appreciate any help, thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/891632eb/attachment.html From mposolda at redhat.com Wed Oct 14 12:57:12 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 14 Oct 2015 18:57:12 +0200 Subject: [keycloak-dev] Keycloak doubts In-Reply-To: References: Message-ID: <561E8968.2020001@redhat.com> On 14/10/15 18:35, David Ram?rez wrote: > > Hi guys, > > I'm new with Keyloack server, after read the official documentation I > have a couple of questions. > > Following the Oauth2 flow: > > +--------+ +---------------+ > | |--(A)------- Authorization Grant --------->| | > | | | | > | |<-(B)----------- Access Token -------------| | > | | & Refresh Token | | > | | | | > | | +----------+ | | > | |--(C)---- Access Token ---->| | | | > | | | | | | > | |<-(D)- Protected Resource --| Resource | | Authorization | > | Client | | Server | | Server | > | |--(E)---- Access Token ---->| | | | > | | | | | | > | |<-(F)- Invalid Token Error -| | | | > | | +----------+ | | > | | | | > | |--(G)----------- Refresh Token ----------->| | > | | | | > | |<-(H)----------- Access Token -------------| | > +--------+ & Optional Refresh Token +---------------+ > > > are 'Client' and 'Resource Server' Keycloaks' clients? > For example, I have an Android App and a Service (Java Rest service), should both be registered in Keycloak Server like clients? Yes. Theoretically it's not needed to register your REST Service as Keycloak client, but it's useful for various reasons. For example you will be able to propagate admin events from KC admin console to it, like push not-before policy. > The last question is about Refresh token. > When I'm authenticated for achieving an access token through 'http://localhost:8080/auth/realms/demo/protocol/openid-connect/token', I received a refresh token too. > If I try to get a protected resource by the refresh token I will get access to it... Why is it possible? I thought that refresh token was only for generate new access token. I'm a bit confussed. It's bug, which is fixed in latest master and will be in 1.6 release. Marek > I will appreciate any help, thanks. > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/cd06a403/attachment-0001.html From bburke at redhat.com Wed Oct 14 12:58:47 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 14 Oct 2015 12:58:47 -0400 Subject: [keycloak-dev] browser refresh and back button issues Message-ID: <561E89C7.4030004@redhat.com> I've been looking into a couple of "browser refresh" bugs. Currently, if an HTTP request to the auth flow spi did not match the state of the client session you would a) have the flow reset if you were currently in the process of authenticating b) Show an error screen if you aren't currently authenticating (i.e. performing required actions) Now I remember why I did it this way. It is impossible to detect the difference between a browser refresh and somebody hitting the back button and resubmitting a previous form. Hitting "browser refresh" will resubmit any previous form POST. So, you have no idea if the user is refreshing the current page or resubmitting after a browser back button. So, I think it is best to keep things the way it is now. Thoughts? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Wed Oct 14 13:20:52 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Oct 2015 19:20:52 +0200 Subject: [keycloak-dev] browser refresh and back button issues In-Reply-To: <561E89C7.4030004@redhat.com> References: <561E89C7.4030004@redhat.com> Message-ID: I think a) is ok, but not the ideal. b) however is problematic IMO. In the case of required actions, why not just display the next required action associated with the user? That would be the equivalent of a. There's also another bug related to this which is that if you try to change the language on a page in the middle of the auth flow it blows up. On 14 October 2015 at 18:58, Bill Burke wrote: > I've been looking into a couple of "browser refresh" bugs. Currently, > if an HTTP request to the auth flow spi did not match the state of the > client session you would > > a) have the flow reset if you were currently in the process of > authenticating > b) Show an error screen if you aren't currently authenticating (i.e. > performing required actions) > > Now I remember why I did it this way. It is impossible to detect the > difference between a browser refresh and somebody hitting the back > button and resubmitting a previous form. Hitting "browser refresh" will > resubmit any previous form POST. So, you have no idea if the user is > refreshing the current page or resubmitting after a browser back button. > > So, I think it is best to keep things the way it is now. Thoughts? > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/09bd2af0/attachment.html From d.rami85 at gmail.com Wed Oct 14 13:31:03 2015 From: d.rami85 at gmail.com (=?UTF-8?Q?David_Ram=C3=ADrez?=) Date: Wed, 14 Oct 2015 19:31:03 +0200 Subject: [keycloak-dev] Keycloak doubts In-Reply-To: <561E8968.2020001@redhat.com> References: <561E8968.2020001@redhat.com> Message-ID: Thanks Marek! 2015-10-14 18:57 GMT+02:00 Marek Posolda : > On 14/10/15 18:35, David Ram?rez wrote: > > Hi guys, > > I'm new with Keyloack server, after read the official documentation I have > a couple of questions. > > Following the Oauth2 flow: > > +--------+ +---------------+ > | |--(A)------- Authorization Grant --------->| | > | | | | > | |<-(B)----------- Access Token -------------| | > | | & Refresh Token | | > | | | | > | | +----------+ | | > | |--(C)---- Access Token ---->| | | | > | | | | | | > | |<-(D)- Protected Resource --| Resource | | Authorization | > | Client | | Server | | Server | > | |--(E)---- Access Token ---->| | | | > | | | | | | > | |<-(F)- Invalid Token Error -| | | | > | | +----------+ | | > | | | | > | |--(G)----------- Refresh Token ----------->| | > | | | | > | |<-(H)----------- Access Token -------------| | > +--------+ & Optional Refresh Token +---------------+ > > > > are 'Client' and 'Resource Server' Keycloaks' clients? > > For example, I have an Android App and a Service (Java Rest service), should both be registered in Keycloak Server like clients? > > Yes. Theoretically it's not needed to register your REST Service as > Keycloak client, but it's useful for various reasons. For example you will > be able to propagate admin events from KC admin console to it, like push > not-before policy. > > The last question is about Refresh token. > > When I'm authenticated for achieving an access token through 'http://localhost:8080/auth/realms/demo/protocol/openid-connect/token', I received a refresh token too. > > If I try to get a protected resource by the refresh token I will get access to it... Why is it possible? I thought that refresh token was only for generate new access token. I'm a bit confussed. > > It's bug, which is fixed in latest master and will be in 1.6 release. > > Marek > > I will appreciate any help, thanks. > > > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/39f49adc/attachment.html From sthorger at redhat.com Wed Oct 14 14:24:27 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 14 Oct 2015 20:24:27 +0200 Subject: [keycloak-dev] Refresh tokens no longer reusable Message-ID: Refresh tokens are no longer reusable. This is done by setting the client sessions timestamp when a new refresh token is issued. If the refresh tokens iat value is less than the client sessions timestamp it's not permitted. If anyone has time I'd appreciate a review of the changes: https://github.com/keycloak/keycloak/pull/1732 For anyone that runs into issues with this policy there's an option to disable it in the admin console in the realms token settings. This does not apply to offline tokens (at least yet). We need to add it to offline tokens as well though as it's even more important for those. There's two problems with offline tokens though, firstly the setTimestamp is not permitted on offline client sessions. Secondly if we allow setting it we would have to persist it, unless someone can come up with something clever. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/952078ad/attachment.html From mposolda at redhat.com Wed Oct 14 17:49:06 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 14 Oct 2015 23:49:06 +0200 Subject: [keycloak-dev] Refresh tokens no longer reusable In-Reply-To: References: Message-ID: <561ECDD2.8020601@redhat.com> On 14/10/15 20:24, Stian Thorgersen wrote: > Refresh tokens are no longer reusable. This is done by setting the > client sessions timestamp when a new refresh token is issued. If the > refresh tokens iat value is less than the client sessions timestamp > it's not permitted. > > If anyone has time I'd appreciate a review of the changes: > https://github.com/keycloak/keycloak/pull/1732 > > For anyone that runs into issues with this policy there's an option to > disable it in the admin console in the realms token settings. > > This does not apply to offline tokens (at least yet). We need to add > it to offline tokens as well though as it's even more important for > those. There's two problems with offline tokens though, firstly the > setTimestamp is not permitted on offline client sessions. Secondly if > we allow setting it we would have to persist it, unless someone can > come up with something clever. I think we don't need to persist, but just save clientSession with updated timestamp into infinispan/memory. Then during startup, the timestamp of clientSessions will be updated to startup time similarly like we have for lastSessionRefresh of user sessions. The refresh will be allowed if (iat == clientSession.timestamp OR startupTime == clientSession.timestamp) . In other words, first refresh after server restart will be always allowed. There is some chance that there can be same refresh token used two times (if attacker will do second refresh after server restart). But then clientSession timestamp will be updated and regular user won't be allowed to refresh his token and will recognize error. But question is, do we really want refreshTokenReusable to be disabled by default? For offline tokens, people will often need to save the offline token into their database on application side. With refreshTokenReusable disabled, they will need to always write into their DB and save new offline token after each refresh. Marek > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151014/ff366f71/attachment-0001.html From bburke at redhat.com Wed Oct 14 19:27:51 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 14 Oct 2015 19:27:51 -0400 Subject: [keycloak-dev] Refresh tokens no longer reusable In-Reply-To: <561ECDD2.8020601@redhat.com> References: <561ECDD2.8020601@redhat.com> Message-ID: <561EE4F7.8070002@redhat.com> On 10/14/2015 5:49 PM, Marek Posolda wrote: > On 14/10/15 20:24, Stian Thorgersen wrote: >> Refresh tokens are no longer reusable. This is done by setting the >> client sessions timestamp when a new refresh token is issued. If the >> refresh tokens iat value is less than the client sessions timestamp >> it's not permitted. >> >> If anyone has time I'd appreciate a review of the changes: >> https://github.com/keycloak/keycloak/pull/1732 >> >> For anyone that runs into issues with this policy there's an option to >> disable it in the admin console in the realms token settings. >> >> This does not apply to offline tokens (at least yet). We need to add >> it to offline tokens as well though as it's even more important for >> those. There's two problems with offline tokens though, firstly the >> setTimestamp is not permitted on offline client sessions. Secondly if >> we allow setting it we would have to persist it, unless someone can >> come up with something clever. > I think we don't need to persist, but just save clientSession with > updated timestamp into infinispan/memory. Then during startup, the > timestamp of clientSessions will be updated to startup time similarly > like we have for lastSessionRefresh of user sessions. The refresh will > be allowed if (iat == clientSession.timestamp OR startupTime == > clientSession.timestamp) . In other words, first refresh after server > restart will be always allowed. > > There is some chance that there can be same refresh token used two > times (if attacker will do second refresh after server restart). But > then clientSession timestamp will be updated and regular user won't be > allowed to refresh his token and will recognize error. > > > But question is, do we really want refreshTokenReusable to be disabled > by default? For offline tokens, people will often need to save the > offline token into their database on application side. With > refreshTokenReusable disabled, they will need to always write into their > DB and save new offline token after each refresh. > My own personal opinion is that we are making this fix to pass some random company's security audit that I don't particularly agree with. If a client has been compromised, then its offline tokens should be revoked and a revocation not-before policy should be pushed out. As it is, the only reason we need to regenerate the refresh token is to update its timestamp for idle checks. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Thu Oct 15 00:36:57 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 15 Oct 2015 06:36:57 +0200 Subject: [keycloak-dev] Refresh tokens no longer reusable In-Reply-To: <561EE4F7.8070002@redhat.com> References: <561ECDD2.8020601@redhat.com> <561EE4F7.8070002@redhat.com> Message-ID: That was my initial idea as well, but then again it already works with our adapters, we already regenerate the tokens, so why not add this extra layer of defence? End of the day as refresh tokens can be stored on the client side how well they are secured can vary. If users want long sessions or even worse with offline tokens it makes sense to add this that enables users to at least notice something is going wrong. The issue is that you may not notice that a client has been compromised, but if all tokens stop working you will. I don't have an issue with setting it to true by default (so refresh tokens are reusable), but since our adapters already work and I can't see any big side effects of preventing refresh token reuse I set it to false by default. On 15 October 2015 at 01:27, Bill Burke wrote: > > > On 10/14/2015 5:49 PM, Marek Posolda wrote: > > On 14/10/15 20:24, Stian Thorgersen wrote: > >> Refresh tokens are no longer reusable. This is done by setting the > >> client sessions timestamp when a new refresh token is issued. If the > >> refresh tokens iat value is less than the client sessions timestamp > >> it's not permitted. > >> > >> If anyone has time I'd appreciate a review of the changes: > >> > https://github.com/keycloak/keycloak/pull/1732 > >> > >> For anyone that runs into issues with this policy there's an option to > >> disable it in the admin console in the realms token settings. > >> > >> This does not apply to offline tokens (at least yet). We need to add > >> it to offline tokens as well though as it's even more important for > >> those. There's two problems with offline tokens though, firstly the > >> setTimestamp is not permitted on offline client sessions. Secondly if > >> we allow setting it we would have to persist it, unless someone can > >> come up with something clever. > > I think we don't need to persist, but just save clientSession with > > updated timestamp into infinispan/memory. Then during startup, the > > timestamp of clientSessions will be updated to startup time similarly > > like we have for lastSessionRefresh of user sessions. The refresh will > > be allowed if (iat == clientSession.timestamp OR startupTime == > > clientSession.timestamp) . In other words, first refresh after server > > restart will be always allowed. > > > > There is some chance that there can be same refresh token used two > > times (if attacker will do second refresh after server restart). But > > then clientSession timestamp will be updated and regular user won't be > > allowed to refresh his token and will recognize error. > > > > > > But question is, do we really want refreshTokenReusable to be disabled > > by default? For offline tokens, people will often need to save the > > offline token into their database on application side. With > > refreshTokenReusable disabled, they will need to always write into their > > DB and save new offline token after each refresh. > > > > My own personal opinion is that we are making this fix to pass some > random company's security audit that I don't particularly agree with. > If a client has been compromised, then its offline tokens should be > revoked and a revocation not-before policy should be pushed out. As it > is, the only reason we need to regenerate the refresh token is to update > its timestamp for idle checks. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151015/5867dc95/attachment.html From sthorger at redhat.com Thu Oct 15 01:44:40 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 15 Oct 2015 07:44:40 +0200 Subject: [keycloak-dev] IDs/names for Mapper Type Properties In-Reply-To: References: Message-ID: Hi, 2 or 3 is not good options. Both would take a fair bit of time to add and would have migration issues. 1 would probably work, we could add a simple directive that can transform a string into a form that can be used in the name attribute. However, in this case I think it's better to just use an XPath expression. As the test would be the thing to add the mapper and set the name in the first place it should be consistent. Especially if you'd add a id to the table and just look for the name within that table. On 2 October 2015 at 19:36, Vaclav Muzikar wrote: > Hi all, > I'd like to discuss missing @id and @name attributes on UI elements of > Mapper Type Properties (related issue: > https://issues.jboss.org/browse/KEYCLOAK-1885). > This concerns e.g. creating/editing a Client Protocol Mapper. When you > choose the Mapper Type, the following properties (like "Token Claim Name" > in case of "Hardcoded Claim") don't have any @id or @name. > This properties are used on more places all over the Keycloak (the > template is "kc-provider-config.html" in "keycloak-forms-common-themes" > module). > > At QE we'd like to add @id for every of these elements so we don't need to > use relative XPath locators based on labels, AngularJS > directives/attributes etc. which could be unstable. > > The problem is there's no suitable (object) attribute of these properties > to use as HTML @id or @name. > The closest thing to this is the mapperType.property.name but it's using > illegal characters (spaces) for @id in some cases. E.g. "Claim value" uses > the "claim.value" name which is OK but "Claim JSON Type" uses "Claim JSON > Type" name (yes, the name is same as the label) which can't be used in HTML > as @id because of spaces. > > I've got some solutions on my mind. > > *1) Replacing the spaces on the client site (using AngularJS controllers)* which > is probably not a nice solution. The Mapper Types (and it's properties) are > used on more than one sites/controllers and I haven't found any global > getter or something like that for Mapper Types which could contain this > replacement code. As far as I know, Mapper Types are fetched using > ServerInfo service. But this service is pretty abstract and simple so I > don't think it's a good idea to do the replacement there. > That means we need to add some getter and rewrite the controllers to use > this getter or copy-paste the replacement code all over the controllers > which is obviously out of the question. > > *2) Add a new ID attribute to the REST API* so the ServerInfo service > would distribute this attribute to all controllers and templates. > > *3) Change the "name" attributes* so it can be used as @id. Possible > problem could be compatibility and migration of > current Keycloak installations to the newer version. > > Can come upon any other solution? Could you implement any of it? > > Thank you! > > Best regards, > V?clav Muzik?? > Keycloak QE > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151015/4f91ceac/attachment.html From mposolda at redhat.com Thu Oct 15 02:44:38 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 15 Oct 2015 08:44:38 +0200 Subject: [keycloak-dev] Refresh tokens no longer reusable In-Reply-To: References: <561ECDD2.8020601@redhat.com> <561EE4F7.8070002@redhat.com> Message-ID: <561F4B56.4010808@redhat.com> On 15/10/15 06:36, Stian Thorgersen wrote: > That was my initial idea as well, but then again it already works with > our adapters, we already regenerate the tokens, so why not add this > extra layer of defence? End of the day as refresh tokens can be stored > on the client side how well they are secured can vary. If users want > long sessions or even worse with offline tokens it makes sense to add > this that enables users to at least notice something is going wrong. > The issue is that you may not notice that a client has been > compromised, but if all tokens stop working you will. > > I don't have an issue with setting it to true by default (so refresh > tokens are reusable), but since our adapters already work and I can't > see any big side effects of preventing refresh token reuse I set it to > false by default. As I said, I can see the side effect just for offline tokens, that people will always need to write new offline token into their DB on application side after each refresh. Marek > > On 15 October 2015 at 01:27, Bill Burke > wrote: > > > > On 10/14/2015 5:49 PM, Marek Posolda wrote: > > On 14/10/15 20:24, Stian Thorgersen wrote: > >> Refresh tokens are no longer reusable. This is done by setting the > >> client sessions timestamp when a new refresh token is issued. > If the > >> refresh tokens iat value is less than the client sessions timestamp > >> it's not permitted. > >> > >> If anyone has time I'd appreciate a review of the changes: > >> > https://github.com/keycloak/keycloak/pull/1732 > >> > >> For anyone that runs into issues with this policy there's an > option to > >> disable it in the admin console in the realms token settings. > >> > >> This does not apply to offline tokens (at least yet). We need > to add > >> it to offline tokens as well though as it's even more important for > >> those. There's two problems with offline tokens though, firstly the > >> setTimestamp is not permitted on offline client sessions. > Secondly if > >> we allow setting it we would have to persist it, unless someone can > >> come up with something clever. > refreshTokenReusable > I think we don't need to persist, but just > save clientSession with > > updated timestamp into infinispan/memory. Then during startup, the > > timestamp of clientSessions will be updated to startup time > similarly > > like we have for lastSessionRefresh of user sessions. The > refresh will > > be allowed if (iat == clientSession.timestamp OR startupTime == > > clientSession.timestamp) . In other words, first refresh after > server > > restart will be always allowed. > > > > There is some chance that there can be same refresh token used two > > times (if attacker will do second refresh after server restart). But > > then clientSession timestamp will be updated and regular user > won't be > > allowed to refresh his token and will recognize error. > > > > > > But question is, do we really want refreshTokenReusable to be > disabled > > by default? For offline tokens, people will often need to save the > > offline token into their database on application side. With > > refreshTokenReusable disabled, they will need to always write > into their > > DB and save new offline token after each refresh. > > > > My own personal opinion is that we are making this fix to pass some > random company's security audit that I don't particularly agree with. > If a client has been compromised, then its offline tokens should be > revoked and a revocation not-before policy should be pushed out. > As it > is, the only reason we need to regenerate the refresh token is to > update > its timestamp for idle checks.refreshTokenReusable > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151015/ac3dcd1f/attachment-0001.html From sthorger at redhat.com Thu Oct 15 02:49:16 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 15 Oct 2015 08:49:16 +0200 Subject: [keycloak-dev] Refresh tokens no longer reusable In-Reply-To: <561F4B56.4010808@redhat.com> References: <561ECDD2.8020601@redhat.com> <561EE4F7.8070002@redhat.com> <561F4B56.4010808@redhat.com> Message-ID: On 15 October 2015 at 08:44, Marek Posolda wrote: > On 15/10/15 06:36, Stian Thorgersen wrote: > > That was my initial idea as well, but then again it already works with our > adapters, we already regenerate the tokens, so why not add this extra layer > of defence? End of the day as refresh tokens can be stored on the client > side how well they are secured can vary. If users want long sessions or > even worse with offline tokens it makes sense to add this that enables > users to at least notice something is going wrong. The issue is that you > may not notice that a client has been compromised, but if all tokens stop > working you will. > > > I don't have an issue with setting it to true by default (so refresh > tokens are reusable), but since our adapters already work and I can't see > any big side effects of preventing refresh token reuse I set it to false by > default. > > As I said, I can see the side effect just for offline tokens, that people > will always need to write new offline token into their DB on application > side after each refresh. > Thing is for offline tokens it's even more important to block old tokens, so would it not make sense to have it on by default as a security measure? > > Marek > > > On 15 October 2015 at 01:27, Bill Burke wrote: > >> >> >> On 10/14/2015 5:49 PM, Marek Posolda wrote: >> > On 14/10/15 20:24, Stian Thorgersen wrote: >> >> Refresh tokens are no longer reusable. This is done by setting the >> >> client sessions timestamp when a new refresh token is issued. If the >> >> refresh tokens iat value is less than the client sessions timestamp >> >> it's not permitted. >> >> >> >> If anyone has time I'd appreciate a review of the changes: >> >> >> >> https://github.com/keycloak/keycloak/pull/1732 >> >> >> >> For anyone that runs into issues with this policy there's an option to >> >> disable it in the admin console in the realms token settings. >> >> >> >> This does not apply to offline tokens (at least yet). We need to add >> >> it to offline tokens as well though as it's even more important for >> >> those. There's two problems with offline tokens though, firstly the >> >> setTimestamp is not permitted on offline client sessions. Secondly if >> >> we allow setting it we would have to persist it, unless someone can >> >> come up with something clever. >> refreshTokenReusable > I think we don't need to persist, but just save >> clientSession with >> > updated timestamp into infinispan/memory. Then during startup, the >> > timestamp of clientSessions will be updated to startup time similarly >> > like we have for lastSessionRefresh of user sessions. The refresh will >> > be allowed if (iat == clientSession.timestamp OR startupTime == >> > clientSession.timestamp) . In other words, first refresh after server >> > restart will be always allowed. >> > >> > There is some chance that there can be same refresh token used two >> > times (if attacker will do second refresh after server restart). But >> > then clientSession timestamp will be updated and regular user won't be >> > allowed to refresh his token and will recognize error. >> > >> > >> > But question is, do we really want refreshTokenReusable to be disabled >> > by default? For offline tokens, people will often need to save the >> > offline token into their database on application side. With >> > refreshTokenReusable disabled, they will need to always write into their >> > DB and save new offline token after each refresh. >> > >> >> My own personal opinion is that we are making this fix to pass some >> random company's security audit that I don't particularly agree with. >> If a client has been compromised, then its offline tokens should be >> revoked and a revocation not-before policy should be pushed out. As it >> is, the only reason we need to regenerate the refresh token is to update >> its timestamp for idle checks.refreshTokenReusable >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151015/8440cd36/attachment.html From sthorger at redhat.com Thu Oct 15 02:53:02 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 15 Oct 2015 08:53:02 +0200 Subject: [keycloak-dev] Refresh tokens no longer reusable In-Reply-To: References: <561ECDD2.8020601@redhat.com> <561EE4F7.8070002@redhat.com> <561F4B56.4010808@redhat.com> Message-ID: A small extract from OAuth2 spec: The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client. If a new refresh token is issued, the refresh token scope MUST be identical to that of the refresh token included by the client in the request. Revoking old refresh tokens is optional. With that in mind and the fact that we didn't use to revoke old refresh tokens my vote goes to the default is not to revoke old refresh tokens, but still have the option to enable this for those that want to. I'm going to change it to that. On 15 October 2015 at 08:49, Stian Thorgersen wrote: > > > On 15 October 2015 at 08:44, Marek Posolda wrote: > >> On 15/10/15 06:36, Stian Thorgersen wrote: >> >> That was my initial idea as well, but then again it already works with >> our adapters, we already regenerate the tokens, so why not add this extra >> layer of defence? End of the day as refresh tokens can be stored on the >> client side how well they are secured can vary. If users want long sessions >> or even worse with offline tokens it makes sense to add this that enables >> users to at least notice something is going wrong. The issue is that you >> may not notice that a client has been compromised, but if all tokens stop >> working you will. >> >> >> I don't have an issue with setting it to true by default (so refresh >> tokens are reusable), but since our adapters already work and I can't see >> any big side effects of preventing refresh token reuse I set it to false by >> default. >> >> As I said, I can see the side effect just for offline tokens, that people >> will always need to write new offline token into their DB on application >> side after each refresh. >> > > Thing is for offline tokens it's even more important to block old tokens, > so would it not make sense to have it on by default as a security measure? > > >> >> Marek >> >> >> On 15 October 2015 at 01:27, Bill Burke wrote: >> >>> >>> >>> On 10/14/2015 5:49 PM, Marek Posolda wrote: >>> > On 14/10/15 20:24, Stian Thorgersen wrote: >>> >> Refresh tokens are no longer reusable. This is done by setting the >>> >> client sessions timestamp when a new refresh token is issued. If the >>> >> refresh tokens iat value is less than the client sessions timestamp >>> >> it's not permitted. >>> >> >>> >> If anyone has time I'd appreciate a review of the changes: >>> >> >>> >>> https://github.com/keycloak/keycloak/pull/1732 >>> >> >>> >> For anyone that runs into issues with this policy there's an option to >>> >> disable it in the admin console in the realms token settings. >>> >> >>> >> This does not apply to offline tokens (at least yet). We need to add >>> >> it to offline tokens as well though as it's even more important for >>> >> those. There's two problems with offline tokens though, firstly the >>> >> setTimestamp is not permitted on offline client sessions. Secondly if >>> >> we allow setting it we would have to persist it, unless someone can >>> >> come up with something clever. >>> refreshTokenReusable > I think we don't need to persist, but just save >>> clientSession with >>> > updated timestamp into infinispan/memory. Then during startup, the >>> > timestamp of clientSessions will be updated to startup time similarly >>> > like we have for lastSessionRefresh of user sessions. The refresh will >>> > be allowed if (iat == clientSession.timestamp OR startupTime == >>> > clientSession.timestamp) . In other words, first refresh after server >>> > restart will be always allowed. >>> > >>> > There is some chance that there can be same refresh token used two >>> > times (if attacker will do second refresh after server restart). But >>> > then clientSession timestamp will be updated and regular user won't be >>> > allowed to refresh his token and will recognize error. >>> > >>> > >>> > But question is, do we really want refreshTokenReusable to be disabled >>> > by default? For offline tokens, people will often need to save the >>> > offline token into their database on application side. With >>> > refreshTokenReusable disabled, they will need to always write into >>> their >>> > DB and save new offline token after each refresh. >>> > >>> >>> My own personal opinion is that we are making this fix to pass some >>> random company's security audit that I don't particularly agree with. >>> If a client has been compromised, then its offline tokens should be >>> revoked and a revocation not-before policy should be pushed out. As it >>> is, the only reason we need to regenerate the refresh token is to update >>> its timestamp for idle checks.refreshTokenReusable >>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151015/dfbbc129/attachment-0001.html From gerbermichi at me.com Thu Oct 15 03:26:32 2015 From: gerbermichi at me.com (Michael Gerber) Date: Thu, 15 Oct 2015 07:26:32 +0000 (GMT) Subject: [keycloak-dev] failed authentication: USER_CONFLICT Message-ID: <64cfe96a-ecb3-4d4e-90f8-98655d7e7b61@me.com> Hi all, I get the following error if I try to log in as user1 with a wrong password and then as user2 with a correct password. 2015-10-15 09:05:58,605 ERROR [org.keycloak.authentication.AuthenticationProcessor] (default task-24) failed authentication: USER_CONFLICT: org.keycloak.authentication.AuthenticationFlowException at org.keycloak.authentication.AuthenticationProcessor.setAutheticatedUser(AuthenticationProcessor.java:203) [keycloak-services-1.6.0.Final-SNAPSHOT.jar:1.6.0.Final-SNAPSHOT] at org.keycloak.authentication.AuthenticationProcessor$Result.setUser(AuthenticationProcessor.java:332) [keycloak-services-1.6.0.Final-SNAPSHOT.jar:1.6.0.Final-SNAPSHOT] I think the reason for that is the context.setUser(user) call in the?AbstractUsernameFormAuthenticator.validateUser method. Is this on purpose? Best Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151015/2d9e702a/attachment.html From mposolda at redhat.com Thu Oct 15 03:31:43 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 15 Oct 2015 09:31:43 +0200 Subject: [keycloak-dev] Refresh tokens no longer reusable In-Reply-To: References: <561ECDD2.8020601@redhat.com> <561EE4F7.8070002@redhat.com> <561F4B56.4010808@redhat.com> Message-ID: <561F565F.3070605@redhat.com> On 15/10/15 08:53, Stian Thorgersen wrote: > A small extract from OAuth2 spec: > > The authorization server MAY issue a new refresh token, in which case > the client MUST discard the old refresh token and replace it with the > new refresh token. The authorization server MAY revoke the old > refresh token after issuing a new refresh token to the client. If a > new refresh token is issued, the refresh token scope MUST be > identical to that of the refresh token included by the client in the > request. > Revoking old refresh tokens is optional. With that in mind and the > fact that we didn't use to revoke old refresh tokens my vote goes to > the default is not to revoke old refresh tokens, but still have the > option to enable this for those that want to. I'm going to change it > to that. +1 Marek > > On 15 October 2015 at 08:49, Stian Thorgersen > wrote: > > > > On 15 October 2015 at 08:44, Marek Posolda > wrote: > > On 15/10/15 06:36, Stian Thorgersen wrote: >> That was my initial idea as well, but then again it already >> works with our adapters, we already regenerate the tokens, so >> why not add this extra layer of defence? End of the day as >> refresh tokens can be stored on the client side how well they >> are secured can vary. If users want long sessions or even >> worse with offline tokens it makes sense to add this that >> enables users to at least notice something is going wrong. >> The issue is that you may not notice that a client has been >> compromised, but if all tokens stop working you will. >> >> I don't have an issue with setting it to true by default (so >> refresh tokens are reusable), but since our adapters already >> work and I can't see any big side effects of preventing >> refresh token reuse I set it to false by default. > As I said, I can see the side effect just for offline tokens, > that people will always need to write new offline token into > their DB on application side after each refresh. > > > Thing is for offline tokens it's even more important to block old > tokens, so would it not make sense to have it on by default as a > security measure? > > > Marek >> >> On 15 October 2015 at 01:27, Bill Burke > > wrote: >> >> >> >> On 10/14/2015 5:49 PM, Marek Posolda wrote: >> > On 14/10/15 20:24, Stian Thorgersen wrote: >> >> Refresh tokens are no longer reusable. This is done by >> setting the >> >> client sessions timestamp when a new refresh token is >> issued. If the >> >> refresh tokens iat value is less than the client >> sessions timestamp >> >> it's not permitted. >> >> >> >> If anyone has time I'd appreciate a review of the changes: >> >> https://github.com/keycloak/keycloak/pull/1732 >> >> >> >> For anyone that runs into issues with this policy >> there's an option to >> >> disable it in the admin console in the realms token >> settings. >> >> >> >> This does not apply to offline tokens (at least yet). >> We need to add >> >> it to offline tokens as well though as it's even more >> important for >> >> those. There's two problems with offline tokens >> though, firstly the >> >> setTimestamp is not permitted on offline client >> sessions. Secondly if >> >> we allow setting it we would have to persist it, >> unless someone can >> >> come up with something clever. >> refreshTokenReusable > I think we don't need to persist, >> but just save clientSession with >> > updated timestamp into infinispan/memory. Then during >> startup, the >> > timestamp of clientSessions will be updated to startup >> time similarly >> > like we have for lastSessionRefresh of user sessions. >> The refresh will >> > be allowed if (iat == clientSession.timestamp OR >> startupTime == >> > clientSession.timestamp) . In other words, first >> refresh after server >> > restart will be always allowed. >> > >> > There is some chance that there can be same refresh >> token used two >> > times (if attacker will do second refresh after server >> restart). But >> > then clientSession timestamp will be updated and >> regular user won't be >> > allowed to refresh his token and will recognize error. >> > >> > >> > But question is, do we really want refreshTokenReusable >> to be disabled >> > by default? For offline tokens, people will often need >> to save the >> > offline token into their database on application side. With >> > refreshTokenReusable disabled, they will need to always >> write into their >> > DB and save new offline token after each refresh. >> > >> >> My own personal opinion is that we are making this fix to >> pass some >> random company's security audit that I don't particularly >> agree with. >> If a client has been compromised, then its offline tokens >> should be >> revoked and a revocation not-before policy should be >> pushed out. As it >> is, the only reason we need to regenerate the refresh >> token is to update >> its timestamp for idle checks.refreshTokenReusable >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151015/a62f9a22/attachment-0001.html From vramik at redhat.com Thu Oct 15 05:06:30 2015 From: vramik at redhat.com (Vlasta Ramik) Date: Thu, 15 Oct 2015 11:06:30 +0200 Subject: [keycloak-dev] model to representation in flows In-Reply-To: <561E8181.3060100@redhat.com> References: <561E8120.1000304@redhat.com> <561E8181.3060100@redhat.com> Message-ID: <561F6C96.3070808@redhat.com> Ok, I've created https://issues.jboss.org/browse/KEYCLOAK-1966 for this. Vlasta On 10/14/2015 06:23 PM, Bill Burke wrote: > I was lazy. didn't create a separate authenticationflow rep class. > Jackson will just marshal the properties if there are no jackson > annotations. > > On 10/14/2015 12:21 PM, Vlasta Ramik wrote: >> Hi, >> >> In Keycloak REST Service there is List >> > > >> as a return type when you call GET >> /admin/realms/{realm}/authentication/flows. >> >> When you call GET /admin/realms/{realm}/clients or GET >> /admin/realms/{realm}/users there is list of corresponding representation. >> >> Representations are created >> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/UsersResource.java#L268 >> for users. >> >> Shouldn't be flows also converted from model to representation. >> >> Thanks, >> Vlasta >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Thu Oct 15 09:20:08 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 15 Oct 2015 09:20:08 -0400 Subject: [keycloak-dev] browser refresh and back button issues In-Reply-To: References: <561E89C7.4030004@redhat.com> Message-ID: <561FA808.90706@redhat.com> I'm working on a solution for this stuff. For browser flows I'm going to do a 302 redirect after successful posts. I'm also going to do a 302 redirect after authentication and before going into the required-actions phase. This will get the browser to a "safe" URL that if refresh button is hit, the flow manager can decide what the correct state is. Back button will still result in an error screen though. On 10/14/2015 1:20 PM, Stian Thorgersen wrote: > I think a) is ok, but not the ideal. > > b) however is problematic IMO. In the case of required actions, why not > just display the next required action associated with the user? That > would be the equivalent of a. > > There's also another bug related to this which is that if you try to > change the language on a page in the middle of the auth flow it blows up. > > On 14 October 2015 at 18:58, Bill Burke > wrote: > > I've been looking into a couple of "browser refresh" bugs. Currently, > if an HTTP request to the auth flow spi did not match the state of the > client session you would > > a) have the flow reset if you were currently in the process of > authenticating > b) Show an error screen if you aren't currently authenticating (i.e. > performing required actions) > > Now I remember why I did it this way. It is impossible to detect the > difference between a browser refresh and somebody hitting the back > button and resubmitting a previous form. Hitting "browser refresh" will > resubmit any previous form POST. So, you have no idea if the user is > refreshing the current page or resubmitting after a browser back button. > > So, I think it is best to keep things the way it is now. Thoughts? > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From joakim.lofgren at gmail.com Thu Oct 15 11:46:52 2015 From: joakim.lofgren at gmail.com (=?UTF-8?Q?Joakim_L=C3=B6fgren?=) Date: Thu, 15 Oct 2015 15:46:52 +0000 Subject: [keycloak-dev] Email verification and forgot password oddity Message-ID: Hi, An email is sent for password reset action. When this is opened, another email is sent to verify the email address. This feels redundant. Steps to reproduce: * Create a user with required user actions set to verify email + update password * trigger the reset password flow -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151015/1d9fc2d7/attachment.html From j.kamal at ymail.com Thu Oct 15 15:20:02 2015 From: j.kamal at ymail.com (Kamal Jagadevan) Date: Thu, 15 Oct 2015 19:20:02 +0000 (UTC) Subject: [keycloak-dev] NPE while getting token through Direct Access Grant References: <1950749497.1035048.1444936802831.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1950749497.1035048.1444936802831.JavaMail.yahoo@mail.yahoo.com> Hi Guys!! I took latest master to verify the fix that Stian delivered to prevent usage of same refresh token.My test code tries getting the access token + Refresh token through direct access grant but fails due to NullPointer exception.Meanwhile I can continue to debug further, but wanted to share the observation to you guys... Will post further if I get any more details... Environment details - I have user federation configured to LDAP and tried to login with a user in ldap. Caused by: java.lang.NullPointerException ??????? at org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.removeUser(DefaultCacheUserProvider.java:272) ??????? at org.keycloak.models.UserFederationManager.deleteInvalidUser(UserFederationManager.java:113) ??????? at org.keycloak.models.UserFederationManager.validateAndProxyUser(UserFederationManager.java:135) ??????? at org.keycloak.models.UserFederationManager.getUserById(UserFederationManager.java:163) ??????? at org.keycloak.models.sessions.infinispan.ClientSessionAdapter.getAuthenticatedUser(ClientSessionAdapter.java:265) ??????? at org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:116) ??????? at org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:724) ??????? at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant(TokenEndpoint.java:357) ??????? at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:110) ??????? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ??????? at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ??????? at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ??????? at java.lang.reflect.Method.invoke(Method.java:606) ??????? at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) ??????? at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) ??????? at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) ??????? at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) ??????? at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) ??????? at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) ??????? at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) ??????? at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151015/e25aece3/attachment.html From harish_k_s007 at yahoo.com Thu Oct 15 16:56:02 2015 From: harish_k_s007 at yahoo.com (Harish Kumar) Date: Thu, 15 Oct 2015 20:56:02 +0000 (UTC) Subject: [keycloak-dev] [keycloak-user] Exception while running kaycloak 1.5.0 third party example In-Reply-To: <1305714868.348572.1444851415318.JavaMail.yahoo@mail.yahoo.com> References: <1305714868.348572.1444851415318.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1766477144.851532.1444942562699.JavaMail.yahoo@mail.yahoo.com> I made sure adapter is installed correctly. Now do not see error for Class not found.Now getting following error. Mentioning keycloak.json below.Would appreciate if you could pls let me know how it can be fixed ? 13:44:47,283 WARN? [org.keycloak.events] (default task-115) type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=third-party, userId=null, ipAddress=127.0.0.1, error=invalid_client_credentials Exception13:44:47,284 ERROR [io.undertow.request] (default task-114) UT005023: Exception handling request to /oauth-client/pull_data.jsp: org.apache.jasper.JasperException: java.lang.RuntimeException: org.keycloak.adapters.ServerRequest$HttpFailure at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) 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:745)Caused by: java.lang.RuntimeException: org.keycloak.adapters.ServerRequest$HttpFailure at org.keycloak.example.oauth.ProductDatabaseClient.getTokenResponse(ProductDatabaseClient.java:87) at org.apache.jsp.pull_005fdata_jsp._jspService(pull_005fdata_jsp.java:65) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) ... 31 moreCaused by: org.keycloak.adapters.ServerRequest$HttpFailure at org.keycloak.adapters.ServerRequest.error(ServerRequest.java:211) at org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:94) at org.keycloak.servlet.ServletOAuthClient.resolveBearerToken(ServletOAuthClient.java:41) at org.keycloak.servlet.ServletOAuthClient.getBearerToken(ServletOAuthClient.java:146) at org.keycloak.example.oauth.ProductDatabaseClient.getTokenResponse(ProductDatabaseClient.java:70) ... 35 more Kyecloak.json{ ? "realm": "master",? "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsqzFVCG8nltfcTBL70E5wk2Lh+yu0s5pUvl7rheFBeCb4mSEBwFqLAOIRN3iHVC+A7F8PSp4ZlpqQIBiFXfFiUUSaLfVPVoRapKfi0Wl4+MScFcW2VL4uiIZWR0wIlg0HCZ8EOrHLA6myKi5pc/jhEf7i1FgG+QiTvemQSv9TvLF1xXAXoiNvQbbGzH0t2Pmau9woyHwbiepLp+8pxxIxYupJtBFU+cTc65Rs2wJOmd9snCQQbhTOxeoJLT9J/JkOQcrJUVEracGRx7ebj2pjmUrKx2sAqFH4sCyinODPfFh2OUWUaTSoIN16X2QRyJPbltChjwiu4U2ajD56L5teQIDAQAB",? "auth-server-url": "http://localhost:8080/auth",? "ssl-required": "external",? "resource": "third-party",? "credentials": {? ? "secret": "49f899fa-6208-4eb6-b4fe-e4a8c9b02332"? }} On Wednesday, October 14, 2015 12:36 PM, Harish Kumar wrote: Thanks Marko for response. I checked keycloak-adapter-core-1.5.0.final.jar is presentat ( /modules/system/layers/base/org/keycloak-adapter-core).? Few things i observed, Not sure if they are related just mentioning#1. After 1.1, release httpcomponents (modules/org/apache) has changed jars from 4.2.#2. No start() method for ServletOAuthClient ( it was there in Bootstrap.java in 1.1) Pls let me know if i am missing anything ? Thanks,Harish On Wednesday, October 14, 2015 2:01 AM, Marko Strukelj wrote: The exception seems to indicate that your adapter was not proprerly installed. Make sure that you can see the following file underneath your Wildfly 9 home directory (where you deploy your third party app): modules/system/layers/base/org/keycloak/keycloak-adapter-core/main/keycloak-adapter-core-1.5.0.Final.jar It should be there as a result of properly unpacking??keycloak-wf9-adapter-dist-1.5.0.Final.zip?into your Wildfly 9.I suppose your mentioning?keycloak-appliance-dist-all-1.1.0.Final is a reference to a version that used to work for you some time ago, and not what you're using now. On Wed, Oct 14, 2015 at 4:36 AM, Harish Kumar wrote: I was trying out examples from keycloak 1.5.0, specifically i was trying third-party?example. Same example worked fine while i took distribution (keycloak-appliance-dist-all-1.1.0.Final)I did following steps.? 1. Installed keycloak 1.5.02. Set third-party client with valid redirect URL as?/oauth-client/*3. Keycloak Json mentioned below (towards end of that email)4. Initially when i deployed then i got error (No class definition error :Lorg/keycloak/servlet/ServletOAuthClient)? ?then added files from?keycloak-wf9-adapter-dist-1.5.0.Final.zip.5. After that application could deploy but when i type?http://localhost:8080/oauth-client/?and click on "pull data"? ?then getting error.? I would appreciate if you could pls let me know how this error can be fixed ?? ? Any module missing ? ?javax.servlet.ServletException: java.lang.NoClassDefFoundError: ?org/keycloak/adapters/ServerRequest$HttpFailure ?org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:848) ?org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:777) ?org.apache.jsp.redirect_jsp._jspService(redirect_jsp.java:63) ?org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) ?javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ?org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) ?org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) ?org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) ?javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ?io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) Keycloak json{ ? "realm": "demo",? "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuPt1q5aq8xZGUZVHAwj7xW6vJ20qk/awf6kK6NqQ2CvblWoSYyZOeLF+NpGue3Wn5r4ImKVUST89wPMrO83Y5st31Zpe4kZKoe8kvUj7tI6eeRrUsEsUWwpZ6I5yR5uVgj+8hJ9TaZQNAgB8zK0FvAxmu5bO+mq7c6eDEsYbcuMt3X+VZrkD36toaWM+gXPqziVkiNxp8DdS2TB8EN2J+MBGQRkbG6t6zdVMF0XrWpoT2UeMeFQ05I5lk1mlVupa6TJCpeH7sZBL2pgR+6TRDhViShur5PZUepHayS45PjPYPMsejfGZInRjHl/aqGcRK8YkXPjVDqPSp0xIa/QXYwIDAQAB",? "auth-server-url": "http://localhost:8080/auth",? "ssl-required": "external",? "resource": "third-party",? "credentials": {? ? "secret": "7269abc3-4de8-4be7-b881-8c3fcacf4ef4"? }} _______________________________________________ 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-dev/attachments/20151015/108396ab/attachment-0001.html From ssilvert at redhat.com Thu Oct 15 17:07:26 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 15 Oct 2015 17:07:26 -0400 Subject: [keycloak-dev] Can I use this method in RepresentationToModel? Message-ID: <5620158E.7040400@redhat.com> I'm implementing import users from the admin console. I'd like to use this method to create each user: https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/utils/RepresentationToModel.java#L923 But I'm not sure of the effect since this method uses session.userStorage().addUser() instead of session.users().addUser(). Anyone care to enlighten me? Stan From ssilvert at redhat.com Thu Oct 15 17:28:19 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 15 Oct 2015 17:28:19 -0400 Subject: [keycloak-dev] Can I use this method in RepresentationToModel? In-Reply-To: <5620158E.7040400@redhat.com> References: <5620158E.7040400@redhat.com> Message-ID: <56201A73.5000306@redhat.com> Looks like import realm is using the same method so I guess it's OK. It would still be interesting to know a bit about the effect of calling session.userStorage().addUser() versus session.users().addUser(). We are just relying on the provider settings to sync federated users? On 10/15/2015 5:07 PM, Stan Silvert wrote: > I'm implementing import users from the admin console. I'd like to use > this method to create each user: > https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/utils/RepresentationToModel.java#L923 > > But I'm not sure of the effect since this method uses > session.userStorage().addUser() instead of session.users().addUser(). > > Anyone care to enlighten me? > > Stan > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Thu Oct 15 19:03:44 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 15 Oct 2015 19:03:44 -0400 Subject: [keycloak-dev] Email verification and forgot password oddity In-Reply-To: References: Message-ID: <562030D0.3080808@redhat.com> Fixed in master. On 10/15/2015 11:46 AM, Joakim L?fgren wrote: > Hi, > > An email is sent for password reset action. > When this is opened, another email is sent to verify the email address. > > This feels redundant. > > Steps to reproduce: > * Create a user with required user actions set to verify email + update > password > * trigger the reset password flow > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From gerbermichi at me.com Fri Oct 16 01:42:02 2015 From: gerbermichi at me.com (Michael Gerber) Date: Fri, 16 Oct 2015 07:42:02 +0200 Subject: [keycloak-dev] failed authentication: USER_CONFLICT In-Reply-To: <64cfe96a-ecb3-4d4e-90f8-98655d7e7b61@me.com> References: <64cfe96a-ecb3-4d4e-90f8-98655d7e7b61@me.com> Message-ID: I looked a bit more into the code. And I think you should not set the authenticated user before you have validated the password. Isn't it a bit dangerous if the authenticated user is set even if the entered password is wrong? > Am 15.10.2015 um 09:26 schrieb Michael Gerber : > > Hi all, > > I get the following error if I try to log in as user1 with a wrong password and then as user2 with a correct password. > > 2015-10-15 09:05:58,605 ERROR [org.keycloak.authentication.AuthenticationProcessor] (default task-24) failed authentication: USER_CONFLICT: org.keycloak.authentication.AuthenticationFlowException > at org.keycloak.authentication.AuthenticationProcessor.setAutheticatedUser(AuthenticationProcessor.java:203) [keycloak-services-1.6.0.Final-SNAPSHOT.jar:1.6.0.Final-SNAPSHOT] > at org.keycloak.authentication.AuthenticationProcessor$Result.setUser(AuthenticationProcessor.java:332) [keycloak-services-1.6.0.Final-SNAPSHOT.jar:1.6.0.Final-SNAPSHOT] > > > I think the reason for that is the context.setUser(user) call in the AbstractUsernameFormAuthenticator.validateUser method. > > Is this on purpose? > > Best > Michael > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Fri Oct 16 02:45:02 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Oct 2015 08:45:02 +0200 Subject: [keycloak-dev] Can I use this method in RepresentationToModel? In-Reply-To: <56201A73.5000306@redhat.com> References: <5620158E.7040400@redhat.com> <56201A73.5000306@redhat.com> Message-ID: <56209CEE.3010107@redhat.com> The session.userStorage().addUser() adds user directly to KC persistent storage (JPA, Mongo) and bypasses federation. When you're creating new user through Keycloak somehow (for example in admin console or during user registration), there is need to use "session.users().addUser()", so the user is propagated to federation storage as well. For example, if you have configured LDAP federation provider with WRITE editMode, the user will be created to LDAP as well in addition to Keycloak database. However during import, user usually already exists in LDAP as he was exported from previous environment. It's bit similar for example for default roles. When you create new user in admin console/registration, default roles are added to him. However during import, they are not as the user is supposed to have them already from previously exported DB. Marek On 15/10/15 23:28, Stan Silvert wrote: > Looks like import realm is using the same method so I guess it's OK. It > would still be interesting to know a bit about the effect of calling > session.userStorage().addUser() versus session.users().addUser(). We are > just relying on the provider settings to sync federated users? > > On 10/15/2015 5:07 PM, Stan Silvert wrote: >> I'm implementing import users from the admin console. I'd like to use >> this method to create each user: >> https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/utils/RepresentationToModel.java#L923 >> >> But I'm not sure of the effect since this method uses >> session.userStorage().addUser() instead of session.users().addUser(). >> >> Anyone care to enlighten me? >> >> Stan >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From satyajit.das at spire2grow.com Fri Oct 16 02:50:44 2015 From: satyajit.das at spire2grow.com (Satyajit Das) Date: Fri, 16 Oct 2015 12:20:44 +0530 Subject: [keycloak-dev] Regarding Reset Password Message-ID: Hi Team, Kindly answer by below query. I can see admin api has 2 services for reset password. Do we have an api where in user can enter new password and it should be permanent instead of temporarary. Regards, Satya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151016/86af6f70/attachment.html From mposolda at redhat.com Fri Oct 16 02:54:11 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Oct 2015 08:54:11 +0200 Subject: [keycloak-dev] failed authentication: USER_CONFLICT In-Reply-To: References: <64cfe96a-ecb3-4d4e-90f8-98655d7e7b61@me.com> Message-ID: <56209F13.3080608@redhat.com> +1, anyway it looks like a bug considering the scenario you described. Feel free to create JIRA. Marek On 16/10/15 07:42, Michael Gerber wrote: > I looked a bit more into the code. > And I think you should not set the authenticated user before you have validated the password. Isn't it a bit dangerous if the authenticated user is set even if the entered password is wrong? > >> Am 15.10.2015 um 09:26 schrieb Michael Gerber : >> >> Hi all, >> >> I get the following error if I try to log in as user1 with a wrong password and then as user2 with a correct password. >> >> 2015-10-15 09:05:58,605 ERROR [org.keycloak.authentication.AuthenticationProcessor] (default task-24) failed authentication: USER_CONFLICT: org.keycloak.authentication.AuthenticationFlowException >> at org.keycloak.authentication.AuthenticationProcessor.setAutheticatedUser(AuthenticationProcessor.java:203) [keycloak-services-1.6.0.Final-SNAPSHOT.jar:1.6.0.Final-SNAPSHOT] >> at org.keycloak.authentication.AuthenticationProcessor$Result.setUser(AuthenticationProcessor.java:332) [keycloak-services-1.6.0.Final-SNAPSHOT.jar:1.6.0.Final-SNAPSHOT] >> >> >> I think the reason for that is the context.setUser(user) call in the AbstractUsernameFormAuthenticator.validateUser method. >> >> Is this on purpose? >> >> Best >> Michael >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Fri Oct 16 02:59:19 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Oct 2015 08:59:19 +0200 Subject: [keycloak-dev] [keycloak-user] Exception while running kaycloak 1.5.0 third party example In-Reply-To: <1766477144.851532.1444942562699.JavaMail.yahoo@mail.yahoo.com> References: <1305714868.348572.1444851415318.JavaMail.yahoo@mail.yahoo.com> <1766477144.851532.1444942562699.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5620A047.4060401@redhat.com> According to error, I suppose it is invalid client credentials, so likely invalid client secret. If you go to admin console and click to "thirdparty" client, then tab "Credentials" you will see the actual secret of thirdparty client from Keycloak database. You need to copy this secret into keycloak.json . Marek On 15/10/15 22:56, Harish Kumar wrote: > I made sure adapter is installed correctly. Now do not see error for > Class not found. > Now getting following error. Mentioning keycloak.json below. > Would appreciate if you could pls let me know how it can be fixed ? > > > 13:44:47,283 WARN [org.keycloak.events] (default task-115) > type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=third-party, > userId=null, ipAddress=127.0.0.1, error=invalid_client_credentials > > *_Exception_* > 13:44:47,284 ERROR [io.undertow.request] (default task-114) UT005023: > Exception handling request to /oauth-client/pull_data.jsp: > org.apache.jasper.JasperException: java.lang.RuntimeException: > org.keycloak.adapters.ServerRequest$HttpFailure > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32) > 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:745) > Caused by: java.lang.RuntimeException: > org.keycloak.adapters.ServerRequest$HttpFailure > at > org.keycloak.example.oauth.ProductDatabaseClient.getTokenResponse(ProductDatabaseClient.java:87) > at org.apache.jsp.pull_005fdata_jsp._jspService(pull_005fdata_jsp.java:65) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) > ... 31 more > Caused by: org.keycloak.adapters.ServerRequest$HttpFailure > at org.keycloak.adapters.ServerRequest.error(ServerRequest.java:211) > at > org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:94) > at > org.keycloak.servlet.ServletOAuthClient.resolveBearerToken(ServletOAuthClient.java:41) > at > org.keycloak.servlet.ServletOAuthClient.getBearerToken(ServletOAuthClient.java:146) > at > org.keycloak.example.oauth.ProductDatabaseClient.getTokenResponse(ProductDatabaseClient.java:70) > ... 35 more > > *_Kyecloak.json_* > { > "realm": "master", > "realm-public-key": > "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsqzFVCG8nltfcTBL70E5wk2Lh+yu0s5pUvl7rheFBeCb4mSEBwFqLAOIRN3iHVC+A7F8PSp4ZlpqQIBiFXfFiUUSaLfVPVoRapKfi0Wl4+MScFcW2VL4uiIZWR0wIlg0HCZ8EOrHLA6myKi5pc/jhEf7i1FgG+QiTvemQSv9TvLF1xXAXoiNvQbbGzH0t2Pmau9woyHwbiepLp+8pxxIxYupJtBFU+cTc65Rs2wJOmd9snCQQbhTOxeoJLT9J/JkOQcrJUVEracGRx7ebj2pjmUrKx2sAqFH4sCyinODPfFh2OUWUaTSoIN16X2QRyJPbltChjwiu4U2ajD56L5teQIDAQAB", > "auth-server-url": "http://localhost:8080/auth", > "ssl-required": "external", > "resource": "third-party", > "credentials": { > "secret": "49f899fa-6208-4eb6-b4fe-e4a8c9b02332" > } > } > > > > > On Wednesday, October 14, 2015 12:36 PM, Harish Kumar > wrote: > > > Thanks Marko for response. I checked > keycloak-adapter-core-1.5.0.final.jar is present > at ( /modules/system/layers/base/org/keycloak-adapter-core). > > Few things i observed, Not sure if they are related just mentioning > #1. After 1.1, release httpcomponents (modules/org/apache) has changed > jars from 4.2. > #2. No start() method for ServletOAuthClient ( it was there in > Bootstrap.java in 1.1) > > Pls let me know if i am missing anything ? > > Thanks, > Harish > > On Wednesday, October 14, 2015 2:01 AM, Marko Strukelj > wrote: > > > The exception seems to indicate that your adapter was not proprerly > installed. > > Make sure that you can see the following file underneath your Wildfly > 9 home directory (where you deploy your third party app): > > modules/system/layers/base/org/keycloak/keycloak-adapter-core/main/keycloak-adapter-core-1.5.0.Final.jar > > It should be there as a result of properly unpacking > keycloak-wf9-adapter-dist-1.5.0.Final.zip > into > your Wildfly 9. > I suppose your mentioning keycloak-appliance-dist-all-1.1.0.Final is a > reference to a version that used to work for you some time ago, and > not what you're using now. > > > On Wed, Oct 14, 2015 at 4:36 AM, Harish Kumar > wrote: > > I was trying out examples from keycloak 1.5.0, specifically i was > trying third-party > example. Same example worked fine while i took distribution > (keycloak-appliance-dist-all-1.1.0.Final) > I did following steps. > > 1. Installed keycloak 1.5.0 > 2. Set third-party client with valid redirect URL as /oauth-client/* > 3. Keycloak Json mentioned below (towards end of that email) > 4. Initially when i deployed then i got error (No class definition > error :Lorg/keycloak/servlet/ServletOAuthClient) > then added files from keycloak-wf9-adapter-dist-1.5.0.Final.zip > . > 5. After that application could deploy but when i type > http://localhost:8080/oauth-client/ and click on "pull data" > then getting error. I would appreciate if you could pls let me > know how this error can be fixed ? > Any module missing ? > > javax.servlet.ServletException: java.lang.NoClassDefFoundError: > org/keycloak/adapters/ServerRequest$HttpFailure > org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:848) > org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:777) > org.apache.jsp.redirect_jsp._jspService(redirect_jsp.java:63) > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) > > > *_Keycloak json_* > { > "realm": "demo", > "realm-public-key": > "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuPt1q5aq8xZGUZVHAwj7xW6vJ20qk/awf6kK6NqQ2CvblWoSYyZOeLF+NpGue3Wn5r4ImKVUST89wPMrO83Y5st31Zpe4kZKoe8kvUj7tI6eeRrUsEsUWwpZ6I5yR5uVgj+8hJ9TaZQNAgB8zK0FvAxmu5bO+mq7c6eDEsYbcuMt3X+VZrkD36toaWM+gXPqziVkiNxp8DdS2TB8EN2J+MBGQRkbG6t6zdVMF0XrWpoT2UeMeFQ05I5lk1mlVupa6TJCpeH7sZBL2pgR+6TRDhViShur5PZUepHayS45PjPYPMsejfGZInRjHl/aqGcRK8YkXPjVDqPSp0xIa/QXYwIDAQAB", > "auth-server-url": "http://localhost:8080/auth", > "ssl-required": "external", > "resource": "third-party", > "credentials": { > "secret": "7269abc3-4de8-4be7-b881-8c3fcacf4ef4" > } > } > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151016/92082f41/attachment-0001.html From mposolda at redhat.com Fri Oct 16 03:05:51 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Oct 2015 09:05:51 +0200 Subject: [keycloak-dev] [keycloak-user] Regarding Reset Password In-Reply-To: References: Message-ID: <5620A1CF.5000006@redhat.com> The API already allows to set credential as permanent instead of temporary. There is flag boolean flag "temporary" on CredentialRepresentation. You can see the admin console on/off switch for temporary password too. So try to switch it off and see how REST request sent from admin console looks like (you can use tools like firebug to see REST requests sent by browser) Marek On 16/10/15 08:50, Satyajit Das wrote: > Hi Team, > Kindly answer by below query. > > I can see admin api has 2 services for reset password. > > Do we have an api where in user can enter new password and it should > be permanent instead of temporarary. > > 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-dev/attachments/20151016/a0fb6564/attachment.html From sthorger at redhat.com Fri Oct 16 04:08:10 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 16 Oct 2015 10:08:10 +0200 Subject: [keycloak-dev] NPE while getting token through Direct Access Grant In-Reply-To: <1950749497.1035048.1444936802831.JavaMail.yahoo@mail.yahoo.com> References: <1950749497.1035048.1444936802831.JavaMail.yahoo@mail.yahoo.com> <1950749497.1035048.1444936802831.JavaMail.yahoo@mail.yahoo.com> Message-ID: Does it work if you disable "Revoke Refresh Token" in token settings? When that is off (default setting) there's no changes to the code. On 15 October 2015 at 21:20, Kamal Jagadevan wrote: > Hi Guys!! > > I took latest master to verify the fix that Stian delivered to prevent > usage of same refresh token. > My test code tries getting the access token + Refresh token through direct > access grant but fails due to NullPointer exception. > Meanwhile I can continue to debug further, but wanted to share the > observation to you guys... Will post further if I get any more details... > > Environment details - I have user federation configured to LDAP and tried > to login with a user in ldap. > > > Caused by: java.lang.NullPointerException > at > org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.removeUser(DefaultCacheUserProvider.java:272) > at > org.keycloak.models.UserFederationManager.deleteInvalidUser(UserFederationManager.java:113) > at > org.keycloak.models.UserFederationManager.validateAndProxyUser(UserFederationManager.java:135) > at > org.keycloak.models.UserFederationManager.getUserById(UserFederationManager.java:163) > at > org.keycloak.models.sessions.infinispan.ClientSessionAdapter.getAuthenticatedUser(ClientSessionAdapter.java:265) > at > org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:116) > at > org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:724) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant(TokenEndpoint.java:357) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:110) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151016/49cbf7d8/attachment.html From sthorger at redhat.com Fri Oct 16 04:11:32 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 16 Oct 2015 10:11:32 +0200 Subject: [keycloak-dev] This list is not for support! Message-ID: Please do not use the developer mailing list to ask about general questions about using Keycloak. Use the user mailing list for that. Also, please refrain from answering support questions to this list! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151016/023a422c/attachment.html From sthorger at redhat.com Fri Oct 16 04:15:56 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 16 Oct 2015 10:15:56 +0200 Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: <1630521586.46217988.1444830025050.JavaMail.zimbra@redhat.com> References: <1932006692.46216128.1444829886159.JavaMail.zimbra@redhat.com> <1630521586.46217988.1444830025050.JavaMail.zimbra@redhat.com> Message-ID: For now - which ever you want. I propose you introduce a new SPI though. Once it's beyond a POC then both :/ On 14 October 2015 at 15:40, Pedro Igor Silva wrote: > Hi, > > Would like to know your thoughts about which model implementations I > must support for the authz model. Both Database/JPA and MongoDB ? > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151016/5e97cf8c/attachment.html From mposolda at redhat.com Fri Oct 16 04:35:08 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Oct 2015 10:35:08 +0200 Subject: [keycloak-dev] This list is not for support! In-Reply-To: References: Message-ID: <5620B6BC.1050404@redhat.com> I guess most of people go to http://www.keycloak.org and find the mailing lists from here. Maybe it's not clear enough what "Developer forum" and "User forum" means and what is the best place to ask support questions... Maybe a possible improvement for new web page to emphasize it more clearly :-) Another helpful thing might be to fill the description "About keycloak-dev" here https://lists.jboss.org/mailman/listinfo/keycloak-dev . Same for keycloak-user ML. Marek On 16/10/15 10:11, Stian Thorgersen wrote: > Please do not use the developer mailing list to ask about general > questions about using Keycloak. Use the user mailing list for that. > > Also, please refrain from answering support questions to this list! > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151016/6ca28571/attachment.html From mposolda at redhat.com Fri Oct 16 04:47:05 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Oct 2015 10:47:05 +0200 Subject: [keycloak-dev] NPE while getting token through Direct Access Grant In-Reply-To: References: <1950749497.1035048.1444936802831.JavaMail.yahoo@mail.yahoo.com> <1950749497.1035048.1444936802831.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5620B989.3060206@redhat.com> In stacktrace there is: at org.keycloak.models.UserFederationManager.deleteInvalidUser(UserFederationManager.java:113) at org.keycloak.models.UserFederationManager.validateAndProxyUser(UserFederationManager.java:135) which means that your LDAP user is no longer valid - in other words he wasn't found by Keycloak in LDAP. So this looks like LDAP problem rather than issue related to refresh tokens. Is your user still available in LDAP? If yes, then what are you using for "UUID LDAP attribute" in LDAP federation provider settings page? Does your LDAP users have this attribute available in LDAP? For example if you use "entryUUID" in the admin console configuration, is this attribute really available in LDAP for your LDAP users? Marek On 16/10/15 10:08, Stian Thorgersen wrote: > Does it work if you disable "Revoke Refresh Token" in token settings? > When that is off (default setting) there's no changes to the code. > > On 15 October 2015 at 21:20, Kamal Jagadevan > wrote: > > Hi Guys!! > > I took latest master to verify the fix that Stian delivered to > prevent usage of same refresh token. > My test code tries getting the access token + Refresh token > through direct access grant but fails due to NullPointer exception. > Meanwhile I can continue to debug further, but wanted to share the > observation to you guys... Will post further if I get any more > details... > > Environment details - I have user federation configured to LDAP > and tried to login with a user in ldap. > > > Caused by: java.lang.NullPointerException > at > org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.removeUser(DefaultCacheUserProvider.java:272) > at > org.keycloak.models.UserFederationManager.deleteInvalidUser(UserFederationManager.java:113) > at > org.keycloak.models.UserFederationManager.validateAndProxyUser(UserFederationManager.java:135) > at > org.keycloak.models.UserFederationManager.getUserById(UserFederationManager.java:163) > at > org.keycloak.models.sessions.infinispan.ClientSessionAdapter.getAuthenticatedUser(ClientSessionAdapter.java:265) > at > org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:116) > at > org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:724) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant(TokenEndpoint.java:357) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:110) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151016/73a9f013/attachment-0001.html From psilva at redhat.com Fri Oct 16 09:07:37 2015 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 16 Oct 2015 09:07:37 -0400 (EDT) Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: References: <1932006692.46216128.1444829886159.JavaMail.zimbra@redhat.com> <1630521586.46217988.1444830025050.JavaMail.zimbra@redhat.com> Message-ID: <749164596.47425988.1445000857848.JavaMail.zimbra@redhat.com> Yeah, I've talked with Bolek as well and we discussed about focusing on JPA (which I was already using) for now, but still provide a SPI for future implementations. >From a SPI perspective, I did something very simple without KC's org.keycloak.provider.Spi. The main reason for this decision is that Spis in KC are not loaded when defined within a custom provider and I'm trying to minimize changes in KC itself. However, if necessary, I can provide some minor changes to make that happen. So Spis can also be loaded from custom providers. Thanks. ----- Original Message ----- From: "Stian Thorgersen" To: "Pedro Igor Silva" Cc: "keycloak dev" Sent: Friday, October 16, 2015 5:15:56 AM Subject: Re: [keycloak-dev] Authz Model Implementation For now - which ever you want. I propose you introduce a new SPI though. Once it's beyond a POC then both :/ On 14 October 2015 at 15:40, Pedro Igor Silva wrote: > Hi, > > Would like to know your thoughts about which model implementations I > must support for the authz model. Both Database/JPA and MongoDB ? > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From psilva at redhat.com Fri Oct 16 09:16:01 2015 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 16 Oct 2015 09:16:01 -0400 (EDT) Subject: [keycloak-dev] Using events to track repository updates In-Reply-To: <1062295451.47430011.1445001065068.JavaMail.zimbra@redhat.com> Message-ID: <1992470867.47433520.1445001361208.JavaMail.zimbra@redhat.com> Hi, Are KC events, like ClientCreationEvent (and probably a missing ClientRemovedEvent), the recommended way to keep different repositories in sync ? In case you have to manage FKs programmatically ... Regards. Pedro Igor From ssilvert at redhat.com Fri Oct 16 09:33:46 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 16 Oct 2015 09:33:46 -0400 Subject: [keycloak-dev] Can I use this method in RepresentationToModel? In-Reply-To: <56209CEE.3010107@redhat.com> References: <5620158E.7040400@redhat.com> <56201A73.5000306@redhat.com> <56209CEE.3010107@redhat.com> Message-ID: <5620FCBA.3090507@redhat.com> Hmm. Sounds like during import we are making some assumptions about how the import file was created. Like I said, when you import a realm from the admin console today it uses session.userStorage().addUser(). So someone using this feature should be aware that anything imported will not be federated. (If I understand correctly) Is that OK? Is it OK going forward for partial imports? No federation? On 10/16/2015 2:45 AM, Marek Posolda wrote: > The session.userStorage().addUser() adds user directly to KC > persistent storage (JPA, Mongo) and bypasses federation. > > When you're creating new user through Keycloak somehow (for example in > admin console or during user registration), there is need to use > "session.users().addUser()", so the user is propagated to federation > storage as well. For example, if you have configured LDAP federation > provider with WRITE editMode, the user will be created to LDAP as well > in addition to Keycloak database. However during import, user usually > already exists in LDAP as he was exported from previous environment. > > It's bit similar for example for default roles. When you create new > user in admin console/registration, default roles are added to him. > However during import, they are not as the user is supposed to have > them already from previously exported DB. > > Marek > > On 15/10/15 23:28, Stan Silvert wrote: >> Looks like import realm is using the same method so I guess it's OK. It >> would still be interesting to know a bit about the effect of calling >> session.userStorage().addUser() versus session.users().addUser(). We are >> just relying on the provider settings to sync federated users? >> >> On 10/15/2015 5:07 PM, Stan Silvert wrote: >>> I'm implementing import users from the admin console. I'd like to use >>> this method to create each user: >>> https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/utils/RepresentationToModel.java#L923 >>> >>> >>> But I'm not sure of the effect since this method uses >>> session.userStorage().addUser() instead of session.users().addUser(). >>> >>> Anyone care to enlighten me? >>> >>> Stan >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Fri Oct 16 10:39:19 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 16 Oct 2015 10:39:19 -0400 Subject: [keycloak-dev] changes to browser-based flows Message-ID: <56210C17.8020907@redhat.com> FYI: Not important if you are uninterested in design. Prior to my last commit if you hit the browser refresh button you would either have had the authentication flow completely reset or received an error page. Also, changing the local on some required actions pages would end up in an error condition. So...To fix this I made some changes to browser based flows: * After any successful action processing (i.e. a form POST), the browser is sent a 302 redirect to a "safer" page. If you are in the authentication phase, then this redirect will be to /authenticate?code={code}, registration /register?code={code}, reset credentials /reset-credentials?code={code}, required actions /required-action?code={code}. When these URIs are executed, Keycloak will figure out where the user is in the flow and render things appropriately. * After authentication, the browser will be 302 redirected to /required-action?code={code} The reason for these changes is to support when the user clicks the browser refresh button. The refresh button will resubmit the previous request. Prior to this change there were issues with this. For example, previously, if there was a required action and you just logged in via username and password, the URI in the browser would still point to the username/password page even though the required action page was being rendered. If the refresh button was hit, the previous username password POST would be resent to the username/password page, Keycloak would say "WTF are you doing?!?" and abort. There were similar issues like this everywhere. Other things effected by this fix: * required actions no longer change the ACTION_KEY or the ClientSessionModel.getAction(). * ClientSessionModel.getAction() will either be AUTHENTICATION, REQUIRED_ACTIONS, EXECUTE_ACTIONS, LOGGED_OUT, or OAUTH_GRANT. * After authentication, the flow manager will change the action from AUTHENTICATION to REQUIRED_ACTIONS. Overall, this is less performant as there are additional HTTP redirect requests being thrown in, but should provide a better user experience. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Oct 16 10:48:41 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 16 Oct 2015 10:48:41 -0400 Subject: [keycloak-dev] Can I use this method in RepresentationToModel? In-Reply-To: <5620FCBA.3090507@redhat.com> References: <5620158E.7040400@redhat.com> <56201A73.5000306@redhat.com> <56209CEE.3010107@redhat.com> <5620FCBA.3090507@redhat.com> Message-ID: <56210E49.4030601@redhat.com> Import was really mostly targeted to migration or our demos or the testsuite. For migration, you would be importing a previous export of the local keycloak storage and thus would not want to go through federation. I guess import would need a switch on whether if it is an import into local keycloak storage only or not? On 10/16/2015 9:33 AM, Stan Silvert wrote: > Hmm. Sounds like during import we are making some assumptions about how > the import file was created. > > Like I said, when you import a realm from the admin console today it > uses session.userStorage().addUser(). So someone using this feature > should be aware that anything imported will not be federated. (If I > understand correctly) > > Is that OK? > > Is it OK going forward for partial imports? No federation? > > On 10/16/2015 2:45 AM, Marek Posolda wrote: >> The session.userStorage().addUser() adds user directly to KC >> persistent storage (JPA, Mongo) and bypasses federation. >> >> When you're creating new user through Keycloak somehow (for example in >> admin console or during user registration), there is need to use >> "session.users().addUser()", so the user is propagated to federation >> storage as well. For example, if you have configured LDAP federation >> provider with WRITE editMode, the user will be created to LDAP as well >> in addition to Keycloak database. However during import, user usually >> already exists in LDAP as he was exported from previous environment. >> >> It's bit similar for example for default roles. When you create new >> user in admin console/registration, default roles are added to him. >> However during import, they are not as the user is supposed to have >> them already from previously exported DB. >> >> Marek >> >> On 15/10/15 23:28, Stan Silvert wrote: >>> Looks like import realm is using the same method so I guess it's OK. It >>> would still be interesting to know a bit about the effect of calling >>> session.userStorage().addUser() versus session.users().addUser(). We are >>> just relying on the provider settings to sync federated users? >>> >>> On 10/15/2015 5:07 PM, Stan Silvert wrote: >>>> I'm implementing import users from the admin console. I'd like to use >>>> this method to create each user: >>>> https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/utils/RepresentationToModel.java#L923 >>>> >>>> >>>> But I'm not sure of the effect since this method uses >>>> session.userStorage().addUser() instead of session.users().addUser(). >>>> >>>> Anyone care to enlighten me? >>>> >>>> Stan >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Fri Oct 16 10:58:56 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 16 Oct 2015 16:58:56 +0200 Subject: [keycloak-dev] Some packages renamed Message-ID: <562110B0.80307@redhat.com> Fuse (OSGI in general) doesn't like when there are 2 jar bundles exporting same java packages. Hence I sent PR https://github.com/keycloak/keycloak/pull/1750, which (among some minor fixes) contains renaming of some packages: - keycloak-common vs. keycloak-core had same packages. So all packages in keycloak-common were put into "org.keycloak.common" (For example "org.keycloak.common.util" instead of previous "org.keycloak.util" ) - keycloak-adapter-spi vs. keycloak-adapter-core had same packages. So package in keycloak-adapter-spi was renamed to "org.keycloak.adapters.spi" - keycloak-jetty-spi vs. keycloak-jetty-core had same packages. So package in keycloak-jetty-spi was renamed to "org.keycloak.jetty.spi" We discussed with Stian that it's ok to rename it as keycloak-common and keycloak-adapter-spi contains mainly internal util classes and are not supposed to be widely used by people. Most important packages (especially stuff in keycloak-core ) is unchanged. But still, I am likely going to write some note to migration guide. This change affects quite many classes, especially import. So I suggest to rebase before start on something major :-) Marek From j.kamal at ymail.com Fri Oct 16 11:12:53 2015 From: j.kamal at ymail.com (Kamal Jagadevan) Date: Fri, 16 Oct 2015 15:12:53 +0000 (UTC) Subject: [keycloak-dev] NPE while getting token through Direct Access Grant In-Reply-To: <5620B989.3060206@redhat.com> References: <1950749497.1035048.1444936802831.JavaMail.yahoo@mail.yahoo.com> <1950749497.1035048.1444936802831.JavaMail.yahoo@mail.yahoo.com> <5620B989.3060206@redhat.com> Message-ID: <546009763.1480258.1445008373557.JavaMail.yahoo@mail.yahoo.com> Marek,? You are right...it was an LDAP issue, after I added(deleting the older one) new profile I no longer see this issue. Thanks for your inputs. ThanksKamal From: Marek Posolda To: stian at redhat.com; Kamal Jagadevan Cc: Keycloak-dev Sent: Friday, October 16, 2015 4:47 AM Subject: Re: [keycloak-dev] NPE while getting token through Direct Access Grant In stacktrace there is: ??? atorg.keycloak.models.UserFederationManager.deleteInvalidUser(UserFederationManager.java:113) atorg.keycloak.models.UserFederationManager.validateAndProxyUser(UserFederationManager.java:135) which means that your LDAP user is no longer valid - in other words he wasn't found by Keycloak in LDAP. So this looks like LDAP problem rather than issue related to refresh tokens. Is your user still available in LDAP? If yes, then what are you using for "UUID LDAP attribute" in LDAP federation provider settings page? Does your LDAP users have this attribute available in LDAP? For example if you use "entryUUID" in the admin console configuration, is this attribute really available in LDAP for your LDAP users? Marek On 16/10/15 10:08, Stian Thorgersen wrote: Does it work if you disable "Revoke Refresh Token" in token settings? When that is off (default setting) there's no changes to the code. On 15 October 2015 at 21:20, Kamal Jagadevan wrote: Hi Guys!! I took latest master to verify the fix that Stian delivered to prevent usage of same refresh token. My test code tries getting the access token + Refresh token through direct access grant but fails due to NullPointer exception. Meanwhile I can continue to debug further, but wanted to share the observation to you guys... Will post further if I get any more details... Environment details - I have user federation configured to LDAP and tried to login with a user in ldap. Caused by: java.lang.NullPointerException ??????? atorg.keycloak.models.cache.infinispan.DefaultCacheUserProvider.removeUser(DefaultCacheUserProvider.java:272) ??????? atorg.keycloak.models.UserFederationManager.deleteInvalidUser(UserFederationManager.java:113) ??????? atorg.keycloak.models.UserFederationManager.validateAndProxyUser(UserFederationManager.java:135) ??????? atorg.keycloak.models.UserFederationManager.getUserById(UserFederationManager.java:163) ??????? atorg.keycloak.models.sessions.infinispan.ClientSessionAdapter.getAuthenticatedUser(ClientSessionAdapter.java:265) ??????? atorg.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:116) ??????? atorg.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:724) ??????? atorg.keycloak.protocol.oidc.endpoints.TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant(TokenEndpoint.java:357) ??????? atorg.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:110) ??????? at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ??????? atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ??????? atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ??????? at java.lang.reflect.Method.invoke(Method.java:606) ??????? atorg.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) ??????? atorg.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) ??????? atorg.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) ??????? atorg.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) ??????? atorg.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:109) ??????? atorg.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:135) ??????? atorg.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) ??????? atorg.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151016/ab6c9ed5/attachment-0001.html From bburke at redhat.com Fri Oct 16 13:18:22 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 16 Oct 2015 13:18:22 -0400 Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: <749164596.47425988.1445000857848.JavaMail.zimbra@redhat.com> References: <1932006692.46216128.1444829886159.JavaMail.zimbra@redhat.com> <1630521586.46217988.1444830025050.JavaMail.zimbra@redhat.com> <749164596.47425988.1445000857848.JavaMail.zimbra@redhat.com> Message-ID: <5621315E.5070408@redhat.com> On 10/16/2015 9:07 AM, Pedro Igor Silva wrote: > Yeah, I've talked with Bolek as well and we discussed about focusing on JPA (which I was already using) for now, but still provide a SPI for future implementations. > >>From a SPI perspective, I did something very simple without KC's org.keycloak.provider.Spi. The main reason for this decision is that Spis in KC are not loaded when defined within a custom provider and I'm trying to minimize changes in KC itself. > How could the org.keycloak.provider.Spi not work? It uses the META-INF/services pattern to locate new and old Spis. Nothing magical there. Your jar just needs to be loaded into the appropriate modules. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Oct 16 14:24:36 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 16 Oct 2015 14:24:36 -0400 Subject: [keycloak-dev] improvements to client creation Message-ID: <562140E4.2040800@redhat.com> I'd like to improve the client creation page to reduce the amount of info somebody needs to type in the first page and to provide base defaults. I'll add this as a jira and schedule for 1.7 or 1.8 Create page required config (only these will be shown): * Client Id * protocol * Root URL For OIDC defaults would be: * confidential client * full scoped * valid redirect urls Root URL/* * consent required false * direct grants only false * service accounts enabled false * Base URL renamed to Link URL defaults to root url * Web Origins defaults to host of Root URL * Remove admin url, this would just point to the root. For SAML: * Sign documents true * Include Authn Statement true * Client signature required true * Sign assertions false * Client private/public cert would be generated * force post binding false * encrypt assertions false * front channel logout false * Remove valid redirect URLs * Remvoe Master SAML Processing URL * Assertion Consumer and Logout Service binding urls all filled in with Root URL. SAML would get an Installation tab and could choose configurations for: * Keycloak SAML adapter * mod-auth-mellon -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From psilva at redhat.com Fri Oct 16 15:19:34 2015 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 16 Oct 2015 15:19:34 -0400 (EDT) Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: <5621315E.5070408@redhat.com> References: <1932006692.46216128.1444829886159.JavaMail.zimbra@redhat.com> <1630521586.46217988.1444830025050.JavaMail.zimbra@redhat.com> <749164596.47425988.1445000857848.JavaMail.zimbra@redhat.com> <5621315E.5070408@redhat.com> Message-ID: <149136013.47805384.1445023174448.JavaMail.zimbra@redhat.com> I'm not saying it does not work, but in my case I have a specific module with all the authz stuff. There I'm already using Spis from KC such as JpaConnectionProvider, extension to admin rest api, etc. That is fine and everything is perfect. The problem I'm facing is how to tell KC to load Spis from my module without change a bit in KC modules or change code. If you see org.keycloak.services.DefaultKeycloakSessionFactory#init, Spis are loaded from getClass().getClassLoader(). Considering that my Spis are in a different classloader, they will never be loaded. A simple solution for that would be to do something similar as when loading providers, so you could also consider the classloaders from the providers when loading Spis. ----- Original Message ----- From: "Bill Burke" To: keycloak-dev at lists.jboss.org Sent: Friday, October 16, 2015 2:18:22 PM Subject: Re: [keycloak-dev] Authz Model Implementation On 10/16/2015 9:07 AM, Pedro Igor Silva wrote: > Yeah, I've talked with Bolek as well and we discussed about focusing on JPA (which I was already using) for now, but still provide a SPI for future implementations. > >>From a SPI perspective, I did something very simple without KC's org.keycloak.provider.Spi. The main reason for this decision is that Spis in KC are not loaded when defined within a custom provider and I'm trying to minimize changes in KC itself. > How could the org.keycloak.provider.Spi not work? It uses the META-INF/services pattern to locate new and old Spis. Nothing magical there. Your jar just needs to be loaded into the appropriate modules. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From calovi86 at gmail.com Sat Oct 17 19:28:37 2015 From: calovi86 at gmail.com (Cristhian Camilo Lopez) Date: Sat, 17 Oct 2015 18:28:37 -0500 Subject: [keycloak-dev] Fine Grained Permissions Message-ID: <7a7965cb-1851-4877-b8d5-48ab9b449fcc@typeapp.com> Hello, I'm migrating from Picketlink to Keycloak but I haven't found the way to implement fined Grained permissions . What's the "right" approach to implement this feature. Help is appreciated, Crsthian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151017/60bd15d2/attachment.html From bburke at redhat.com Sat Oct 17 20:14:06 2015 From: bburke at redhat.com (Bill Burke) Date: Sat, 17 Oct 2015 20:14:06 -0400 Subject: [keycloak-dev] Fine Grained Permissions In-Reply-To: <7a7965cb-1851-4877-b8d5-48ab9b449fcc@typeapp.com> References: <7a7965cb-1851-4877-b8d5-48ab9b449fcc@typeapp.com> Message-ID: <5622E44E.9080600@redhat.com> Pedro is working on an Authz server to compliment Keycloak. He can give you more details. On 10/17/2015 7:28 PM, Cristhian Camilo Lopez wrote: > Hello, > > I'm migrating from Picketlink to Keycloak but I haven't found the way to > implement fined Grained permissions . What's the "right" approach to > implement this feature. > > Help is appreciated, > > Crsthian > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From calovi86 at gmail.com Sun Oct 18 13:16:30 2015 From: calovi86 at gmail.com (Cristhian Camilo Lopez) Date: Sun, 18 Oct 2015 12:16:30 -0500 Subject: [keycloak-dev] Authz Model Implementation Message-ID: Hi Pedro, I'm migrating from Picketlink, but I haven't found the way to use fine-grained permissions, Could u give me some advice on this ? Thanks, Cristhian. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151018/15eea699/attachment.html From sthorger at redhat.com Mon Oct 19 02:29:27 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 19 Oct 2015 08:29:27 +0200 Subject: [keycloak-dev] Using events to track repository updates In-Reply-To: <1992470867.47433520.1445001361208.JavaMail.zimbra@redhat.com> References: <1062295451.47430011.1445001065068.JavaMail.zimbra@redhat.com> <1992470867.47433520.1445001361208.JavaMail.zimbra@redhat.com> Message-ID: Yes, that's the best we got On 16 October 2015 at 15:16, Pedro Igor Silva wrote: > Hi, > > Are KC events, like ClientCreationEvent (and probably a missing > ClientRemovedEvent), the recommended way to keep different repositories in > sync ? In case you have to manage FKs programmatically ... > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151019/d5483081/attachment.html From sthorger at redhat.com Mon Oct 19 02:32:13 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 19 Oct 2015 08:32:13 +0200 Subject: [keycloak-dev] improvements to client creation In-Reply-To: <562140E4.2040800@redhat.com> References: <562140E4.2040800@redhat.com> Message-ID: Instead of having the create and edit pages different. Why don't we have only those fields shown by default, then have a expandable field or a separate tab with the "advanced options"? On 16 October 2015 at 20:24, Bill Burke wrote: > I'd like to improve the client creation page to reduce the amount of > info somebody needs to type in the first page and to provide base > defaults. I'll add this as a jira and schedule for 1.7 or 1.8 > > Create page required config (only these will be shown): > * Client Id > * protocol > * Root URL > > For OIDC defaults would be: > * confidential client > * full scoped > * valid redirect urls Root URL/* > * consent required false > * direct grants only false > * service accounts enabled false > * Base URL renamed to Link URL defaults to root url > * Web Origins defaults to host of Root URL > * Remove admin url, this would just point to the root. > > For SAML: > * Sign documents true > * Include Authn Statement true > * Client signature required true > * Sign assertions false > * Client private/public cert would be generated > * force post binding false > * encrypt assertions false > * front channel logout false > * Remove valid redirect URLs > * Remvoe Master SAML Processing URL > * Assertion Consumer and Logout Service binding urls all filled in with > Root URL. > > SAML would get an Installation tab and could choose configurations for: > * Keycloak SAML adapter > * mod-auth-mellon > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151019/b19e3eca/attachment.html From sthorger at redhat.com Mon Oct 19 02:33:58 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 19 Oct 2015 08:33:58 +0200 Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: <149136013.47805384.1445023174448.JavaMail.zimbra@redhat.com> References: <1932006692.46216128.1444829886159.JavaMail.zimbra@redhat.com> <1630521586.46217988.1444830025050.JavaMail.zimbra@redhat.com> <749164596.47425988.1445000857848.JavaMail.zimbra@redhat.com> <5621315E.5070408@redhat.com> <149136013.47805384.1445023174448.JavaMail.zimbra@redhat.com> Message-ID: On 16 October 2015 at 21:19, Pedro Igor Silva wrote: > I'm not saying it does not work, but in my case I have a specific module > with all the authz stuff. There I'm already using Spis from KC such as > JpaConnectionProvider, extension to admin rest api, etc. That is fine and > everything is perfect. > > The problem I'm facing is how to tell KC to load Spis from my module > without change a bit in KC modules or change code. If you see > org.keycloak.services.DefaultKeycloakSessionFactory#init, Spis are loaded > from getClass().getClassLoader(). Considering that my Spis are in a > different classloader, they will never be loaded. > > A simple solution for that would be to do something similar as when > loading providers, so you could also consider the classloaders from the > providers when loading Spis. > That works - we should be able to look in modules and classpath entries for SPIs like we do for providers. Prepare a PR and we'll merge it. > > ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, October 16, 2015 2:18:22 PM > Subject: Re: [keycloak-dev] Authz Model Implementation > > > > On 10/16/2015 9:07 AM, Pedro Igor Silva wrote: > > Yeah, I've talked with Bolek as well and we discussed about focusing on > JPA (which I was already using) for now, but still provide a SPI for future > implementations. > > > >>From a SPI perspective, I did something very simple without KC's > org.keycloak.provider.Spi. The main reason for this decision is that Spis > in KC are not loaded when defined within a custom provider and I'm trying > to minimize changes in KC itself. > > > > How could the org.keycloak.provider.Spi not work? It uses the > META-INF/services pattern to locate new and old Spis. Nothing magical > there. Your jar just needs to be loaded into the appropriate modules. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151019/8a9d302a/attachment-0001.html From d.rami85 at gmail.com Mon Oct 19 03:52:52 2015 From: d.rami85 at gmail.com (=?UTF-8?Q?David_Ram=C3=ADrez?=) Date: Mon, 19 Oct 2015 09:52:52 +0200 Subject: [keycloak-dev] Communications links failure Message-ID: Hi guys, do you know something about this error? In a first time it was seem all was ok. Apparently keycloak updated correctly my new database although this WARN https://issues.jboss.org/browse/KEYCLOAK-1506 appeared. I signed in like admin and I made some operations correctly but when I logout and sign in again Keycloak crashed. I'm working with *MariaDB version:10.0.12*. This is the error: 09:20:45,808 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-39) SQL Error: 0, SQLState: 08S01 09:20:45,813 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-39) Communications link failure The last packet successfully received from the server was 920.157 milliseconds ago. The last packet sent successfully to the server was 0 milliseconds ago. 09:20:45,820 ERROR [io.undertow.request] (default task-39) UT005023: Exception handling request to /auth/admin/realms: java.lang.RuntimeException: request path: /auth/admin/realms at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:73) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: org.jboss.resteasy.spi.UnhandledException: javax.persistence.PersistenceException: org.hibernate.exception.JDBCConnectionException: could not prepare statement at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:59) ... 29 more Caused by: javax.persistence.PersistenceException: org.hibernate.exception.JDBCConnectionException: could not prepare statement at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:458) at org.keycloak.models.jpa.JpaRealmProvider.getRealms(JpaRealmProvider.java:71) at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getRealms(DefaultCacheRealmProvider.java:188) at org.keycloak.services.resources.admin.RealmsAdminResource.getRealms(RealmsAdminResource.java:87) 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) ... 37 more Caused by: org.hibernate.exception.JDBCConnectionException: could not prepare statement at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:132) at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:196) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:160) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1885) at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1862) at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1839) at org.hibernate.loader.Loader.doQuery(Loader.java:910) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:355) at org.hibernate.loader.Loader.doList(Loader.java:2554) at org.hibernate.loader.Loader.doList(Loader.java:2540) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2370) at org.hibernate.loader.Loader.list(Loader.java:2365) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:497) at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:387) at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:236) at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1300) at org.hibernate.internal.QueryImpl.list(QueryImpl.java:103) at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:573) at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:449) ... 50 more Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure The last packet successfully received from the server was 920.157 milliseconds ago. The last packet sent successfully to the server was 0 milliseconds ago. 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:404) at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:983) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3457) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3357) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3797) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2470) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2617) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2546) at com.mysql.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:4873) at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:948) at org.jboss.jca.adapters.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:1623) at org.jboss.jca.adapters.jdbc.WrappedConnection.prepareStatement(WrappedConnection.java:427) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:162) at org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:186) ... 67 more Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost. at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2949) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3367) ... 78 more any ideas? could my database version the problem? thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151019/1de92223/attachment.html From sthorger at redhat.com Mon Oct 19 04:02:10 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 19 Oct 2015 10:02:10 +0200 Subject: [keycloak-dev] Communications links failure In-Reply-To: References: Message-ID: Looks like a db issue rather than a Keycloak issue. Is your db actually up and running correctly? You should be able to safely ignore KEYCLOAK-1506 . For the record we don't actually support MariaDB, although we do support MySQL. On 19 October 2015 at 09:52, David Ram?rez wrote: > Hi guys, > > do you know something about this error? > > In a first time it was seem all was ok. Apparently keycloak updated > correctly my new database although this WARN > https://issues.jboss.org/browse/KEYCLOAK-1506 appeared. > > I signed in like admin and I made some operations correctly but when I > logout and sign in again Keycloak crashed. > > I'm working with *MariaDB version:10.0.12*. > > This is the error: > > > 09:20:45,808 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] > (default task-39) SQL Error: 0, SQLState: 08S01 09:20:45,813 ERROR > [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-39) > Communications link failure The last packet successfully received from the > server was 920.157 milliseconds ago. The last packet sent successfully to > the server was 0 milliseconds ago. 09:20:45,820 ERROR [io.undertow.request] > (default task-39) UT005023: Exception handling request to > /auth/admin/realms: java.lang.RuntimeException: request path: > /auth/admin/realms at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:73) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) Caused by: > org.jboss.resteasy.spi.UnhandledException: > javax.persistence.PersistenceException: > org.hibernate.exception.JDBCConnectionException: could not prepare > statement at > org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) > at > org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) > at > org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:59) > ... 29 more Caused by: javax.persistence.PersistenceException: > org.hibernate.exception.JDBCConnectionException: could not prepare > statement at > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) > at > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) > at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:458) > at > org.keycloak.models.jpa.JpaRealmProvider.getRealms(JpaRealmProvider.java:71) > at > org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getRealms(DefaultCacheRealmProvider.java:188) > at > org.keycloak.services.resources.admin.RealmsAdminResource.getRealms(RealmsAdminResource.java:87) > 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) > ... 37 more Caused by: org.hibernate.exception.JDBCConnectionException: > could not prepare statement at > org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:132) > at > org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) > at > org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) > at > org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:196) > at > org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:160) > at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1885) at > org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1862) at > org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1839) at > org.hibernate.loader.Loader.doQuery(Loader.java:910) at > org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:355) > at org.hibernate.loader.Loader.doList(Loader.java:2554) at > org.hibernate.loader.Loader.doList(Loader.java:2540) at > org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2370) at > org.hibernate.loader.Loader.list(Loader.java:2365) at > org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:497) at > org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:387) > at > org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:236) > at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1300) at > org.hibernate.internal.QueryImpl.list(QueryImpl.java:103) at > org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:573) at > org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:449) ... > 50 more Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: > Communications link failure The last packet successfully received from the > server was 920.157 milliseconds ago. The last packet sent successfully to > the server was 0 milliseconds ago. 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:404) at > com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:983) at > com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3457) at > com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3357) at > com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3797) at > com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2470) at > com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2617) at > com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2546) at > com.mysql.jdbc.ConnectionImpl.setAutoCommit(ConnectionImpl.java:4873) at > org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.checkTransaction(BaseWrapperManagedConnection.java:948) > at > org.jboss.jca.adapters.jdbc.WrappedConnection.checkTransaction(WrappedConnection.java:1623) > at > org.jboss.jca.adapters.jdbc.WrappedConnection.prepareStatement(WrappedConnection.java:427) > at > org.hibernate.engine.jdbc.internal.StatementPreparerImpl$5.doPrepare(StatementPreparerImpl.java:162) > at > org.hibernate.engine.jdbc.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:186) > ... 67 more Caused by: java.io.EOFException: Can not read response from > server. Expected to read 4 bytes, read 0 bytes before connection was > unexpectedly lost. at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2949) > at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3367) ... 78 more > any ideas? could my database version the problem? thanks! > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151019/ccd3f412/attachment-0001.html From psilva at redhat.com Mon Oct 19 08:01:20 2015 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 19 Oct 2015 08:01:20 -0400 (EDT) Subject: [keycloak-dev] Using events to track repository updates In-Reply-To: References: <1062295451.47430011.1445001065068.JavaMail.zimbra@redhat.com> <1992470867.47433520.1445001361208.JavaMail.zimbra@redhat.com> Message-ID: <693798216.48229972.1445256080004.JavaMail.zimbra@redhat.com> Awesome, so I'm on the right path ... ----- Original Message ----- From: "Stian Thorgersen" To: "Pedro Igor Silva" Cc: "keycloak dev" Sent: Monday, October 19, 2015 4:29:27 AM Subject: Re: [keycloak-dev] Using events to track repository updates Yes, that's the best we got On 16 October 2015 at 15:16, Pedro Igor Silva wrote: > Hi, > > Are KC events, like ClientCreationEvent (and probably a missing > ClientRemovedEvent), the recommended way to keep different repositories in > sync ? In case you have to manage FKs programmatically ... > > Regards. > Pedro Igor > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From psilva at redhat.com Mon Oct 19 08:24:59 2015 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 19 Oct 2015 08:24:59 -0400 (EDT) Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: References: Message-ID: <1445913672.48271500.1445257499103.JavaMail.zimbra@redhat.com> Hey Crhisthian, As Bill said, we are working on an Authz Server for Keycloak in order to provide fine-grained permissions. It is still a working in progress, although we already have a baseline for a first release which will happen very soon. From a migration perspective, while PL provides a rich Permission Java API, Keycloak will provide a distributable authorization server based on a RESTful API to manage resources, policies, evaluate policies, obtain entitlements and plus other goodies. In other words, Keycloak will become a PAP (Policy Administration Point), a PDP (Policy Decision Point) and a Entitlements Server. Everything based on OpenID Connect (and of course, oAuth2). As you know, Keycloak is a feature rich, OOTB and easy to use security as a service solution. We are considering these same premises for the authz server, so you can protect web apps, RESTful APIs or any other resources very easily. For instance, you'll be able to write policies using JBoss Drools, EL and easily extend your existing oAuth2 clients in order ask for permissions or enforce them (in case your client acts as a resource server). I'm afraid there will be no "migragration path" between PL and KC, at this sense. But we can work together to make this migration easier. For instance, we are going to provide a Protection API which can be used to manage resources and policies remotely. Regards. Pedro Igor ----- Original Message ----- From: "Cristhian Camilo Lopez" To: keycloak-dev at lists.jboss.org Sent: Sunday, October 18, 2015 3:16:30 PM Subject: Re: [keycloak-dev] Authz Model Implementation Hi Pedro, I'm migrating from Picketlink, but I haven't found the way to use fine-grained permissions, Could u give me some advice on this ? Thanks, Cristhian. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From arthurshakal at gmail.com Mon Oct 19 08:45:24 2015 From: arthurshakal at gmail.com (=?UTF-8?Q?Arthur_Greg=C3=B3rio?=) Date: Mon, 19 Oct 2015 10:45:24 -0200 Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: <1445913672.48271500.1445257499103.JavaMail.zimbra@redhat.com> References: <1445913672.48271500.1445257499103.JavaMail.zimbra@redhat.com> Message-ID: Then KC will not have a model in the style of the PL? This means that those who used the PL hoping that everything in it was in KC turned out to have a framework discontinued and with no more updates? Or the PL as it exists today will continue to be developed and there will be a plus integration with KC? I am very confused by the merge of the projects, it appears that the security of my system already died before were born. at., *Arthur P. Greg?rio* *+55 45 9958-0302* @gregorioarthur www.arthurgregorio.eti.br 2015-10-19 10:24 GMT-02:00 Pedro Igor Silva : > Hey Crhisthian, > > As Bill said, we are working on an Authz Server for Keycloak in order > to provide fine-grained permissions. It is still a working in progress, > although we already have a baseline for a first release which will happen > very soon. > > From a migration perspective, while PL provides a rich Permission Java > API, Keycloak will provide a distributable authorization server based on a > RESTful API to manage resources, policies, evaluate policies, obtain > entitlements and plus other goodies. In other words, Keycloak will become a > PAP (Policy Administration Point), a PDP (Policy Decision Point) and a > Entitlements Server. Everything based on OpenID Connect (and of course, > oAuth2). > > As you know, Keycloak is a feature rich, OOTB and easy to use security > as a service solution. We are considering these same premises for the authz > server, so you can protect web apps, RESTful APIs or any other resources > very easily. For instance, you'll be able to write policies using JBoss > Drools, EL and easily extend your existing oAuth2 clients in order ask for > permissions or enforce them (in case your client acts as a resource server). > > I'm afraid there will be no "migragration path" between PL and KC, at > this sense. But we can work together to make this migration easier. For > instance, we are going to provide a Protection API which can be used to > manage resources and policies remotely. > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Cristhian Camilo Lopez" > To: keycloak-dev at lists.jboss.org > Sent: Sunday, October 18, 2015 3:16:30 PM > Subject: Re: [keycloak-dev] Authz Model Implementation > > > > Hi Pedro, > > I'm migrating from Picketlink, but I haven't found the way to use > fine-grained permissions, Could u give me some advice on this ? > > Thanks, > > Cristhian. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151019/913420e3/attachment.html From bburke at redhat.com Mon Oct 19 08:55:23 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 19 Oct 2015 08:55:23 -0400 Subject: [keycloak-dev] improvements to client creation In-Reply-To: References: <562140E4.2040800@redhat.com> Message-ID: <5624E83B.8010900@redhat.com> I think we have too many tabs on client page. Maybe if the roles tab is moved off? On 10/19/2015 2:32 AM, Stian Thorgersen wrote: > Instead of having the create and edit pages different. Why don't we have > only those fields shown by default, then have a expandable field or a > separate tab with the "advanced options"? > > On 16 October 2015 at 20:24, Bill Burke > wrote: > > I'd like to improve the client creation page to reduce the amount of > info somebody needs to type in the first page and to provide base > defaults. I'll add this as a jira and schedule for 1.7 or 1.8 > > Create page required config (only these will be shown): > * Client Id > * protocol > * Root URL > > For OIDC defaults would be: > * confidential client > * full scoped > * valid redirect urls Root URL/* > * consent required false > * direct grants only false > * service accounts enabled false > * Base URL renamed to Link URL defaults to root url > * Web Origins defaults to host of Root URL > * Remove admin url, this would just point to the root. > > For SAML: > * Sign documents true > * Include Authn Statement true > * Client signature required true > * Sign assertions false > * Client private/public cert would be generated > * force post binding false > * encrypt assertions false > * front channel logout false > * Remove valid redirect URLs > * Remvoe Master SAML Processing URL > * Assertion Consumer and Logout Service binding urls all filled in with > Root URL. > > SAML would get an Installation tab and could choose configurations for: > * Keycloak SAML adapter > * mod-auth-mellon > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Mon Oct 19 08:57:27 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 19 Oct 2015 14:57:27 +0200 Subject: [keycloak-dev] improvements to client creation In-Reply-To: <5624E83B.8010900@redhat.com> References: <562140E4.2040800@redhat.com> <5624E83B.8010900@redhat.com> Message-ID: +1 There's a lot We could also use the extra level of tabs we have used on security defences On 19 October 2015 at 14:55, Bill Burke wrote: > I think we have too many tabs on client page. Maybe if the roles tab is > moved off? > > > > > On 10/19/2015 2:32 AM, Stian Thorgersen wrote: > >> Instead of having the create and edit pages different. Why don't we have >> only those fields shown by default, then have a expandable field or a >> separate tab with the "advanced options"? >> >> On 16 October 2015 at 20:24, Bill Burke > > wrote: >> >> I'd like to improve the client creation page to reduce the amount of >> info somebody needs to type in the first page and to provide base >> defaults. I'll add this as a jira and schedule for 1.7 or 1.8 >> >> Create page required config (only these will be shown): >> * Client Id >> * protocol >> * Root URL >> >> For OIDC defaults would be: >> * confidential client >> * full scoped >> * valid redirect urls Root URL/* >> * consent required false >> * direct grants only false >> * service accounts enabled false >> * Base URL renamed to Link URL defaults to root url >> * Web Origins defaults to host of Root URL >> * Remove admin url, this would just point to the root. >> >> For SAML: >> * Sign documents true >> * Include Authn Statement true >> * Client signature required true >> * Sign assertions false >> * Client private/public cert would be generated >> * force post binding false >> * encrypt assertions false >> * front channel logout false >> * Remove valid redirect URLs >> * Remvoe Master SAML Processing URL >> * Assertion Consumer and Logout Service binding urls all filled in >> with >> Root URL. >> >> SAML would get an Installation tab and could choose configurations >> for: >> * Keycloak SAML adapter >> * mod-auth-mellon >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > -- > 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-dev/attachments/20151019/9f410edc/attachment.html From sthorger at redhat.com Mon Oct 19 08:57:52 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 19 Oct 2015 14:57:52 +0200 Subject: [keycloak-dev] improvements to client creation In-Reply-To: References: <562140E4.2040800@redhat.com> <5624E83B.8010900@redhat.com> Message-ID: BTW maybe we should do this after the feature freeze and focus on getting the last features in first? On 19 October 2015 at 14:57, Stian Thorgersen wrote: > +1 There's a lot > > We could also use the extra level of tabs we have used on security defences > > On 19 October 2015 at 14:55, Bill Burke wrote: > >> I think we have too many tabs on client page. Maybe if the roles tab is >> moved off? >> >> >> >> >> On 10/19/2015 2:32 AM, Stian Thorgersen wrote: >> >>> Instead of having the create and edit pages different. Why don't we have >>> only those fields shown by default, then have a expandable field or a >>> separate tab with the "advanced options"? >>> >>> On 16 October 2015 at 20:24, Bill Burke >> > wrote: >>> >>> I'd like to improve the client creation page to reduce the amount of >>> info somebody needs to type in the first page and to provide base >>> defaults. I'll add this as a jira and schedule for 1.7 or 1.8 >>> >>> Create page required config (only these will be shown): >>> * Client Id >>> * protocol >>> * Root URL >>> >>> For OIDC defaults would be: >>> * confidential client >>> * full scoped >>> * valid redirect urls Root URL/* >>> * consent required false >>> * direct grants only false >>> * service accounts enabled false >>> * Base URL renamed to Link URL defaults to root url >>> * Web Origins defaults to host of Root URL >>> * Remove admin url, this would just point to the root. >>> >>> For SAML: >>> * Sign documents true >>> * Include Authn Statement true >>> * Client signature required true >>> * Sign assertions false >>> * Client private/public cert would be generated >>> * force post binding false >>> * encrypt assertions false >>> * front channel logout false >>> * Remove valid redirect URLs >>> * Remvoe Master SAML Processing URL >>> * Assertion Consumer and Logout Service binding urls all filled in >>> with >>> Root URL. >>> >>> SAML would get an Installation tab and could choose configurations >>> for: >>> * Keycloak SAML adapter >>> * mod-auth-mellon >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >> -- >> 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-dev/attachments/20151019/84e1df50/attachment-0001.html From calovi86 at gmail.com Mon Oct 19 09:56:12 2015 From: calovi86 at gmail.com (Cristhian Lopez) Date: Mon, 19 Oct 2015 08:56:12 -0500 Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: References: <1445913672.48271500.1445257499103.JavaMail.zimbra@redhat.com> Message-ID: <9934FA4D-A6CD-4115-8132-AF66D54A0948@gmail.com> Thanks for your clear answer Pedro, I understand the vision that KC is aiming to achieve and now I know what requirements I?m going to be able to cover with the KC approach. Also, following the Arthur concerns, IMO the in-house security solutions that were built using PL are going to follow a different path from KC and will have to be maintained with resources inside the company or they can extend the SPI that will be provided by KC and this still will require a high inside resources demand. I think KC will work for my needs and I will be interested in contributing if it?s possible. I?m looking forward to test the Authz server. Regards, Cristhian. > On Oct 19, 2015, at 7:45 AM, Arthur Greg?rio wrote: > > Then KC will not have a model in the style of the PL? > > This means that those who used the PL hoping that everything in it was in KC turned out to have a framework discontinued and with no more updates? > > Or the PL as it exists today will continue to be developed and there will be a plus integration with KC? > > I am very confused by the merge of the projects, it appears that the security of my system already died before were born. > > at., > > Arthur P. Greg?rio > +55 45 9958-0302 > @gregorioarthur > www.arthurgregorio.eti.br > > 2015-10-19 10:24 GMT-02:00 Pedro Igor Silva >: > Hey Crhisthian, > > As Bill said, we are working on an Authz Server for Keycloak in order to provide fine-grained permissions. It is still a working in progress, although we already have a baseline for a first release which will happen very soon. > > From a migration perspective, while PL provides a rich Permission Java API, Keycloak will provide a distributable authorization server based on a RESTful API to manage resources, policies, evaluate policies, obtain entitlements and plus other goodies. In other words, Keycloak will become a PAP (Policy Administration Point), a PDP (Policy Decision Point) and a Entitlements Server. Everything based on OpenID Connect (and of course, oAuth2). > > As you know, Keycloak is a feature rich, OOTB and easy to use security as a service solution. We are considering these same premises for the authz server, so you can protect web apps, RESTful APIs or any other resources very easily. For instance, you'll be able to write policies using JBoss Drools, EL and easily extend your existing oAuth2 clients in order ask for permissions or enforce them (in case your client acts as a resource server). > > I'm afraid there will be no "migragration path" between PL and KC, at this sense. But we can work together to make this migration easier. For instance, we are going to provide a Protection API which can be used to manage resources and policies remotely. > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Cristhian Camilo Lopez" > > To: keycloak-dev at lists.jboss.org > Sent: Sunday, October 18, 2015 3:16:30 PM > Subject: Re: [keycloak-dev] Authz Model Implementation > > > > Hi Pedro, > > I'm migrating from Picketlink, but I haven't found the way to use fine-grained permissions, Could u give me some advice on this ? > > Thanks, > > Cristhian. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151019/388ee462/attachment.html From bburke at redhat.com Mon Oct 19 10:15:51 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 19 Oct 2015 10:15:51 -0400 Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: References: <1445913672.48271500.1445257499103.JavaMail.zimbra@redhat.com> Message-ID: <5624FB17.9070006@redhat.com> A lot of the PL APIs are going to go away. We want tight and focused SPIs that leverage the rest of the Keycloak platform and vision. Not broad generic APIs for rolling your own SSO solution. We want something out of the box that for most cases a user doesn't have to be a Java programmer to use and deploy Keycloak. You just have to have a focused and specific security model to provide an out of the box solution and focused vision. That being said, what we've learned is that developers have broad and different requirements when it comes to authorization and permissions. This is where an API, backed by the authz server, would be very useful. Pedro was involved with PLs permission APIs and I'm confident he has some really good ideas for evolving it. On 10/19/2015 8:45 AM, Arthur Greg?rio wrote: > Then KC will not have a model in the style of the PL? > > This means that those who used the PL hoping that everything in it was > in KC turned out to have a framework discontinued and with no more updates? > > Or the PL as it exists today will continue to be developed and there > will be a plus integration with KC? > > I am very confused by the merge of the projects, it appears that the > security of my system already died before were born. > > at., > > *Arthur P. Greg?rio* > /+55 45 9958-0302/ > @gregorioarthur > www.arthurgregorio.eti.br > > 2015-10-19 10:24 GMT-02:00 Pedro Igor Silva >: > > Hey Crhisthian, > > As Bill said, we are working on an Authz Server for Keycloak in > order to provide fine-grained permissions. It is still a working in > progress, although we already have a baseline for a first release > which will happen very soon. > > From a migration perspective, while PL provides a rich > Permission Java API, Keycloak will provide a distributable > authorization server based on a RESTful API to manage resources, > policies, evaluate policies, obtain entitlements and plus other > goodies. In other words, Keycloak will become a PAP (Policy > Administration Point), a PDP (Policy Decision Point) and a > Entitlements Server. Everything based on OpenID Connect (and of > course, oAuth2). > > As you know, Keycloak is a feature rich, OOTB and easy to use > security as a service solution. We are considering these same > premises for the authz server, so you can protect web apps, RESTful > APIs or any other resources very easily. For instance, you'll be > able to write policies using JBoss Drools, EL and easily extend your > existing oAuth2 clients in order ask for permissions or enforce them > (in case your client acts as a resource server). > > I'm afraid there will be no "migragration path" between PL and > KC, at this sense. But we can work together to make this migration > easier. For instance, we are going to provide a Protection API which > can be used to manage resources and policies remotely. > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Cristhian Camilo Lopez" > > To: keycloak-dev at lists.jboss.org > Sent: Sunday, October 18, 2015 3:16:30 PM > Subject: Re: [keycloak-dev] Authz Model Implementation > > > > Hi Pedro, > > I'm migrating from Picketlink, but I haven't found the way to use > fine-grained permissions, Could u give me some advice on this ? > > Thanks, > > Cristhian. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Mon Oct 19 10:18:21 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 19 Oct 2015 16:18:21 +0200 Subject: [keycloak-dev] Master ready for 1.7 development Message-ID: Master is now ready to accept commits for 1.7. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151019/8af26abf/attachment.html From bburke at redhat.com Mon Oct 19 10:19:11 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 19 Oct 2015 10:19:11 -0400 Subject: [keycloak-dev] improvements to client creation In-Reply-To: References: <562140E4.2040800@redhat.com> <5624E83B.8010900@redhat.com> Message-ID: <5624FBDF.5010500@redhat.com> Yeah, that's fine. I just wanted to make sure this was scheduled. On 10/19/2015 8:57 AM, Stian Thorgersen wrote: > BTW maybe we should do this after the feature freeze and focus on > getting the last features in first? > > On 19 October 2015 at 14:57, Stian Thorgersen > wrote: > > +1 There's a lot > > We could also use the extra level of tabs we have used on security > defences > > On 19 October 2015 at 14:55, Bill Burke > wrote: > > I think we have too many tabs on client page. Maybe if the > roles tab is moved off? > > > > > On 10/19/2015 2:32 AM, Stian Thorgersen wrote: > > Instead of having the create and edit pages different. Why > don't we have > only those fields shown by default, then have a expandable > field or a > separate tab with the "advanced options"? > > On 16 October 2015 at 20:24, Bill Burke > >> wrote: > > I'd like to improve the client creation page to reduce > the amount of > info somebody needs to type in the first page and to > provide base > defaults. I'll add this as a jira and schedule for 1.7 > or 1.8 > > Create page required config (only these will be shown): > * Client Id > * protocol > * Root URL > > For OIDC defaults would be: > * confidential client > * full scoped > * valid redirect urls Root URL/* > * consent required false > * direct grants only false > * service accounts enabled false > * Base URL renamed to Link URL defaults to root url > * Web Origins defaults to host of Root URL > * Remove admin url, this would just point to the root. > > For SAML: > * Sign documents true > * Include Authn Statement true > * Client signature required true > * Sign assertions false > * Client private/public cert would be generated > * force post binding false > * encrypt assertions false > * front channel logout false > * Remove valid redirect URLs > * Remvoe Master SAML Processing URL > * Assertion Consumer and Logout Service binding urls > all filled in with > Root URL. > > SAML would get an Installation tab and could choose > configurations for: > * Keycloak SAML adapter > * mod-auth-mellon > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Oct 19 10:40:22 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 19 Oct 2015 10:40:22 -0400 Subject: [keycloak-dev] hierarchical only groups? Message-ID: <562500D6.7080401@redhat.com> I was wondering if it would be ok to only have parent/child, tree structure relationship between groups. Meaning, a group can't belong to multiple groups. I was just thinking about modeling a large company with groups. How would you visualize the group structure within the admin console? A hierarchical-only group structure would allow you to define a group with a simple non-unique names. i.e. "admins", "customers". -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Oct 19 10:47:32 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 19 Oct 2015 10:47:32 -0400 Subject: [keycloak-dev] angular tree view Message-ID: <56250284.7060605@redhat.com> https://github.com/eu81273/angular.treeview FYI. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From psilva at redhat.com Mon Oct 19 13:01:45 2015 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 19 Oct 2015 13:01:45 -0400 (EDT) Subject: [keycloak-dev] Authz Model Implementation In-Reply-To: References: <1445913672.48271500.1445257499103.JavaMail.zimbra@redhat.com> Message-ID: <483099033.50545632.1445274105226.JavaMail.zimbra@redhat.com> Hey Arthur, Please, take a look at this announcement [1] for more details about the merge. [1] http://picketlink.org/news/2015/03/10/PicketLink-and-Keycloak-project-merge/ Regards. Pedro Igor ----- Original Message ----- From: "Arthur Greg?rio" To: "Pedro Igor Silva" Cc: "Cristhian Camilo Lopez" , keycloak-dev at lists.jboss.org Sent: Monday, October 19, 2015 10:45:24 AM Subject: Re: [keycloak-dev] Authz Model Implementation Then KC will not have a model in the style of the PL? This means that those who used the PL hoping that everything in it was in KC turned out to have a framework discontinued and with no more updates? Or the PL as it exists today will continue to be developed and there will be a plus integration with KC? I am very confused by the merge of the projects, it appears that the security of my system already died before were born. at., *Arthur P. Greg?rio* *+55 45 9958-0302* @gregorioarthur www.arthurgregorio.eti.br 2015-10-19 10:24 GMT-02:00 Pedro Igor Silva : > Hey Crhisthian, > > As Bill said, we are working on an Authz Server for Keycloak in order > to provide fine-grained permissions. It is still a working in progress, > although we already have a baseline for a first release which will happen > very soon. > > From a migration perspective, while PL provides a rich Permission Java > API, Keycloak will provide a distributable authorization server based on a > RESTful API to manage resources, policies, evaluate policies, obtain > entitlements and plus other goodies. In other words, Keycloak will become a > PAP (Policy Administration Point), a PDP (Policy Decision Point) and a > Entitlements Server. Everything based on OpenID Connect (and of course, > oAuth2). > > As you know, Keycloak is a feature rich, OOTB and easy to use security > as a service solution. We are considering these same premises for the authz > server, so you can protect web apps, RESTful APIs or any other resources > very easily. For instance, you'll be able to write policies using JBoss > Drools, EL and easily extend your existing oAuth2 clients in order ask for > permissions or enforce them (in case your client acts as a resource server). > > I'm afraid there will be no "migragration path" between PL and KC, at > this sense. But we can work together to make this migration easier. For > instance, we are going to provide a Protection API which can be used to > manage resources and policies remotely. > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Cristhian Camilo Lopez" > To: keycloak-dev at lists.jboss.org > Sent: Sunday, October 18, 2015 3:16:30 PM > Subject: Re: [keycloak-dev] Authz Model Implementation > > > > Hi Pedro, > > I'm migrating from Picketlink, but I haven't found the way to use > fine-grained permissions, Could u give me some advice on this ? > > Thanks, > > Cristhian. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Tue Oct 20 07:48:30 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 20 Oct 2015 13:48:30 +0200 Subject: [keycloak-dev] hierarchical only groups? In-Reply-To: <562500D6.7080401@redhat.com> References: <562500D6.7080401@redhat.com> Message-ID: <56262A0E.1050408@redhat.com> That's similar to how it worked for GateIn portal . There was only parent-child notion and each group could be identified easily by path consisting of it's simple name and parent hierarchy. For example root group "platform" had path "/platform" . The subgroup "finance" of root group "platform" had path "/platform/finance" etc. All the roles were always assigned to user per group, so there was notion like: User "john" is member of role "admin" in group "/platform/finance" etc. Visualization was quite easy - some screenshots are here: https://docs.jboss.org/author/display/GTNPORTAL39/Manage+Users+and+Groups . I think this model was sufficient (at least for portal purposes). Can't any customer wanted the structure with group being child of multiple parent groups. Marek On 19/10/15 16:40, Bill Burke wrote: > I was wondering if it would be ok to only have parent/child, tree > structure relationship between groups. Meaning, a group can't belong to > multiple groups. > > I was just thinking about modeling a large company with groups. How > would you visualize the group structure within the admin console? A > hierarchical-only group structure would allow you to define a group with > a simple non-unique names. i.e. "admins", "customers". From sthorger at redhat.com Tue Oct 20 10:24:41 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Oct 2015 16:24:41 +0200 Subject: [keycloak-dev] hierarchical only groups? In-Reply-To: <56262A0E.1050408@redhat.com> References: <562500D6.7080401@redhat.com> <56262A0E.1050408@redhat.com> Message-ID: I'm sure there are benefits of a group belonging to groups, but I think it's outweighed by the complexity involved. On 20 October 2015 at 13:48, Marek Posolda wrote: > That's similar to how it worked for GateIn portal . There was only > parent-child notion and each group could be identified easily by path > consisting of it's simple name and parent hierarchy. For example root > group "platform" had path "/platform" . The subgroup "finance" of root > group "platform" had path "/platform/finance" etc. > > All the roles were always assigned to user per group, so there was > notion like: User "john" is member of role "admin" in group > "/platform/finance" etc. Visualization was quite easy - some screenshots > are here: > https://docs.jboss.org/author/display/GTNPORTAL39/Manage+Users+and+Groups > . > > I think this model was sufficient (at least for portal purposes). Can't > any customer wanted the structure with group being child of multiple > parent groups. > > Marek > > > On 19/10/15 16:40, Bill Burke wrote: > > I was wondering if it would be ok to only have parent/child, tree > > structure relationship between groups. Meaning, a group can't belong to > > multiple groups. > > > > I was just thinking about modeling a large company with groups. How > > would you visualize the group structure within the admin console? A > > hierarchical-only group structure would allow you to define a group with > > a simple non-unique names. i.e. "admins", "customers". > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151020/312e51c4/attachment.html From ssilvert at redhat.com Tue Oct 20 10:32:37 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 20 Oct 2015 10:32:37 -0400 Subject: [keycloak-dev] Import Clients? Message-ID: <56265085.7050409@redhat.com> It looks like there is a partially-implemented facility to import clients from admin console? client-list.html has this: {{:: 'import' | translate}}> But I can't find any reference to the "importButton" flag, so it looks like it is never set and the button never shows up. Can anyone tell me more about the state of this feature? Is it supposed to work? From sthorger at redhat.com Tue Oct 20 10:40:22 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Oct 2015 16:40:22 +0200 Subject: [keycloak-dev] Import Clients? In-Reply-To: <56265085.7050409@redhat.com> References: <56265085.7050409@redhat.com> Message-ID: Import clients is fully functional - click on create new client and there's an option to import there. On 20 October 2015 at 16:32, Stan Silvert wrote: > It looks like there is a partially-implemented facility to import > clients from admin console? > > client-list.html has this: > href="#/import/client/{{realm.realm}}" data-ng-show="importButton">{{:: > 'import' | translate}}> > > But I can't find any reference to the "importButton" flag, so it looks > like it is never set and the button never shows up. > > Can anyone tell me more about the state of this feature? > Is it supposed to work? > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151020/01402d6f/attachment.html From sthorger at redhat.com Tue Oct 20 10:40:46 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Oct 2015 16:40:46 +0200 Subject: [keycloak-dev] Import Clients? In-Reply-To: References: <56265085.7050409@redhat.com> Message-ID: Import client (single) that is.. We don't have support to import clients (plural). On 20 October 2015 at 16:40, Stian Thorgersen wrote: > Import clients is fully functional - click on create new client and > there's an option to import there. > > On 20 October 2015 at 16:32, Stan Silvert wrote: > >> It looks like there is a partially-implemented facility to import >> clients from admin console? >> >> client-list.html has this: >> > href="#/import/client/{{realm.realm}}" data-ng-show="importButton">{{:: >> 'import' | translate}}> >> >> But I can't find any reference to the "importButton" flag, so it looks >> like it is never set and the button never shows up. >> >> Can anyone tell me more about the state of this feature? >> Is it supposed to work? >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151020/924d7f5a/attachment-0001.html From ssilvert at redhat.com Tue Oct 20 10:46:59 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 20 Oct 2015 10:46:59 -0400 Subject: [keycloak-dev] Import Clients? In-Reply-To: References: <56265085.7050409@redhat.com> Message-ID: <562653E3.8040107@redhat.com> I see. What do you think about removing that when I add import clients (plural)? Import client (single) is just a subset of the new functionality, so it doesn't make sense to have two ways to do the same thing. On 10/20/2015 10:40 AM, Stian Thorgersen wrote: > Import client (single) that is.. We don't have support to import > clients (plural). > > On 20 October 2015 at 16:40, Stian Thorgersen > wrote: > > Import clients is fully functional - click on create new client > and there's an option to import there. > > On 20 October 2015 at 16:32, Stan Silvert > wrote: > > It looks like there is a partially-implemented facility to import > clients from admin console? > > client-list.html has this: > href="#/import/client/{{realm.realm}}" > data-ng-show="importButton">{{:: > 'import' | translate}}> > > But I can't find any reference to the "importButton" flag, so > it looks > like it is never set and the button never shows up. > > Can anyone tell me more about the state of this feature? > Is it supposed to work? > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151020/5d9103fe/attachment.html From sthorger at redhat.com Tue Oct 20 10:53:39 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Oct 2015 16:53:39 +0200 Subject: [keycloak-dev] Keycloak 1.6.0.Final Released Message-ID: We're pleased to announce the release of Keycloak 1.6.0.Final. - *SAML SP* - in the past we only had client libraries for OpenID Connect, now we also have client libraries for SAML - *Offline Tokens* - if your applications need long term access outside of the users session you should take a look at the new offline tokens support we've added - *Client Registration* - we introduced a new rest api that can be used to automate the registration of clients, this includes a java client library. This feature will be further polished in a future release, including documentation and examples - *Import Clients in Admin Console* - it's now possible to import clients through the admin console using the Keycloak JSON client representation or OpenID Connect descriptions - *Added Root URL to Clients* - we've added a root url to clients. For clients that have a root url defined you can use relative urls for redirect uris and other urls - *Internationalization support in Admin Console* - we've added support for internationalization of the Admin Console. Around half the pages now support translation and the rest will be added in the next release For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151020/90fdc320/attachment.html From sthorger at redhat.com Tue Oct 20 10:54:00 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 20 Oct 2015 16:54:00 +0200 Subject: [keycloak-dev] Import Clients? In-Reply-To: <562653E3.8040107@redhat.com> References: <56265085.7050409@redhat.com> <562653E3.8040107@redhat.com> Message-ID: No, we want to keep the import single on the create page On 20 October 2015 at 16:46, Stan Silvert wrote: > I see. > > What do you think about removing that when I add import clients (plural)? > > Import client (single) is just a subset of the new functionality, so it > doesn't make sense to have two ways to do the same thing. > > > On 10/20/2015 10:40 AM, Stian Thorgersen wrote: > > Import client (single) that is.. We don't have support to import clients > (plural). > > On 20 October 2015 at 16:40, Stian Thorgersen wrote: > >> Import clients is fully functional - click on create new client and >> there's an option to import there. >> >> On 20 October 2015 at 16:32, Stan Silvert wrote: >> >>> It looks like there is a partially-implemented facility to import >>> clients from admin console? >>> >>> client-list.html has this: >>> >> href="#/import/client/{{realm.realm}}" data-ng-show="importButton">{{:: >>> 'import' | translate}}> >>> >>> But I can't find any reference to the "importButton" flag, so it looks >>> like it is never set and the button never shows up. >>> >>> Can anyone tell me more about the state of this feature? >>> Is it supposed to work? >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151020/6a874320/attachment.html From sthorger at redhat.com Wed Oct 21 03:09:36 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 09:09:36 +0200 Subject: [keycloak-dev] U2F implemetation In-Reply-To: <1915394626.40128278.1444137088661.JavaMail.zimbra@redhat.com> References: <13802065.40123403.1444136587423.JavaMail.zimbra@redhat.com> <1915394626.40128278.1444137088661.JavaMail.zimbra@redhat.com> Message-ID: Hi Greg, Sorry for the late response. We'd love a contribution for U2F. You should start by looking into the new Authenticator SPI ( http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html ). First step would be to implement a U2F Authenticator that can replace the current OTP Authenticator for a realm. Second step would be to make it possible for users to select which mechanism they want to use if a realm has multiple available. Not sure how exactly we'd do this. I can look into this some more. On 6 October 2015 at 15:11, Greg Autric wrote: > Hi All, > > I would like develop the u2f feature. > I noticed the JIRA ticket [1] > I would like to know how can I begin with ? > - 2/3 key classes > - add u2f attribut to User Model > - maybe reuse OTP workflow/action > > by advance, thx for your help > > [1] https://issues.jboss.org/browse/KEYCLOAK-1409 > > Greg AUTRIC > JBoss Middleware Consultant > > email : gautric __at__ redhat __dot__ com > twitter : @gautric_io > > Red Hat Global Services > Red Hat France SARL sit: http://www.redhat.fr > Le Linea, 1 rue du General Leclerc, 92047 Paris La D?fense Cedex > Sent from webmail > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/343b8d4f/attachment-0001.html From mposolda at redhat.com Wed Oct 21 03:31:58 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 21 Oct 2015 09:31:58 +0200 Subject: [keycloak-dev] Autogeneration of admin-client REST API Message-ID: <56273F6E.4030103@redhat.com> Was wondering if resteasy has some way to autogenerate REST endpoints inside integration/admin-client to be automatically synced with the REST endpoints from keycloak-services ? So for example when I add new REST endpoint on server-side into org.keycloak.services.resources.RealmsResource class, the admin-client class org.keycloak.admin.client.resource.RealmsResource will be automatically updated too . Ideally there can be maven target executed on demand for update admin-client sources. That would help to avoid unsynced endpoints in admin-client - issues like https://issues.jboss.org/browse/KEYCLOAK-1967 . Marek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/44d3ee5e/attachment.html From sthorger at redhat.com Wed Oct 21 03:40:20 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 09:40:20 +0200 Subject: [keycloak-dev] Autogeneration of admin-client REST API In-Reply-To: <56273F6E.4030103@redhat.com> References: <56273F6E.4030103@redhat.com> Message-ID: I don't like the use of RestEasy client for these in the first place. It doesn't make a very nice Java library IMO. Something like: void createRealm(RealmRepresentation rep) throws AdminException Would be much better than: Response createRealm(RealmRepresentation rep) Under the covers the implementation could use RestEasy client, but I don't think the current approach creates a very nice API. On 21 October 2015 at 09:31, Marek Posolda wrote: > Was wondering if resteasy has some way to autogenerate REST endpoints > inside integration/admin-client to be automatically synced with the REST > endpoints from keycloak-services ? > > So for example when I add new REST endpoint on server-side into > org.keycloak.services.resources .RealmsResource class, the admin-client > class org.keycloak.admin.client.resource.RealmsResource will be > automatically updated too . Ideally there can be maven target executed on > demand for update admin-client sources. That would help to avoid unsynced > endpoints in admin-client - issues like > https://issues.jboss.org/browse/KEYCLOAK-1967 . > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/821b4781/attachment.html From lkrzyzan at redhat.com Wed Oct 21 03:58:40 2015 From: lkrzyzan at redhat.com (Libor Krzyzanek) Date: Wed, 21 Oct 2015 09:58:40 +0200 Subject: [keycloak-dev] 1.6.0.Final pom version tag/commit missing Message-ID: <72DF8126-93E0-4AF1-ACDC-B4176A13AC58@redhat.com> Hi there, I have to build org.keycloak:keycloak-testsuite-integration:tests:1.6.0.Final because it?s not in maven repo. I?m fine to build it from sources but I don?t see any commit/tag with 1.6.0.Final in poms. I would expect that tag 1.6.0.Final https://github.com/keycloak/keycloak/tree/1.6.0.Final would have exactly 1.6.0.Final version not 1.6.0.Final-SNAPSHOT in maven poms. Would be possible when you?re increasing number in poms to follow this: 1.6.0.Final-SNAPSHOT 1.6.0.Final <- do tag from this commit 1.7.0.Final-SNAPSHOT WDYT? Thanks, Libor Krzy?anek jboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/68de57f5/attachment.html From sthorger at redhat.com Wed Oct 21 04:00:35 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 10:00:35 +0200 Subject: [keycloak-dev] Batch import/export Message-ID: After your last email with regards to removing the import button from client create page I had an idea. How about we do the following: Import/export single -------------------------- On realm, client, identity provider and user federation create pages we add the import button. This will prefill the form and let the user review before importing. This is how realm and client works now. We'd also add a link to export a single entity when displaying it in the admin console (next to the delete icon). Batch export ----------------- When exporting a realm you can select what you want to export. The option would include realm settings, clients, identity brokers, user federation, users, credentials. Further there would be an option if export would be done to a file or a json download. If export to file is selected you would get the option to export credentials for users, if json download is selected that option would be disabled. Batch import ----------------- We should have options to import a realm as well as import into an existing realm. For this we should have an option to select what happens if resources exists (for example client with client-id exists, or user with username exists). Options could be replace, skip, warn, error, etc.. Finally I was also thinking about an option where we'd have a import directory on the server. Any files in this would be imported on startup. Once imported we'd add a ".imported" or ".failed". Same here it would be nice to be able to somehow specify the strategy if the resource exists. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/27429da2/attachment.html From sthorger at redhat.com Wed Oct 21 04:02:05 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 10:02:05 +0200 Subject: [keycloak-dev] 1.6.0.Final pom version tag/commit missing In-Reply-To: <72DF8126-93E0-4AF1-ACDC-B4176A13AC58@redhat.com> References: <72DF8126-93E0-4AF1-ACDC-B4176A13AC58@redhat.com> Message-ID: Fixed On 21 October 2015 at 09:58, Libor Krzyzanek wrote: > Hi there, > I have to build org.keycloak:keycloak-testsuite-integration:tests:1.6.0.Final > because it?s not in maven repo. > > I?m fine to build it from sources but I don?t see any commit/tag with > 1.6.0.Final in poms. > > I would expect that tag 1.6.0.Final > https://github.com/keycloak/keycloak/tree/1.6.0.Final would have exactly > 1.6.0.Final version not 1.6.0.Final-SNAPSHOT in maven poms. > > Would be possible when you?re increasing number in poms to follow this: > 1.6.0.Final-SNAPSHOT > 1.6.0.Final <- do tag from this commit > 1.7.0.Final-SNAPSHOT > > WDYT? > > Thanks, > > > Libor Krzy?anek > jboss.org Development Team > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/4bf80640/attachment.html From thomas.raehalme at aitiofinland.com Wed Oct 21 04:06:09 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 21 Oct 2015 11:06:09 +0300 Subject: [keycloak-dev] Batch import/export In-Reply-To: References: Message-ID: I think all of these sound useful! May I suggest another useful option when importing realm or client, which is to re-generate keys and secrets? Best regards, Thomas On Wed, Oct 21, 2015 at 11:00 AM, Stian Thorgersen wrote: > After your last email with regards to removing the import button from > client create page I had an idea. > > How about we do the following: > > > Import/export single > -------------------------- > On realm, client, identity provider and user federation create pages we > add the import button. This will prefill the form and let the user review > before importing. This is how realm and client works now. We'd also add a > link to export a single entity when displaying it in the admin console > (next to the delete icon). > > Batch export > ----------------- > When exporting a realm you can select what you want to export. The option > would include realm settings, clients, identity brokers, user federation, > users, credentials. Further there would be an option if export would be > done to a file or a json download. If export to file is selected you would > get the option to export credentials for users, if json download is > selected that option would be disabled. > > Batch import > ----------------- > We should have options to import a realm as well as import into an > existing realm. For this we should have an option to select what happens if > resources exists (for example client with client-id exists, or user with > username exists). Options could be replace, skip, warn, error, etc.. > > > Finally I was also thinking about an option where we'd have a import > directory on the server. Any files in this would be imported on startup. > Once imported we'd add a ".imported" or ".failed". Same > here it would be nice to be able to somehow specify the strategy if the > resource exists. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/af6731af/attachment-0001.html From lkrzyzan at redhat.com Wed Oct 21 04:29:38 2015 From: lkrzyzan at redhat.com (Libor Krzyzanek) Date: Wed, 21 Oct 2015 10:29:38 +0200 Subject: [keycloak-dev] 1.6.0.Final pom version tag/commit missing In-Reply-To: References: <72DF8126-93E0-4AF1-ACDC-B4176A13AC58@redhat.com> Message-ID: <94116392-621A-41D2-B6B6-0298D0F16CC2@redhat.com> Appreciated. Libor Krzy?anek jboss.org Development Team > On Oct 21, 2015, at 10:02 AM, Stian Thorgersen wrote: > > Fixed > > On 21 October 2015 at 09:58, Libor Krzyzanek > wrote: > Hi there, > I have to build org.keycloak:keycloak-testsuite-integration:tests:1.6.0.Final because it?s not in maven repo. > > I?m fine to build it from sources but I don?t see any commit/tag with 1.6.0.Final in poms. > > I would expect that tag 1.6.0.Final https://github.com/keycloak/keycloak/tree/1.6.0.Final would have exactly 1.6.0.Final version not 1.6.0.Final-SNAPSHOT in maven poms. > > Would be possible when you?re increasing number in poms to follow this: > 1.6.0.Final-SNAPSHOT > 1.6.0.Final <- do tag from this commit > 1.7.0.Final-SNAPSHOT > > WDYT? > > Thanks, > > > Libor Krzy?anek > jboss.org Development Team > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/c41896b2/attachment.html From mposolda at redhat.com Wed Oct 21 05:16:15 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 21 Oct 2015 11:16:15 +0200 Subject: [keycloak-dev] Autogeneration of admin-client REST API In-Reply-To: References: <56273F6E.4030103@redhat.com> Message-ID: <562757DF.3000109@redhat.com> The nicer API will be good, but IMO it is more important the REST endpoints are up-to-date . Which is not the case now. I believe the autogeneration will help with having the admin-client endpoints synced with the stuff from server. Unfortunately it seems to me that it will be challenge to have nice API and autogeneration at the same time :-\ Marek On 21/10/15 09:40, Stian Thorgersen wrote: > I don't like the use of RestEasy client for these in the first place. > It doesn't make a very nice Java library IMO. Something like: > > void createRealm(RealmRepresentation rep) throws AdminException > > Would be much better than: > > Response createRealm(RealmRepresentation rep) > > Under the covers the implementation could use RestEasy client, but I > don't think the current approach creates a very nice API. > > On 21 October 2015 at 09:31, Marek Posolda > wrote: > > Was wondering if resteasy has some way to autogenerate REST > endpoints inside integration/admin-client to be automatically > synced with the REST endpoints from keycloak-services ? > > So for example when I add new REST endpoint on server-side into > org.keycloak.services.resources.RealmsResource class, the > admin-client class > org.keycloak.admin.client.resource.RealmsResource will be > automatically updated too . Ideally there can be maven target > executed on demand for update admin-client sources. That would > help to avoid unsynced endpoints in admin-client - issues like > https://issues.jboss.org/browse/KEYCLOAK-1967 . > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/3a6ade4d/attachment.html From sthorger at redhat.com Wed Oct 21 06:00:34 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 12:00:34 +0200 Subject: [keycloak-dev] Batch import/export In-Reply-To: References: Message-ID: Those are nice additional options we could have. Simply have a checkbox to re-generate realm keys and another checkbox to re-generate client secrets (if a client is using jwt auth then we shouldn't re-generate the keys for the client as we don't store the private key). On 21 October 2015 at 10:06, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > I think all of these sound useful! > > May I suggest another useful option when importing realm or client, which > is to re-generate keys and secrets? > > Best regards, > Thomas > > On Wed, Oct 21, 2015 at 11:00 AM, Stian Thorgersen > wrote: > >> After your last email with regards to removing the import button from >> client create page I had an idea. >> >> How about we do the following: >> >> >> Import/export single >> -------------------------- >> On realm, client, identity provider and user federation create pages we >> add the import button. This will prefill the form and let the user review >> before importing. This is how realm and client works now. We'd also add a >> link to export a single entity when displaying it in the admin console >> (next to the delete icon). >> >> Batch export >> ----------------- >> When exporting a realm you can select what you want to export. The option >> would include realm settings, clients, identity brokers, user federation, >> users, credentials. Further there would be an option if export would be >> done to a file or a json download. If export to file is selected you would >> get the option to export credentials for users, if json download is >> selected that option would be disabled. >> >> Batch import >> ----------------- >> We should have options to import a realm as well as import into an >> existing realm. For this we should have an option to select what happens if >> resources exists (for example client with client-id exists, or user with >> username exists). Options could be replace, skip, warn, error, etc.. >> >> >> Finally I was also thinking about an option where we'd have a import >> directory on the server. Any files in this would be imported on startup. >> Once imported we'd add a ".imported" or ".failed". Same >> here it would be nice to be able to somehow specify the strategy if the >> resource exists. >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/617a965f/attachment.html From sthorger at redhat.com Wed Oct 21 06:02:11 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 12:02:11 +0200 Subject: [keycloak-dev] Autogeneration of admin-client REST API In-Reply-To: <562757DF.3000109@redhat.com> References: <56273F6E.4030103@redhat.com> <562757DF.3000109@redhat.com> Message-ID: We should just go ahead an improve the admin api. Then we make sure this is used when testing. Anyone doing changes to the admin endpoints should in the future write tests for it, which should use the admin api. On 21 October 2015 at 11:16, Marek Posolda wrote: > The nicer API will be good, but IMO it is more important the REST > endpoints are up-to-date . Which is not the case now. I believe the > autogeneration will help with having the admin-client endpoints synced with > the stuff from server. > > Unfortunately it seems to me that it will be challenge to have nice API > and autogeneration at the same time :-\ > > Marek > > > On 21/10/15 09:40, Stian Thorgersen wrote: > > I don't like the use of RestEasy client for these in the first place. It > doesn't make a very nice Java library IMO. Something like: > > void createRealm(RealmRepresentation rep) throws AdminException > > Would be much better than: > > Response createRealm(RealmRepresentation rep) > > Under the covers the implementation could use RestEasy client, but I don't > think the current approach creates a very nice API. > > On 21 October 2015 at 09:31, Marek Posolda wrote: > >> Was wondering if resteasy has some way to autogenerate REST endpoints >> inside integration/admin-client to be automatically synced with the REST >> endpoints from keycloak-services ? >> >> So for example when I add new REST endpoint on server-side into >> org.keycloak.services.resources .RealmsResource class, the admin-client >> class org.keycloak.admin.client.resource.RealmsResource will be >> automatically updated too . Ideally there can be maven target executed on >> demand for update admin-client sources. That would help to avoid unsynced >> endpoints in admin-client - issues like >> https://issues.jboss.org/browse/KEYCLOAK-1967 . >> >> Marek >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/8aee664e/attachment-0001.html From ssilvert at redhat.com Wed Oct 21 08:15:56 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 21 Oct 2015 08:15:56 -0400 Subject: [keycloak-dev] Batch import/export In-Reply-To: References: Message-ID: <562781FC.2020207@redhat.com> I like those ideas too. Some have already been talked about but regarded as "nice to have". The question is do we want me to spend extra weeks on all those features or do we want to get started on CLI? Right now, I have batch import implemented for Users, Clients, and Identity Providers. It's easy to add the replace, skip, error feature, so I'll probably spend a couple of extra hours today doing that. Personally, I think the best approach is to implement the simplest possible version of the feature and then get feedback to see what enhancements are really needed. If you want to try out the import feature, It's here: https://github.com/ssilvert/keycloak/tree/user-import-export On 10/21/2015 6:00 AM, Stian Thorgersen wrote: > Those are nice additional options we could have. Simply have a > checkbox to re-generate realm keys and another checkbox to re-generate > client secrets (if a client is using jwt auth then we shouldn't > re-generate the keys for the client as we don't store the private key). > > On 21 October 2015 at 10:06, Thomas Raehalme > > wrote: > > I think all of these sound useful! > > May I suggest another useful option when importing realm or > client, which is to re-generate keys and secrets? > > Best regards, > Thomas > > On Wed, Oct 21, 2015 at 11:00 AM, Stian Thorgersen > > wrote: > > After your last email with regards to removing the import > button from client create page I had an idea. > > How about we do the following: > > > Import/export single > -------------------------- > On realm, client, identity provider and user federation create > pages we add the import button. This will prefill the form and > let the user review before importing. This is how realm and > client works now. We'd also add a link to export a single > entity when displaying it in the admin console (next to the > delete icon). > > Batch export > ----------------- > When exporting a realm you can select what you want to export. > The option would include realm settings, clients, identity > brokers, user federation, users, credentials. Further there > would be an option if export would be done to a file or a json > download. If export to file is selected you would get the > option to export credentials for users, if json download is > selected that option would be disabled. > > Batch import > ----------------- > We should have options to import a realm as well as import > into an existing realm. For this we should have an option to > select what happens if resources exists (for example client > with client-id exists, or user with username exists). Options > could be replace, skip, warn, error, etc.. > > > Finally I was also thinking about an option where we'd have a > import directory on the server. Any files in this would be > imported on startup. Once imported we'd add a > ".imported" or ".failed". Same here it > would be nice to be able to somehow specify the strategy if > the resource exists. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/0cae5025/attachment.html From sthorger at redhat.com Wed Oct 21 08:27:45 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 14:27:45 +0200 Subject: [keycloak-dev] Batch import/export In-Reply-To: <562781FC.2020207@redhat.com> References: <562781FC.2020207@redhat.com> Message-ID: I'd like to get import/export done properly. The addition of being able to add bits and pieces to import in a directory would be really helpful on Docker/OpenShift/etc.. Besides, CLI is on hold until we decide what to do. We're not going to decide on that in the next week weeks. I'm not sure we have the resources available to do CLI properly before Christmas, so it would probably be better to wait. On 21 October 2015 at 14:15, Stan Silvert wrote: > I like those ideas too. Some have already been talked about but regarded > as "nice to have". > > The question is do we want me to spend extra weeks on all those features > or do we want to get started on CLI? > > Right now, I have batch import implemented for Users, Clients, and > Identity Providers. It's easy to add the replace, skip, error feature, so > I'll probably spend a couple of extra hours today doing that. > > Personally, I think the best approach is to implement the simplest > possible version of the feature and then get feedback to see what > enhancements are really needed. If you want to try out the import feature, > It's here: > https://github.com/ssilvert/keycloak/tree/user-import-export > > > On 10/21/2015 6:00 AM, Stian Thorgersen wrote: > > Those are nice additional options we could have. Simply have a checkbox to > re-generate realm keys and another checkbox to re-generate client secrets > (if a client is using jwt auth then we shouldn't re-generate the keys for > the client as we don't store the private key). > > On 21 October 2015 at 10:06, Thomas Raehalme < > thomas.raehalme at aitiofinland.com> wrote: > >> I think all of these sound useful! >> >> May I suggest another useful option when importing realm or client, which >> is to re-generate keys and secrets? >> >> Best regards, >> Thomas >> >> On Wed, Oct 21, 2015 at 11:00 AM, Stian Thorgersen >> wrote: >> >>> After your last email with regards to removing the import button from >>> client create page I had an idea. >>> >>> How about we do the following: >>> >>> >>> Import/export single >>> -------------------------- >>> On realm, client, identity provider and user federation create pages we >>> add the import button. This will prefill the form and let the user review >>> before importing. This is how realm and client works now. We'd also add a >>> link to export a single entity when displaying it in the admin console >>> (next to the delete icon). >>> >>> Batch export >>> ----------------- >>> When exporting a realm you can select what you want to export. The >>> option would include realm settings, clients, identity brokers, user >>> federation, users, credentials. Further there would be an option if export >>> would be done to a file or a json download. If export to file is selected >>> you would get the option to export credentials for users, if json download >>> is selected that option would be disabled. >>> >>> Batch import >>> ----------------- >>> We should have options to import a realm as well as import into an >>> existing realm. For this we should have an option to select what happens if >>> resources exists (for example client with client-id exists, or user with >>> username exists). Options could be replace, skip, warn, error, etc.. >>> >>> >>> Finally I was also thinking about an option where we'd have a import >>> directory on the server. Any files in this would be imported on startup. >>> Once imported we'd add a ".imported" or ".failed". Same >>> here it would be nice to be able to somehow specify the strategy if the >>> resource exists. >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/c4827fbb/attachment.html From thomas.raehalme at aitiofinland.com Wed Oct 21 08:29:59 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 21 Oct 2015 15:29:59 +0300 Subject: [keycloak-dev] Batch import/export In-Reply-To: References: <562781FC.2020207@redhat.com> Message-ID: On Wed, Oct 21, 2015 at 3:27 PM, Stian Thorgersen wrote: > I'd like to get import/export done properly. The addition of being able to > add bits and pieces to import in a directory would be really helpful on > Docker/OpenShift/etc.. > I had similar things in mind when I suggested the re-generation of keys and secrets. You could define a template which you'd use in a process for new deployments. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/e1b3a7f6/attachment-0001.html From sthorger at redhat.com Wed Oct 21 08:33:40 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 14:33:40 +0200 Subject: [keycloak-dev] Batch import/export In-Reply-To: References: <562781FC.2020207@redhat.com> Message-ID: Can you elaborate a bit on that? On 21 October 2015 at 14:29, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > > > On Wed, Oct 21, 2015 at 3:27 PM, Stian Thorgersen > wrote: > >> I'd like to get import/export done properly. The addition of being able >> to add bits and pieces to import in a directory would be really helpful on >> Docker/OpenShift/etc.. >> > > I had similar things in mind when I suggested the re-generation of keys > and secrets. You could define a template which you'd use in a process for > new deployments. > > Best regards, > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/1cedceec/attachment.html From thomas.raehalme at aitiofinland.com Wed Oct 21 08:40:50 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 21 Oct 2015 15:40:50 +0300 Subject: [keycloak-dev] Batch import/export In-Reply-To: References: <562781FC.2020207@redhat.com> Message-ID: If you deploy the same application multiple times for different customers you could have a configuration template containing all the common bits and pieces, but have Keycloak generate keys and secrets when you import the configuration. Best regards, Thomas On Wed, Oct 21, 2015 at 3:33 PM, Stian Thorgersen wrote: > Can you elaborate a bit on that? > > On 21 October 2015 at 14:29, Thomas Raehalme < > thomas.raehalme at aitiofinland.com> wrote: > >> >> >> On Wed, Oct 21, 2015 at 3:27 PM, Stian Thorgersen >> wrote: >> >>> I'd like to get import/export done properly. The addition of being able >>> to add bits and pieces to import in a directory would be really helpful on >>> Docker/OpenShift/etc.. >>> >> >> I had similar things in mind when I suggested the re-generation of keys >> and secrets. You could define a template which you'd use in a process for >> new deployments. >> >> Best regards, >> Thomas >> > > -- *Thomas Raehalme* *CTO, teknologiajohtaja* Mobile +358 40 545 0605 *Aitio Finland Oy* V?in?nkatu 26 A 40100 JYV?SKYL?, Finland Tel. +358 10 322 0040 www.aitiofinland.com *Codecenter on nyt Aitio ? me kun ei vain koodata!* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/77b68bdc/attachment.html From sthorger at redhat.com Wed Oct 21 08:44:11 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 14:44:11 +0200 Subject: [keycloak-dev] Batch import/export In-Reply-To: References: <562781FC.2020207@redhat.com> Message-ID: I've just added client registration services in 1.6 which should be more useful for that. There's also a Java library. Basically admins and service accounts with the role create-client can create new clients, while clients themselves have permissions to update their config. You could have a client template that you change the client-id only then use this endpoint to register the client. On 21 October 2015 at 14:40, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > If you deploy the same application multiple times for different customers > you could have a configuration template containing all the common bits and > pieces, but have Keycloak generate keys and secrets when you import the > configuration. > > Best regards, > Thomas > > > On Wed, Oct 21, 2015 at 3:33 PM, Stian Thorgersen > wrote: > >> Can you elaborate a bit on that? >> >> On 21 October 2015 at 14:29, Thomas Raehalme < >> thomas.raehalme at aitiofinland.com> wrote: >> >>> >>> >>> On Wed, Oct 21, 2015 at 3:27 PM, Stian Thorgersen >>> wrote: >>> >>>> I'd like to get import/export done properly. The addition of being able >>>> to add bits and pieces to import in a directory would be really helpful on >>>> Docker/OpenShift/etc.. >>>> >>> >>> I had similar things in mind when I suggested the re-generation of keys >>> and secrets. You could define a template which you'd use in a process for >>> new deployments. >>> >>> Best regards, >>> Thomas >>> >> >> > > > -- > *Thomas Raehalme* > *CTO, teknologiajohtaja* > Mobile +358 40 545 0605 > > *Aitio Finland Oy* > V?in?nkatu 26 A > 40100 JYV?SKYL?, Finland > Tel. +358 10 322 0040 > www.aitiofinland.com > > *Codecenter on nyt Aitio ? me kun ei vain koodata!* > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/8fb4ae00/attachment.html From sthorger at redhat.com Wed Oct 21 08:59:17 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 14:59:17 +0200 Subject: [keycloak-dev] Access datasource from a CLI Message-ID: It would be nice to have an "offline" cli that can be used to configure Keycloak. If we roll our own CLI for that and it uses jboss-modules do you reckon we can get access to the datasources somehow? This is for things like setting the admin password, import/export from cli, etc.. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/f332b9e1/attachment.html From ssilvert at redhat.com Wed Oct 21 10:05:54 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 21 Oct 2015 10:05:54 -0400 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: Message-ID: <56279BC2.50005@redhat.com> On 10/21/2015 8:59 AM, Stian Thorgersen wrote: > It would be nice to have an "offline" cli that can be used to > configure Keycloak. If we roll our own CLI for that and it uses > jboss-modules do you reckon we can get access to the datasources > somehow? This is for things like setting the admin password, > import/export from cli, etc.. That's what WildFly's "offline CLI" feature was built for: http://wildfly.org/news/2015/03/13/Offline-CLI/ Of course, anything is possible, but doing this ourselves involves more than just using jboss-modules. You have to start up the environment that lets you use whatever technology you are choosing to connect to the data. If we want to reuse our current code for that then it means starting container environments such as CDI, JPA, and other dependencies, then wiring them together and starting our own stripped-down version of the overall server. Probably, we would end up doing exactly what WildFly CLI does and just embed the server into our CLI process. Then we are back to the problem of actually getting access to the datasource. That's really a problem whether we roll our own or not. In embedded mode, you can't use the REST API because no inbound connections are allowed. Any CLI will run outside the container. So you are always faced with accessing the container context from outside the container, which is next to impossible. This is the land of the java.lang.LinkageError. So you need some way to call into the container using a serialized data format. If there is a way to do in-process, port-less REST calls then that's probably the easiest solution. But I'm really grasping at straws here. I'd have to do some research to find out what our options are. From mstrukel at redhat.com Wed Oct 21 10:43:32 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 21 Oct 2015 16:43:32 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: <56279BC2.50005@redhat.com> References: <56279BC2.50005@redhat.com> Message-ID: Since Wildfly's config is persisted into a single standalone.xml file, the offline mode can be achieved simply by editing that file. It would bypass all MDR model checks as defined by services, so it's up to our console to not generate a corrupt config, which may mean it would have to contain subsystem version specific information. But that would only be necessary for subsystems that we would touch. We might try with Wildfly Swarm to boot a programatically configured bare minimum to get datasources / mongo / ldap connectors and use them directly. But any such approach would not build on jboss-cli, and would have to start with some other console as a base, maybe something like CraSH ( http://www.crashub.org/). On Wed, Oct 21, 2015 at 4:05 PM, Stan Silvert wrote: > On 10/21/2015 8:59 AM, Stian Thorgersen wrote: > > It would be nice to have an "offline" cli that can be used to > > configure Keycloak. If we roll our own CLI for that and it uses > > jboss-modules do you reckon we can get access to the datasources > > somehow? This is for things like setting the admin password, > > import/export from cli, etc.. > That's what WildFly's "offline CLI" feature was built for: > http://wildfly.org/news/2015/03/13/Offline-CLI/ > > Of course, anything is possible, but doing this ourselves involves more > than just using jboss-modules. You have to start up the environment > that lets you use whatever technology you are choosing to connect to the > data. If we want to reuse our current code for that then it means > starting container environments such as CDI, JPA, and other > dependencies, then wiring them together and starting our own > stripped-down version of the overall server. > > Probably, we would end up doing exactly what WildFly CLI does and just > embed the server into our CLI process. > > Then we are back to the problem of actually getting access to the > datasource. That's really a problem whether we roll our own or not. In > embedded mode, you can't use the REST API because no inbound connections > are allowed. > > Any CLI will run outside the container. So you are always faced with > accessing the container context from outside the container, which is > next to impossible. This is the land of the java.lang.LinkageError. So > you need some way to call into the container using a serialized data > format. If there is a way to do in-process, port-less REST calls then > that's probably the easiest solution. But I'm really grasping at straws > here. I'd have to do some research to find out what our options are. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/5d1b5170/attachment-0001.html From ssilvert at redhat.com Wed Oct 21 11:02:03 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 21 Oct 2015 11:02:03 -0400 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <56279BC2.50005@redhat.com> Message-ID: <5627A8EB.9000708@redhat.com> On 10/21/2015 10:43 AM, Marko Strukelj wrote: > Since Wildfly's config is persisted into a single standalone.xml file, > the offline mode can be achieved simply by editing that file. It would > bypass all MDR model checks as defined by services, so it's up to our > console to not generate a corrupt config, which may mean it would have > to contain subsystem version specific information. But that would only > be necessary for subsystems that we would touch. > > We might try with Wildfly Swarm to boot a programatically configured > bare minimum to get datasources / mongo / ldap connectors and use them > directly. I don't see how that helps you use datasources directly. From what I understand of Swarm, it's just a different way to start the same containers. But you still have the problem of accessing from outside the container. Or, you need something akin to Bill's SSH solution where the WAR actually kicks off the CLI. (At one point Bill was proposing that our WAR expose a port that someone could SSH into and issue commands. But that was eventually rejected.) > > But any such approach would not build on jboss-cli, and would have to > start with some other console as a base, maybe something like CraSH > (http://www.crashub.org/). > > On Wed, Oct 21, 2015 at 4:05 PM, Stan Silvert > wrote: > > On 10/21/2015 8:59 AM, Stian Thorgersen wrote: > > It would be nice to have an "offline" cli that can be used to > > configure Keycloak. If we roll our own CLI for that and it uses > > jboss-modules do you reckon we can get access to the datasources > > somehow? This is for things like setting the admin password, > > import/export from cli, etc.. > That's what WildFly's "offline CLI" feature was built for: > http://wildfly.org/news/2015/03/13/Offline-CLI/ > > Of course, anything is possible, but doing this ourselves involves > more > than just using jboss-modules. You have to start up the environment > that lets you use whatever technology you are choosing to connect > to the > data. If we want to reuse our current code for that then it means > starting container environments such as CDI, JPA, and other > dependencies, then wiring them together and starting our own > stripped-down version of the overall server. > > Probably, we would end up doing exactly what WildFly CLI does and just > embed the server into our CLI process. > > Then we are back to the problem of actually getting access to the > datasource. That's really a problem whether we roll our own or > not. In > embedded mode, you can't use the REST API because no inbound > connections > are allowed. > > Any CLI will run outside the container. So you are always faced with > accessing the container context from outside the container, which is > next to impossible. This is the land of the > java.lang.LinkageError. So > you need some way to call into the container using a serialized data > format. If there is a way to do in-process, port-less REST calls then > that's probably the easiest solution. But I'm really grasping at > straws > here. I'd have to do some research to find out what our options are. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/3459671e/attachment.html From mstrukel at redhat.com Wed Oct 21 11:14:22 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 21 Oct 2015 17:14:22 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: <5627A8EB.9000708@redhat.com> References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> Message-ID: I haven't taken a very close look at Swarm yet, but I assumed you start Wildfly embedded in the same JVM as your Main class. If that is the case, then there should be no problem communicating with any kind of deployed component via heap directly - just lookup some singleton ... If that is not the case, then we would need some kind of interprocess communication going. With shell the roles of who connects where could also be reversed, and a started up Wildfly instance could have a service connecting out to local port bound by our CLI rather than the other way around. I'm throwing out ideas here, not really knowing what are the hard constraints that we don't want to violate ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/191d9f1f/attachment.html From ssilvert at redhat.com Wed Oct 21 11:57:28 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 21 Oct 2015 11:57:28 -0400 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> Message-ID: <5627B5E8.2000208@redhat.com> On 10/21/2015 11:14 AM, Marko Strukelj wrote: > I haven't taken a very close look at Swarm yet, but I assumed you > start Wildfly embedded in the same JVM as your Main class. If that is > the case, then there should be no problem communicating with any kind > of deployed component via heap directly - just lookup some singleton ... Classloading constraints are what you usually run up against. You can't use your own version of a class that was loaded from a different classloader. I don't think Swarm helps you get around that, but just assumes you will access the WAR in the usual way through an HTTP port. But I could be wrong as I haven't worked with Swarm either. Here is an explanation of the problem based on an old version of JBoss: https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html With jboss-modules, it's easier to get around these problems, but you still run into the isolation built into the container itself, especially in the case of a WAR. > > If that is not the case, then we would need some kind of interprocess > communication going. With shell the roles of who connects where could > also be reversed, and a started up Wildfly instance could have a > service connecting out to local port bound by our CLI rather than the > other way around. I don't think the direction of the connection matters so much as the fact that you need a serialized format to issue commands to a foreign container. Or, as I mentioned, you need the CLI to actually live inside the container. > > I'm throwing out ideas here, not really knowing what are the hard > constraints that we don't want to violate ... > From mstrukel at redhat.com Wed Oct 21 12:22:24 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 21 Oct 2015 18:22:24 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: <5627B5E8.2000208@redhat.com> References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> Message-ID: On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert wrote: > On 10/21/2015 11:14 AM, Marko Strukelj wrote: > >> I haven't taken a very close look at Swarm yet, but I assumed you start >> Wildfly embedded in the same JVM as your Main class. If that is the case, >> then there should be no problem communicating with any kind of deployed >> component via heap directly - just lookup some singleton ... >> > Classloading constraints are what you usually run up against. You can't > use your own version of a class that was loaded from a different > classloader. I don't think Swarm helps you get around that, but just > assumes you will access the WAR in the usual way through an HTTP port. But > I could be wrong as I haven't worked with Swarm either. > > Here is an explanation of the problem based on an old version of JBoss: > > https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html > > With jboss-modules, it's easier to get around these problems, but you > still run into the isolation built into the container itself, especially in > the case of a WAR. CLI running in the same JVM as Wildfly would get bootstrapped through jboss-modules, and would package it's classes as a jboss module. It can then deploy additional 'in-container' logic that needs actual access to datasources via many different mechanisms. It can be a .jar containing a SLSB, a .war, a .sar, a POJO (via pojo subsystem), it can be a custom subsystem that gets installed ... In every of these cases it can then have access to resource objects bound to java:jboss JNDI space ... And in every of these cases it uses shared types loaded via dependencies on jboss-modules. >> If that is not the case, then we would need some kind of interprocess >> communication going. With shell the roles of who connects where could also >> be reversed, and a started up Wildfly instance could have a service >> connecting out to local port bound by our CLI rather than the other way >> around. >> > I don't think the direction of the connection matters so much as the fact > that you need a serialized format to issue commands to a foreign container. > > Or, as I mentioned, you need the CLI to actually live inside the container. CLI needs to be able to execute its logic inside the container in order to harness the datasources, but the UI part that takes care of getting the inputs and displaying the outputs - e.g. CraSH, does not have to be inside the container. I don't know what you mean by 'serialized format to issue commands to a foreign container', but if it means taking care of UI interaction, CraSH looks pretty decent CLI, easy to extend with custom commands. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/d7174655/attachment.html From tkyjovsk at redhat.com Wed Oct 21 12:23:16 2015 From: tkyjovsk at redhat.com (Tomas Kyjovsky) Date: Wed, 21 Oct 2015 12:23:16 -0400 (EDT) Subject: [keycloak-dev] Event log consistency - EventBuilder using client.getClientId() In-Reply-To: <873160926.48008493.1445443757190.JavaMail.zimbra@redhat.com> Message-ID: <735665734.48014163.1445444596404.JavaMail.zimbra@redhat.com> EventBuilder uses client.getClientId() when building new events instead of client.getId() - which is the real "primary key" for the entity. This may cause problems with consistency of the event log. A client can be removed and a new one created with the same clientId but different id. On the other hand, the clientId attribute is also useful when filtering the log. Tomas From sthorger at redhat.com Wed Oct 21 13:23:38 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 19:23:38 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> Message-ID: Guys - all we need is the datasource. I want to create a "db tool" for Keycloak, this is not for the Admin CLI We don't need CDI, EJB, etc.. All we need is the datasource, or at least the connection information for the datasource + we also need JBoss modules so we can get the required classes. If offline mode can do this then that'd be good, but I seem to remember datasources weren't available? On 21 October 2015 at 18:22, Marko Strukelj wrote: > On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert wrote: > >> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >> >>> I haven't taken a very close look at Swarm yet, but I assumed you start >>> Wildfly embedded in the same JVM as your Main class. If that is the case, >>> then there should be no problem communicating with any kind of deployed >>> component via heap directly - just lookup some singleton ... >>> >> Classloading constraints are what you usually run up against. You can't >> use your own version of a class that was loaded from a different >> classloader. I don't think Swarm helps you get around that, but just >> assumes you will access the WAR in the usual way through an HTTP port. But >> I could be wrong as I haven't worked with Swarm either. >> >> Here is an explanation of the problem based on an old version of JBoss: >> >> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >> >> With jboss-modules, it's easier to get around these problems, but you >> still run into the isolation built into the container itself, especially in >> the case of a WAR. > > > CLI running in the same JVM as Wildfly would get bootstrapped through > jboss-modules, and would package it's classes as a jboss module. It can > then deploy additional 'in-container' logic that needs actual access to > datasources via many different mechanisms. It can be a .jar containing a > SLSB, a .war, a .sar, a POJO (via pojo subsystem), it can be a custom > subsystem that gets installed ... In every of these cases it can then have > access to resource objects bound to java:jboss JNDI space ... And in every > of these cases it uses shared types loaded via dependencies on > jboss-modules. > > > >>> If that is not the case, then we would need some kind of interprocess >>> communication going. With shell the roles of who connects where could also >>> be reversed, and a started up Wildfly instance could have a service >>> connecting out to local port bound by our CLI rather than the other way >>> around. >>> >> I don't think the direction of the connection matters so much as the fact >> that you need a serialized format to issue commands to a foreign container. >> >> Or, as I mentioned, you need the CLI to actually live inside the >> container. > > > CLI needs to be able to execute its logic inside the container in order to > harness the datasources, but the UI part that takes care of getting the > inputs and displaying the outputs - e.g. CraSH, does not have to be inside > the container. > > I don't know what you mean by 'serialized format to issue commands to a > foreign container', but if it means taking care of UI interaction, CraSH > looks pretty decent CLI, easy to extend with custom commands. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/9bd65b6f/attachment.html From ssilvert at redhat.com Wed Oct 21 13:53:59 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 21 Oct 2015 13:53:59 -0400 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> Message-ID: <5627D137.2080708@redhat.com> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: > Guys - all we need is the datasource. I want to create a "db tool" for > Keycloak, this is not for the Admin CLI > > We don't need CDI, EJB, etc.. All we need is the datasource, or at > least the connection information for the datasource + we also need > JBoss modules so we can get the required classes. > > If offline mode can do this then that'd be good, but I seem to > remember datasources weren't available? If you want to use our existing JPA infrastructure then you need a JPA container. That's where this other stuff all gets pulled in. Hey, let's just use JDBC! :-) > > On 21 October 2015 at 18:22, Marko Strukelj > wrote: > > On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert > wrote: > > On 10/21/2015 11:14 AM, Marko Strukelj wrote: > > I haven't taken a very close look at Swarm yet, but I > assumed you start Wildfly embedded in the same JVM as your > Main class. If that is the case, then there should be no > problem communicating with any kind of deployed component > via heap directly - just lookup some singleton ... > > Classloading constraints are what you usually run up against. > You can't use your own version of a class that was loaded from > a different classloader. I don't think Swarm helps you get > around that, but just assumes you will access the WAR in the > usual way through an HTTP port. But I could be wrong as I > haven't worked with Swarm either. > > Here is an explanation of the problem based on an old version > of JBoss: > https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html > > With jboss-modules, it's easier to get around these problems, > but you still run into the isolation built into the container > itself, especially in the case of a WAR. > > CLI running in the same JVM as Wildfly would get bootstrapped > through jboss-modules, and would package it's classes as a jboss > module. It can then deploy additional 'in-container' logic that > needs actual access to datasources via many different mechanisms. > It can be a .jar containing a SLSB, a .war, a .sar, a POJO (via > pojo subsystem), it can be a custom subsystem that gets installed > ... In every of these cases it can then have access to resource > objects bound to java:jboss JNDI space ... And in every of these > cases it uses shared types loaded via dependencies on jboss-modules. > > > > If that is not the case, then we would need some kind of > interprocess communication going. With shell the roles of > who connects where could also be reversed, and a started > up Wildfly instance could have a service connecting out to > local port bound by our CLI rather than the other way around. > > I don't think the direction of the connection matters so much > as the fact that you need a serialized format to issue > commands to a foreign container. > > Or, as I mentioned, you need the CLI to actually live inside > the container. > > > CLI needs to be able to execute its logic inside the container in > order to harness the datasources, but the UI part that takes care > of getting the inputs and displaying the outputs - e.g. CraSH, > does not have to be inside the container. > > I don't know what you mean by 'serialized format to issue commands > to a foreign container', but if it means taking care of UI > interaction, CraSH looks pretty decent CLI, easy to extend with > custom commands. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/67550bd1/attachment.html From sthorger at redhat.com Wed Oct 21 13:57:51 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 19:57:51 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: <5627D137.2080708@redhat.com> References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> Message-ID: We manage our own EntityManagerFactory and EntityManager as well as our own transactions. So that's not true. On 21 October 2015 at 19:53, Stan Silvert wrote: > On 10/21/2015 1:23 PM, Stian Thorgersen wrote: > > Guys - all we need is the datasource. I want to create a "db tool" for > Keycloak, this is not for the Admin CLI > > We don't need CDI, EJB, etc.. All we need is the datasource, or at least > the connection information for the datasource + we also need JBoss modules > so we can get the required classes. > > If offline mode can do this then that'd be good, but I seem to remember > datasources weren't available? > > If you want to use our existing JPA infrastructure then you need a JPA > container. That's where this other stuff all gets pulled in. > > Hey, let's just use JDBC! :-) > > > On 21 October 2015 at 18:22, Marko Strukelj wrote: > >> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >> wrote: >> >>> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >>> >>>> I haven't taken a very close look at Swarm yet, but I assumed you start >>>> Wildfly embedded in the same JVM as your Main class. If that is the case, >>>> then there should be no problem communicating with any kind of deployed >>>> component via heap directly - just lookup some singleton ... >>>> >>> Classloading constraints are what you usually run up against. You can't >>> use your own version of a class that was loaded from a different >>> classloader. I don't think Swarm helps you get around that, but just >>> assumes you will access the WAR in the usual way through an HTTP port. But >>> I could be wrong as I haven't worked with Swarm either. >>> >>> Here is an explanation of the problem based on an old version of JBoss: >>> >>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>> >>> With jboss-modules, it's easier to get around these problems, but you >>> still run into the isolation built into the container itself, especially in >>> the case of a WAR. >> >> >> CLI running in the same JVM as Wildfly would get bootstrapped through >> jboss-modules, and would package it's classes as a jboss module. It can >> then deploy additional 'in-container' logic that needs actual access to >> datasources via many different mechanisms. It can be a .jar containing a >> SLSB, a .war, a .sar, a POJO (via pojo subsystem), it can be a custom >> subsystem that gets installed ... In every of these cases it can then have >> access to resource objects bound to java:jboss JNDI space ... And in every >> of these cases it uses shared types loaded via dependencies on >> jboss-modules. >> >> >> >>>> If that is not the case, then we would need some kind of interprocess >>>> communication going. With shell the roles of who connects where could also >>>> be reversed, and a started up Wildfly instance could have a service >>>> connecting out to local port bound by our CLI rather than the other way >>>> around. >>>> >>> I don't think the direction of the connection matters so much as the >>> fact that you need a serialized format to issue commands to a foreign >>> container. >>> >>> Or, as I mentioned, you need the CLI to actually live inside the >>> container. >> >> >> CLI needs to be able to execute its logic inside the container in order >> to harness the datasources, but the UI part that takes care of getting the >> inputs and displaying the outputs - e.g. CraSH, does not have to be inside >> the container. >> >> I don't know what you mean by 'serialized format to issue commands to a >> foreign container', but if it means taking care of UI interaction, CraSH >> looks pretty decent CLI, easy to extend with custom commands. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/af0ddbc6/attachment-0001.html From ssilvert at redhat.com Wed Oct 21 14:08:51 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 21 Oct 2015 14:08:51 -0400 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> Message-ID: <5627D4B3.5030609@redhat.com> On 10/21/2015 1:57 PM, Stian Thorgersen wrote: > We manage our own EntityManagerFactory and EntityManager as well as > our own transactions. So that's not true. If all you need is the datasource info that lives in standalone.xml then yes, we can get that. > > On 21 October 2015 at 19:53, Stan Silvert > wrote: > > On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >> Guys - all we need is the datasource. I want to create a "db >> tool" for Keycloak, this is not for the Admin CLI >> >> We don't need CDI, EJB, etc.. All we need is the datasource, or >> at least the connection information for the datasource + we also >> need JBoss modules so we can get the required classes. >> >> If offline mode can do this then that'd be good, but I seem to >> remember datasources weren't available? > If you want to use our existing JPA infrastructure then you need a > JPA container. That's where this other stuff all gets pulled in. > > Hey, let's just use JDBC! :-) > >> >> On 21 October 2015 at 18:22, Marko Strukelj > > wrote: >> >> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >> > wrote: >> >> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >> >> I haven't taken a very close look at Swarm yet, but I >> assumed you start Wildfly embedded in the same JVM as >> your Main class. If that is the case, then there >> should be no problem communicating with any kind of >> deployed component via heap directly - just lookup >> some singleton ... >> >> Classloading constraints are what you usually run up >> against. You can't use your own version of a class that >> was loaded from a different classloader. I don't think >> Swarm helps you get around that, but just assumes you >> will access the WAR in the usual way through an HTTP >> port. But I could be wrong as I haven't worked with >> Swarm either. >> >> Here is an explanation of the problem based on an old >> version of JBoss: >> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >> >> With jboss-modules, it's easier to get around these >> problems, but you still run into the isolation built into >> the container itself, especially in the case of a WAR. >> >> CLI running in the same JVM as Wildfly would get bootstrapped >> through jboss-modules, and would package it's classes as a >> jboss module. It can then deploy additional 'in-container' >> logic that needs actual access to datasources via many >> different mechanisms. It can be a .jar containing a SLSB, a >> .war, a .sar, a POJO (via pojo subsystem), it can be a custom >> subsystem that gets installed ... In every of these cases it >> can then have access to resource objects bound to java:jboss >> JNDI space ... And in every of these cases it uses shared >> types loaded via dependencies on jboss-modules. >> >> >> >> If that is not the case, then we would need some kind >> of interprocess communication going. With shell the >> roles of who connects where could also be reversed, >> and a started up Wildfly instance could have a >> service connecting out to local port bound by our CLI >> rather than the other way around. >> >> I don't think the direction of the connection matters so >> much as the fact that you need a serialized format to >> issue commands to a foreign container. >> >> Or, as I mentioned, you need the CLI to actually live >> inside the container. >> >> >> CLI needs to be able to execute its logic inside the >> container in order to harness the datasources, but the UI >> part that takes care of getting the inputs and displaying the >> outputs - e.g. CraSH, does not have to be inside the container. >> >> I don't know what you mean by 'serialized format to issue >> commands to a foreign container', but if it means taking care >> of UI interaction, CraSH looks pretty decent CLI, easy to >> extend with custom commands. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/af6853e4/attachment.html From ssilvert at redhat.com Wed Oct 21 14:16:38 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 21 Oct 2015 14:16:38 -0400 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: <5627D4B3.5030609@redhat.com> References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> Message-ID: <5627D686.7030700@redhat.com> On 10/21/2015 2:08 PM, Stan Silvert wrote: > On 10/21/2015 1:57 PM, Stian Thorgersen wrote: >> We manage our own EntityManagerFactory and EntityManager as well as >> our own transactions. So that's not true. > If all you need is the datasource info that lives in standalone.xml > then yes, we can get that. But I'm a little confused as to how this would work. Are you saying that you wouldn't use any of the classes in org.keycloak.models.jpa.entities? Those need containers. > >> >> On 21 October 2015 at 19:53, Stan Silvert > > wrote: >> >> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >>> Guys - all we need is the datasource. I want to create a "db >>> tool" for Keycloak, this is not for the Admin CLI >>> >>> We don't need CDI, EJB, etc.. All we need is the datasource, or >>> at least the connection information for the datasource + we also >>> need JBoss modules so we can get the required classes. >>> >>> If offline mode can do this then that'd be good, but I seem to >>> remember datasources weren't available? >> If you want to use our existing JPA infrastructure then you need >> a JPA container. That's where this other stuff all gets pulled in. >> >> Hey, let's just use JDBC! :-) >> >>> >>> On 21 October 2015 at 18:22, Marko Strukelj >> > wrote: >>> >>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >>> > wrote: >>> >>> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >>> >>> I haven't taken a very close look at Swarm yet, but >>> I assumed you start Wildfly embedded in the same JVM >>> as your Main class. If that is the case, then there >>> should be no problem communicating with any kind of >>> deployed component via heap directly - just lookup >>> some singleton ... >>> >>> Classloading constraints are what you usually run up >>> against. You can't use your own version of a class that >>> was loaded from a different classloader. I don't think >>> Swarm helps you get around that, but just assumes you >>> will access the WAR in the usual way through an HTTP >>> port. But I could be wrong as I haven't worked with >>> Swarm either. >>> >>> Here is an explanation of the problem based on an old >>> version of JBoss: >>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>> >>> With jboss-modules, it's easier to get around these >>> problems, but you still run into the isolation built >>> into the container itself, especially in the case of a WAR. >>> >>> CLI running in the same JVM as Wildfly would get >>> bootstrapped through jboss-modules, and would package it's >>> classes as a jboss module. It can then deploy additional >>> 'in-container' logic that needs actual access to datasources >>> via many different mechanisms. It can be a .jar containing a >>> SLSB, a .war, a .sar, a POJO (via pojo subsystem), it can be >>> a custom subsystem that gets installed ... In every of these >>> cases it can then have access to resource objects bound to >>> java:jboss JNDI space ... And in every of these cases it >>> uses shared types loaded via dependencies on jboss-modules. >>> >>> >>> >>> If that is not the case, then we would need some >>> kind of interprocess communication going. With shell >>> the roles of who connects where could also be >>> reversed, and a started up Wildfly instance could >>> have a service connecting out to local port bound by >>> our CLI rather than the other way around. >>> >>> I don't think the direction of the connection matters so >>> much as the fact that you need a serialized format to >>> issue commands to a foreign container. >>> >>> Or, as I mentioned, you need the CLI to actually live >>> inside the container. >>> >>> >>> CLI needs to be able to execute its logic inside the >>> container in order to harness the datasources, but the UI >>> part that takes care of getting the inputs and displaying >>> the outputs - e.g. CraSH, does not have to be inside the >>> container. >>> >>> I don't know what you mean by 'serialized format to issue >>> commands to a foreign container', but if it means taking >>> care of UI interaction, CraSH looks pretty decent CLI, easy >>> to extend with custom commands. >>> >>> >> >> > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/7a36cf49/attachment-0001.html From sthorger at redhat.com Wed Oct 21 14:43:38 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 20:43:38 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: <5627D686.7030700@redhat.com> References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> <5627D686.7030700@redhat.com> Message-ID: I have no idea what you mean about containers. As I said we manage our own EntityManagerFactory, etc.. inside Keycloak. It doesn't rely on JEE for that part. We just need the classes which we can get with jboss-modules. On 21 October 2015 at 20:16, Stan Silvert wrote: > On 10/21/2015 2:08 PM, Stan Silvert wrote: > > On 10/21/2015 1:57 PM, Stian Thorgersen wrote: > > We manage our own EntityManagerFactory and EntityManager as well as our > own transactions. So that's not true. > > If all you need is the datasource info that lives in standalone.xml then > yes, we can get that. > > But I'm a little confused as to how this would work. Are you saying that > you wouldn't use any of the classes in org.keycloak.models.jpa.entities? > Those need containers. > > > > On 21 October 2015 at 19:53, Stan Silvert wrote: > >> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >> >> Guys - all we need is the datasource. I want to create a "db tool" for >> Keycloak, this is not for the Admin CLI >> >> We don't need CDI, EJB, etc.. All we need is the datasource, or at least >> the connection information for the datasource + we also need JBoss modules >> so we can get the required classes. >> >> If offline mode can do this then that'd be good, but I seem to remember >> datasources weren't available? >> >> If you want to use our existing JPA infrastructure then you need a JPA >> container. That's where this other stuff all gets pulled in. >> >> Hey, let's just use JDBC! :-) >> >> >> On 21 October 2015 at 18:22, Marko Strukelj wrote: >> >>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >>> wrote: >>> >>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >>>> >>>>> I haven't taken a very close look at Swarm yet, but I assumed you >>>>> start Wildfly embedded in the same JVM as your Main class. If that is the >>>>> case, then there should be no problem communicating with any kind of >>>>> deployed component via heap directly - just lookup some singleton ... >>>>> >>>> Classloading constraints are what you usually run up against. You >>>> can't use your own version of a class that was loaded from a different >>>> classloader. I don't think Swarm helps you get around that, but just >>>> assumes you will access the WAR in the usual way through an HTTP port. But >>>> I could be wrong as I haven't worked with Swarm either. >>>> >>>> Here is an explanation of the problem based on an old version of JBoss: >>>> >>>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>>> >>>> With jboss-modules, it's easier to get around these problems, but you >>>> still run into the isolation built into the container itself, especially in >>>> the case of a WAR. >>> >>> >>> CLI running in the same JVM as Wildfly would get bootstrapped through >>> jboss-modules, and would package it's classes as a jboss module. It can >>> then deploy additional 'in-container' logic that needs actual access to >>> datasources via many different mechanisms. It can be a .jar containing a >>> SLSB, a .war, a .sar, a POJO (via pojo subsystem), it can be a custom >>> subsystem that gets installed ... In every of these cases it can then have >>> access to resource objects bound to java:jboss JNDI space ... And in every >>> of these cases it uses shared types loaded via dependencies on >>> jboss-modules. >>> >>> >>> >>>>> If that is not the case, then we would need some kind of interprocess >>>>> communication going. With shell the roles of who connects where could also >>>>> be reversed, and a started up Wildfly instance could have a service >>>>> connecting out to local port bound by our CLI rather than the other way >>>>> around. >>>>> >>>> I don't think the direction of the connection matters so much as the >>>> fact that you need a serialized format to issue commands to a foreign >>>> container. >>>> >>>> Or, as I mentioned, you need the CLI to actually live inside the >>>> container. >>> >>> >>> CLI needs to be able to execute its logic inside the container in order >>> to harness the datasources, but the UI part that takes care of getting the >>> inputs and displaying the outputs - e.g. CraSH, does not have to be inside >>> the container. >>> >>> I don't know what you mean by 'serialized format to issue commands to a >>> foreign container', but if it means taking care of UI interaction, CraSH >>> looks pretty decent CLI, easy to extend with custom commands. >>> >>> >> >> > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/fb89ce0a/attachment.html From ssilvert at redhat.com Wed Oct 21 15:08:40 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 21 Oct 2015 15:08:40 -0400 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> <5627D686.7030700@redhat.com> Message-ID: <5627E2B8.7060401@redhat.com> On 10/21/2015 2:43 PM, Stian Thorgersen wrote: > I have no idea what you mean about containers. As I said we manage our > own EntityManagerFactory, etc.. inside Keycloak. It doesn't rely on > JEE for that part. Somebody has to process the annotations in org.keycloak.models.jpa.entities, do injection, interception, etc. That's the job of the EE containers. > > We just need the classes which we can get with jboss-modules. > > On 21 October 2015 at 20:16, Stan Silvert > wrote: > > On 10/21/2015 2:08 PM, Stan Silvert wrote: >> On 10/21/2015 1:57 PM, Stian Thorgersen wrote: >>> We manage our own EntityManagerFactory and EntityManager as well >>> as our own transactions. So that's not true. >> If all you need is the datasource info that lives in >> standalone.xml then yes, we can get that. > But I'm a little confused as to how this would work. Are you > saying that you wouldn't use any of the classes in > org.keycloak.models.jpa.entities? Those need containers. >> >>> >>> On 21 October 2015 at 19:53, Stan Silvert >> > wrote: >>> >>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >>>> Guys - all we need is the datasource. I want to create a >>>> "db tool" for Keycloak, this is not for the Admin CLI >>>> >>>> We don't need CDI, EJB, etc.. All we need is the >>>> datasource, or at least the connection information for the >>>> datasource + we also need JBoss modules so we can get the >>>> required classes. >>>> >>>> If offline mode can do this then that'd be good, but I seem >>>> to remember datasources weren't available? >>> If you want to use our existing JPA infrastructure then you >>> need a JPA container. That's where this other stuff all >>> gets pulled in. >>> >>> Hey, let's just use JDBC! :-) >>> >>>> >>>> On 21 October 2015 at 18:22, Marko Strukelj >>>> > wrote: >>>> >>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >>>> > wrote: >>>> >>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >>>> >>>> I haven't taken a very close look at Swarm yet, >>>> but I assumed you start Wildfly embedded in the >>>> same JVM as your Main class. If that is the >>>> case, then there should be no problem >>>> communicating with any kind of deployed >>>> component via heap directly - just lookup some >>>> singleton ... >>>> >>>> Classloading constraints are what you usually run >>>> up against. You can't use your own version of a >>>> class that was loaded from a different classloader. >>>> I don't think Swarm helps you get around that, but >>>> just assumes you will access the WAR in the usual >>>> way through an HTTP port. But I could be wrong as >>>> I haven't worked with Swarm either. >>>> >>>> Here is an explanation of the problem based on an >>>> old version of JBoss: >>>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>>> >>>> With jboss-modules, it's easier to get around these >>>> problems, but you still run into the isolation >>>> built into the container itself, especially in the >>>> case of a WAR. >>>> >>>> CLI running in the same JVM as Wildfly would get >>>> bootstrapped through jboss-modules, and would package >>>> it's classes as a jboss module. It can then deploy >>>> additional 'in-container' logic that needs actual >>>> access to datasources via many different mechanisms. It >>>> can be a .jar containing a SLSB, a .war, a .sar, a POJO >>>> (via pojo subsystem), it can be a custom subsystem that >>>> gets installed ... In every of these cases it can then >>>> have access to resource objects bound to java:jboss >>>> JNDI space ... And in every of these cases it uses >>>> shared types loaded via dependencies on jboss-modules. >>>> >>>> >>>> >>>> If that is not the case, then we would need >>>> some kind of interprocess communication going. >>>> With shell the roles of who connects where >>>> could also be reversed, and a started up >>>> Wildfly instance could have a service >>>> connecting out to local port bound by our CLI >>>> rather than the other way around. >>>> >>>> I don't think the direction of the connection >>>> matters so much as the fact that you need a >>>> serialized format to issue commands to a foreign >>>> container. >>>> >>>> Or, as I mentioned, you need the CLI to actually >>>> live inside the container. >>>> >>>> >>>> CLI needs to be able to execute its logic inside the >>>> container in order to harness the datasources, but the >>>> UI part that takes care of getting the inputs and >>>> displaying the outputs - e.g. CraSH, does not have to >>>> be inside the container. >>>> >>>> I don't know what you mean by 'serialized format to >>>> issue commands to a foreign container', but if it means >>>> taking care of UI interaction, CraSH looks pretty >>>> decent CLI, easy to extend with custom commands. >>>> >>>> >>> >>> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/6c3fb64f/attachment-0001.html From sthorger at redhat.com Wed Oct 21 15:39:15 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 21 Oct 2015 21:39:15 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: <5627E2B8.7060401@redhat.com> References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> <5627D686.7030700@redhat.com> <5627E2B8.7060401@redhat.com> Message-ID: Nopes, that's not the job of EE containers, that's what Hibernate does. Hibernate does that perfectly well in standalone Java apps as well. As I said we manage our own EntityManagerFactory. Have you looked at KeycloakServer inside the testsuite? You can spin up a perfectly functional KC server with nothing but an embedded Undertow server. On 21 October 2015 at 21:08, Stan Silvert wrote: > On 10/21/2015 2:43 PM, Stian Thorgersen wrote: > > I have no idea what you mean about containers. As I said we manage our own > EntityManagerFactory, etc.. inside Keycloak. It doesn't rely on JEE for > that part. > > Somebody has to process the annotations in > org.keycloak.models.jpa.entities, do injection, interception, etc. That's > the job of the EE containers. > > > > We just need the classes which we can get with jboss-modules. > > On 21 October 2015 at 20:16, Stan Silvert wrote: > >> On 10/21/2015 2:08 PM, Stan Silvert wrote: >> >> On 10/21/2015 1:57 PM, Stian Thorgersen wrote: >> >> We manage our own EntityManagerFactory and EntityManager as well as our >> own transactions. So that's not true. >> >> If all you need is the datasource info that lives in standalone.xml then >> yes, we can get that. >> >> But I'm a little confused as to how this would work. Are you saying that >> you wouldn't use any of the classes in org.keycloak.models.jpa.entities? >> Those need containers. >> >> >> >> On 21 October 2015 at 19:53, Stan Silvert wrote: >> >>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >>> >>> Guys - all we need is the datasource. I want to create a "db tool" for >>> Keycloak, this is not for the Admin CLI >>> >>> We don't need CDI, EJB, etc.. All we need is the datasource, or at least >>> the connection information for the datasource + we also need JBoss modules >>> so we can get the required classes. >>> >>> If offline mode can do this then that'd be good, but I seem to remember >>> datasources weren't available? >>> >>> If you want to use our existing JPA infrastructure then you need a JPA >>> container. That's where this other stuff all gets pulled in. >>> >>> Hey, let's just use JDBC! :-) >>> >>> >>> On 21 October 2015 at 18:22, Marko Strukelj wrote: >>> >>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >>>> wrote: >>>> >>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >>>>> >>>>>> I haven't taken a very close look at Swarm yet, but I assumed you >>>>>> start Wildfly embedded in the same JVM as your Main class. If that is the >>>>>> case, then there should be no problem communicating with any kind of >>>>>> deployed component via heap directly - just lookup some singleton ... >>>>>> >>>>> Classloading constraints are what you usually run up against. You >>>>> can't use your own version of a class that was loaded from a different >>>>> classloader. I don't think Swarm helps you get around that, but just >>>>> assumes you will access the WAR in the usual way through an HTTP port. But >>>>> I could be wrong as I haven't worked with Swarm either. >>>>> >>>>> Here is an explanation of the problem based on an old version of JBoss: >>>>> >>>>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>>>> >>>>> With jboss-modules, it's easier to get around these problems, but you >>>>> still run into the isolation built into the container itself, especially in >>>>> the case of a WAR. >>>> >>>> >>>> CLI running in the same JVM as Wildfly would get bootstrapped through >>>> jboss-modules, and would package it's classes as a jboss module. It can >>>> then deploy additional 'in-container' logic that needs actual access to >>>> datasources via many different mechanisms. It can be a .jar containing a >>>> SLSB, a .war, a .sar, a POJO (via pojo subsystem), it can be a custom >>>> subsystem that gets installed ... In every of these cases it can then have >>>> access to resource objects bound to java:jboss JNDI space ... And in every >>>> of these cases it uses shared types loaded via dependencies on >>>> jboss-modules. >>>> >>>> >>>> >>>>>> If that is not the case, then we would need some kind of interprocess >>>>>> communication going. With shell the roles of who connects where could also >>>>>> be reversed, and a started up Wildfly instance could have a service >>>>>> connecting out to local port bound by our CLI rather than the other way >>>>>> around. >>>>>> >>>>> I don't think the direction of the connection matters so much as the >>>>> fact that you need a serialized format to issue commands to a foreign >>>>> container. >>>>> >>>>> Or, as I mentioned, you need the CLI to actually live inside the >>>>> container. >>>> >>>> >>>> CLI needs to be able to execute its logic inside the container in order >>>> to harness the datasources, but the UI part that takes care of getting the >>>> inputs and displaying the outputs - e.g. CraSH, does not have to be inside >>>> the container. >>>> >>>> I don't know what you mean by 'serialized format to issue commands to a >>>> foreign container', but if it means taking care of UI interaction, CraSH >>>> looks pretty decent CLI, easy to extend with custom commands. >>>> >>>> >>> >>> >> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/5f19c037/attachment.html From mstrukel at redhat.com Wed Oct 21 16:48:57 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 21 Oct 2015 22:48:57 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> <5627D686.7030700@redhat.com> <5627E2B8.7060401@redhat.com> Message-ID: @Stian, so your original question is then: Can we have a non jboss-cli CLI that will use hibernate directly, and configure it with datasource info from keycloak-server.json and standalone.xml? That would involve identifying Datasource jndi lookup name, finding datasource definition for it, identifying the driver used, and jboss-module containing the driver ... As long as Hibernate is capable of using connection url to autodetect dialect (AFAIK it can do that) it seems to me the answer is yes, that can be done ... On Oct 21, 2015 21:39, "Stian Thorgersen" wrote: > Nopes, that's not the job of EE containers, that's what Hibernate does. > Hibernate does that perfectly well in standalone Java apps as well. As I > said we manage our own EntityManagerFactory. > > Have you looked at KeycloakServer inside the testsuite? You can spin up a > perfectly functional KC server with nothing but an embedded Undertow server. > > On 21 October 2015 at 21:08, Stan Silvert wrote: > >> On 10/21/2015 2:43 PM, Stian Thorgersen wrote: >> >> I have no idea what you mean about containers. As I said we manage our >> own EntityManagerFactory, etc.. inside Keycloak. It doesn't rely on JEE for >> that part. >> >> Somebody has to process the annotations in >> org.keycloak.models.jpa.entities, do injection, interception, etc. That's >> the job of the EE containers. >> >> >> >> We just need the classes which we can get with jboss-modules. >> >> On 21 October 2015 at 20:16, Stan Silvert wrote: >> >>> On 10/21/2015 2:08 PM, Stan Silvert wrote: >>> >>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote: >>> >>> We manage our own EntityManagerFactory and EntityManager as well as our >>> own transactions. So that's not true. >>> >>> If all you need is the datasource info that lives in standalone.xml then >>> yes, we can get that. >>> >>> But I'm a little confused as to how this would work. Are you saying >>> that you wouldn't use any of the classes in >>> org.keycloak.models.jpa.entities? Those need containers. >>> >>> >>> >>> On 21 October 2015 at 19:53, Stan Silvert wrote: >>> >>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >>>> >>>> Guys - all we need is the datasource. I want to create a "db tool" for >>>> Keycloak, this is not for the Admin CLI >>>> >>>> We don't need CDI, EJB, etc.. All we need is the datasource, or at >>>> least the connection information for the datasource + we also need JBoss >>>> modules so we can get the required classes. >>>> >>>> If offline mode can do this then that'd be good, but I seem to remember >>>> datasources weren't available? >>>> >>>> If you want to use our existing JPA infrastructure then you need a JPA >>>> container. That's where this other stuff all gets pulled in. >>>> >>>> Hey, let's just use JDBC! :-) >>>> >>>> >>>> On 21 October 2015 at 18:22, Marko Strukelj >>>> wrote: >>>> >>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >>>>> wrote: >>>>> >>>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >>>>>> >>>>>>> I haven't taken a very close look at Swarm yet, but I assumed you >>>>>>> start Wildfly embedded in the same JVM as your Main class. If that is the >>>>>>> case, then there should be no problem communicating with any kind of >>>>>>> deployed component via heap directly - just lookup some singleton ... >>>>>>> >>>>>> Classloading constraints are what you usually run up against. You >>>>>> can't use your own version of a class that was loaded from a different >>>>>> classloader. I don't think Swarm helps you get around that, but just >>>>>> assumes you will access the WAR in the usual way through an HTTP port. But >>>>>> I could be wrong as I haven't worked with Swarm either. >>>>>> >>>>>> Here is an explanation of the problem based on an old version of >>>>>> JBoss: >>>>>> >>>>>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>>>>> >>>>>> With jboss-modules, it's easier to get around these problems, but you >>>>>> still run into the isolation built into the container itself, especially in >>>>>> the case of a WAR. >>>>> >>>>> >>>>> CLI running in the same JVM as Wildfly would get bootstrapped through >>>>> jboss-modules, and would package it's classes as a jboss module. It can >>>>> then deploy additional 'in-container' logic that needs actual access to >>>>> datasources via many different mechanisms. It can be a .jar containing a >>>>> SLSB, a .war, a .sar, a POJO (via pojo subsystem), it can be a custom >>>>> subsystem that gets installed ... In every of these cases it can then have >>>>> access to resource objects bound to java:jboss JNDI space ... And in every >>>>> of these cases it uses shared types loaded via dependencies on >>>>> jboss-modules. >>>>> >>>>> >>>>> >>>>>>> If that is not the case, then we would need some kind of >>>>>>> interprocess communication going. With shell the roles of who connects >>>>>>> where could also be reversed, and a started up Wildfly instance could have >>>>>>> a service connecting out to local port bound by our CLI rather than the >>>>>>> other way around. >>>>>>> >>>>>> I don't think the direction of the connection matters so much as the >>>>>> fact that you need a serialized format to issue commands to a foreign >>>>>> container. >>>>>> >>>>>> Or, as I mentioned, you need the CLI to actually live inside the >>>>>> container. >>>>> >>>>> >>>>> CLI needs to be able to execute its logic inside the container in >>>>> order to harness the datasources, but the UI part that takes care of >>>>> getting the inputs and displaying the outputs - e.g. CraSH, does not have >>>>> to be inside the container. >>>>> >>>>> I don't know what you mean by 'serialized format to issue commands to >>>>> a foreign container', but if it means taking care of UI interaction, CraSH >>>>> looks pretty decent CLI, easy to extend with custom commands. >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151021/381a7142/attachment-0001.html From sthorger at redhat.com Thu Oct 22 02:05:58 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Oct 2015 08:05:58 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> <5627D686.7030700@redhat.com> <5627E2B8.7060401@redhat.com> Message-ID: It can be JBoss CLI, that's no problem as long as it works, but if datasources are unavailable in offline mode then it's not going to help. Parsing the standalone.xml ourselves and extracting the datasource piece seems very brittle, that's why I was hoping there was some magic way we could get the datasource. Everything else should be easy enough. On 21 October 2015 at 22:48, Marko Strukelj wrote: > @Stian, so your original question is then: > > Can we have a non jboss-cli CLI that will use hibernate directly, and > configure it with datasource info from keycloak-server.json and > standalone.xml? > > That would involve identifying Datasource jndi lookup name, finding > datasource definition for it, identifying the driver used, and jboss-module > containing the driver ... > > As long as Hibernate is capable of using connection url to autodetect > dialect (AFAIK it can do that) it seems to me the answer is yes, that can > be done ... > On Oct 21, 2015 21:39, "Stian Thorgersen" wrote: > >> Nopes, that's not the job of EE containers, that's what Hibernate does. >> Hibernate does that perfectly well in standalone Java apps as well. As I >> said we manage our own EntityManagerFactory. >> >> Have you looked at KeycloakServer inside the testsuite? You can spin up a >> perfectly functional KC server with nothing but an embedded Undertow server. >> >> On 21 October 2015 at 21:08, Stan Silvert wrote: >> >>> On 10/21/2015 2:43 PM, Stian Thorgersen wrote: >>> >>> I have no idea what you mean about containers. As I said we manage our >>> own EntityManagerFactory, etc.. inside Keycloak. It doesn't rely on JEE for >>> that part. >>> >>> Somebody has to process the annotations in >>> org.keycloak.models.jpa.entities, do injection, interception, etc. That's >>> the job of the EE containers. >>> >>> >>> >>> We just need the classes which we can get with jboss-modules. >>> >>> On 21 October 2015 at 20:16, Stan Silvert wrote: >>> >>>> On 10/21/2015 2:08 PM, Stan Silvert wrote: >>>> >>>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote: >>>> >>>> We manage our own EntityManagerFactory and EntityManager as well as our >>>> own transactions. So that's not true. >>>> >>>> If all you need is the datasource info that lives in standalone.xml >>>> then yes, we can get that. >>>> >>>> But I'm a little confused as to how this would work. Are you saying >>>> that you wouldn't use any of the classes in >>>> org.keycloak.models.jpa.entities? Those need containers. >>>> >>>> >>>> >>>> On 21 October 2015 at 19:53, Stan Silvert wrote: >>>> >>>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >>>>> >>>>> Guys - all we need is the datasource. I want to create a "db tool" for >>>>> Keycloak, this is not for the Admin CLI >>>>> >>>>> We don't need CDI, EJB, etc.. All we need is the datasource, or at >>>>> least the connection information for the datasource + we also need JBoss >>>>> modules so we can get the required classes. >>>>> >>>>> If offline mode can do this then that'd be good, but I seem to >>>>> remember datasources weren't available? >>>>> >>>>> If you want to use our existing JPA infrastructure then you need a JPA >>>>> container. That's where this other stuff all gets pulled in. >>>>> >>>>> Hey, let's just use JDBC! :-) >>>>> >>>>> >>>>> On 21 October 2015 at 18:22, Marko Strukelj >>>>> wrote: >>>>> >>>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >>>>>> wrote: >>>>>> >>>>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >>>>>>> >>>>>>>> I haven't taken a very close look at Swarm yet, but I assumed you >>>>>>>> start Wildfly embedded in the same JVM as your Main class. If that is the >>>>>>>> case, then there should be no problem communicating with any kind of >>>>>>>> deployed component via heap directly - just lookup some singleton ... >>>>>>>> >>>>>>> Classloading constraints are what you usually run up against. You >>>>>>> can't use your own version of a class that was loaded from a different >>>>>>> classloader. I don't think Swarm helps you get around that, but just >>>>>>> assumes you will access the WAR in the usual way through an HTTP port. But >>>>>>> I could be wrong as I haven't worked with Swarm either. >>>>>>> >>>>>>> Here is an explanation of the problem based on an old version of >>>>>>> JBoss: >>>>>>> >>>>>>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>>>>>> >>>>>>> With jboss-modules, it's easier to get around these problems, but >>>>>>> you still run into the isolation built into the container itself, >>>>>>> especially in the case of a WAR. >>>>>> >>>>>> >>>>>> CLI running in the same JVM as Wildfly would get bootstrapped through >>>>>> jboss-modules, and would package it's classes as a jboss module. It can >>>>>> then deploy additional 'in-container' logic that needs actual access to >>>>>> datasources via many different mechanisms. It can be a .jar containing a >>>>>> SLSB, a .war, a .sar, a POJO (via pojo subsystem), it can be a custom >>>>>> subsystem that gets installed ... In every of these cases it can then have >>>>>> access to resource objects bound to java:jboss JNDI space ... And in every >>>>>> of these cases it uses shared types loaded via dependencies on >>>>>> jboss-modules. >>>>>> >>>>>> >>>>>> >>>>>>>> If that is not the case, then we would need some kind of >>>>>>>> interprocess communication going. With shell the roles of who connects >>>>>>>> where could also be reversed, and a started up Wildfly instance could have >>>>>>>> a service connecting out to local port bound by our CLI rather than the >>>>>>>> other way around. >>>>>>>> >>>>>>> I don't think the direction of the connection matters so much as the >>>>>>> fact that you need a serialized format to issue commands to a foreign >>>>>>> container. >>>>>>> >>>>>>> Or, as I mentioned, you need the CLI to actually live inside the >>>>>>> container. >>>>>> >>>>>> >>>>>> CLI needs to be able to execute its logic inside the container in >>>>>> order to harness the datasources, but the UI part that takes care of >>>>>> getting the inputs and displaying the outputs - e.g. CraSH, does not have >>>>>> to be inside the container. >>>>>> >>>>>> I don't know what you mean by 'serialized format to issue commands to >>>>>> a foreign container', but if it means taking care of UI interaction, CraSH >>>>>> looks pretty decent CLI, easy to extend with custom commands. >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >>> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/a1a5cd2e/attachment-0001.html From sthorger at redhat.com Thu Oct 22 02:42:07 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Oct 2015 08:42:07 +0200 Subject: [keycloak-dev] Ability to set hostname for server Message-ID: Currently we have a few people having issues with the fact that we use the URL of the request as the hostname for Keycloak. For example to get the address sent in emails or as the iss value in tokens. This works fine as long as everyone accesses it using the proper domain name. However, it doesn't work when servers are on the same local network use the direct IP address or internal hostname. The simplest solution to this would be to add an option to set the hostname for the server. This would be configured in keycloak-server.json, but we'd also support setting it with a system property. Default would be to use the request-url as we do now, but once specified we would not use the request-url anymore and always use the configured hostname as the base URL. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/6ba1ad8d/attachment.html From thomas.raehalme at aitiofinland.com Thu Oct 22 03:02:05 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Thu, 22 Oct 2015 10:02:05 +0300 Subject: [keycloak-dev] Ability to set hostname for server In-Reply-To: References: Message-ID: On Thu, Oct 22, 2015 at 9:42 AM, Stian Thorgersen wrote: > The simplest solution to this would be to add an option to set the > hostname for the server. This would be configured in keycloak-server.json, > but we'd also support setting it with a system property. Default would be > to use the request-url as we do now, but once specified we would not use > the request-url anymore and always use the configured hostname as the base > URL. > > How about making it an option in the realm configuration? It would allow you to brand the realm just like with themes. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/d55332d8/attachment.html From sthorger at redhat.com Thu Oct 22 03:05:42 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Oct 2015 09:05:42 +0200 Subject: [keycloak-dev] Ability to set hostname for server In-Reply-To: References: Message-ID: That could be an addition. We'd need a global hostname configured outside of the realm, but being able to override on a realm level could be good. On 22 October 2015 at 09:02, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > > On Thu, Oct 22, 2015 at 9:42 AM, Stian Thorgersen > wrote: > >> The simplest solution to this would be to add an option to set the >> hostname for the server. This would be configured in keycloak-server.json, >> but we'd also support setting it with a system property. Default would be >> to use the request-url as we do now, but once specified we would not use >> the request-url anymore and always use the configured hostname as the base >> URL. >> >> > How about making it an option in the realm configuration? It would allow > you to brand the realm just like with themes. > > Best regards, > Thomas > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/84afdec4/attachment.html From mposolda at redhat.com Thu Oct 22 07:14:50 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 22 Oct 2015 13:14:50 +0200 Subject: [keycloak-dev] Ability to set hostname for server In-Reply-To: References: Message-ID: <5628C52A.2030703@redhat.com> +1 But not sure if hostname is sufficient. Shouldn't it rather be whole origin including protocol and port? Marek On 22/10/15 08:42, Stian Thorgersen wrote: > Currently we have a few people having issues with the fact that we use > the URL of the request as the hostname for Keycloak. For example to > get the address sent in emails or as the iss value in tokens. This > works fine as long as everyone accesses it using the proper domain > name. However, it doesn't work when servers are on the same local > network use the direct IP address or internal hostname. > > The simplest solution to this would be to add an option to set the > hostname for the server. This would be configured in > keycloak-server.json, but we'd also support setting it with a system > property. Default would be to use the request-url as we do now, but > once specified we would not use the request-url anymore and always use > the configured hostname as the base URL. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/01eceee9/attachment.html From sebastian.rose at aoe.com Thu Oct 22 07:50:27 2015 From: sebastian.rose at aoe.com (Sebastian Rose) Date: Thu, 22 Oct 2015 11:50:27 +0000 Subject: [keycloak-dev] Ability to set hostname for server In-Reply-To: <5628C52A.2030703@redhat.com> References: , <5628C52A.2030703@redhat.com> Message-ID: <1445514628685.2749@aoe.com> +1 (for full origin) Regards, Sebastian ________________________________ Von: keycloak-dev-bounces at lists.jboss.org im Auftrag von Marek Posolda Gesendet: Donnerstag, 22. Oktober 2015 13:14 An: stian at redhat.com; keycloak-dev Betreff: Re: [keycloak-dev] Ability to set hostname for server +1 But not sure if hostname is sufficient. Shouldn't it rather be whole origin including protocol and port? Marek On 22/10/15 08:42, Stian Thorgersen wrote: Currently we have a few people having issues with the fact that we use the URL of the request as the hostname for Keycloak. For example to get the address sent in emails or as the iss value in tokens. This works fine as long as everyone accesses it using the proper domain name. However, it doesn't work when servers are on the same local network use the direct IP address or internal hostname. The simplest solution to this would be to add an option to set the hostname for the server. This would be configured in keycloak-server.json, but we'd also support setting it with a system property. Default would be to use the request-url as we do now, but once specified we would not use the request-url anymore and always use the configured hostname as the base URL. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/ae908554/attachment.html From ssilvert at redhat.com Thu Oct 22 08:55:44 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 22 Oct 2015 08:55:44 -0400 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> <5627D686.7030700@redhat.com> <5627E2B8.7060401@redhat.com> Message-ID: <5628DCD0.6060800@redhat.com> On 10/21/2015 3:39 PM, Stian Thorgersen wrote: > Nopes, that's not the job of EE containers, that's what Hibernate > does. Hibernate does that perfectly well in standalone Java apps as > well. As I said we manage our own EntityManagerFactory. You're right. I've been working strictly with the app server too many years. It's still a JEE container. JPA is part of the JEE spec. In this case you are just getting it directly from Hibernate. > > Have you looked at KeycloakServer inside the testsuite? You can spin > up a perfectly functional KC server with nothing but an embedded > Undertow server. > > On 21 October 2015 at 21:08, Stan Silvert > wrote: > > On 10/21/2015 2:43 PM, Stian Thorgersen wrote: >> I have no idea what you mean about containers. As I said we >> manage our own EntityManagerFactory, etc.. inside Keycloak. It >> doesn't rely on JEE for that part. > Somebody has to process the annotations in > org.keycloak.models.jpa.entities, do injection, interception, > etc. That's the job of the EE containers. > > >> >> We just need the classes which we can get with jboss-modules. >> >> On 21 October 2015 at 20:16, Stan Silvert > > wrote: >> >> On 10/21/2015 2:08 PM, Stan Silvert wrote: >>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote: >>>> We manage our own EntityManagerFactory and EntityManager as >>>> well as our own transactions. So that's not true. >>> If all you need is the datasource info that lives in >>> standalone.xml then yes, we can get that. >> But I'm a little confused as to how this would work. Are you >> saying that you wouldn't use any of the classes in >> org.keycloak.models.jpa.entities? Those need containers. >>> >>>> >>>> On 21 October 2015 at 19:53, Stan Silvert >>>> > wrote: >>>> >>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >>>>> Guys - all we need is the datasource. I want to create >>>>> a "db tool" for Keycloak, this is not for the Admin CLI >>>>> >>>>> We don't need CDI, EJB, etc.. All we need is the >>>>> datasource, or at least the connection information for >>>>> the datasource + we also need JBoss modules so we can >>>>> get the required classes. >>>>> >>>>> If offline mode can do this then that'd be good, but I >>>>> seem to remember datasources weren't available? >>>> If you want to use our existing JPA infrastructure then >>>> you need a JPA container. That's where this other >>>> stuff all gets pulled in. >>>> >>>> Hey, let's just use JDBC! :-) >>>> >>>>> >>>>> On 21 October 2015 at 18:22, Marko Strukelj >>>>> > wrote: >>>>> >>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >>>>> > >>>>> wrote: >>>>> >>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >>>>> >>>>> I haven't taken a very close look at Swarm >>>>> yet, but I assumed you start Wildfly >>>>> embedded in the same JVM as your Main >>>>> class. If that is the case, then there >>>>> should be no problem communicating with >>>>> any kind of deployed component via heap >>>>> directly - just lookup some singleton ... >>>>> >>>>> Classloading constraints are what you usually >>>>> run up against. You can't use your own >>>>> version of a class that was loaded from a >>>>> different classloader. I don't think Swarm >>>>> helps you get around that, but just assumes >>>>> you will access the WAR in the usual way >>>>> through an HTTP port. But I could be wrong as >>>>> I haven't worked with Swarm either. >>>>> >>>>> Here is an explanation of the problem based on >>>>> an old version of JBoss: >>>>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>>>> >>>>> With jboss-modules, it's easier to get around >>>>> these problems, but you still run into the >>>>> isolation built into the container itself, >>>>> especially in the case of a WAR. >>>>> >>>>> CLI running in the same JVM as Wildfly would get >>>>> bootstrapped through jboss-modules, and would >>>>> package it's classes as a jboss module. It can >>>>> then deploy additional 'in-container' logic that >>>>> needs actual access to datasources via many >>>>> different mechanisms. It can be a .jar containing >>>>> a SLSB, a .war, a .sar, a POJO (via pojo >>>>> subsystem), it can be a custom subsystem that gets >>>>> installed ... In every of these cases it can then >>>>> have access to resource objects bound to >>>>> java:jboss JNDI space ... And in every of these >>>>> cases it uses shared types loaded via dependencies >>>>> on jboss-modules. >>>>> >>>>> >>>>> >>>>> If that is not the case, then we would >>>>> need some kind of interprocess >>>>> communication going. With shell the roles >>>>> of who connects where could also be >>>>> reversed, and a started up Wildfly >>>>> instance could have a service connecting >>>>> out to local port bound by our CLI rather >>>>> than the other way around. >>>>> >>>>> I don't think the direction of the connection >>>>> matters so much as the fact that you need a >>>>> serialized format to issue commands to a >>>>> foreign container. >>>>> >>>>> Or, as I mentioned, you need the CLI to >>>>> actually live inside the container. >>>>> >>>>> >>>>> CLI needs to be able to execute its logic inside >>>>> the container in order to harness the datasources, >>>>> but the UI part that takes care of getting the >>>>> inputs and displaying the outputs - e.g. CraSH, >>>>> does not have to be inside the container. >>>>> >>>>> I don't know what you mean by 'serialized format >>>>> to issue commands to a foreign container', but if >>>>> it means taking care of UI interaction, CraSH >>>>> looks pretty decent CLI, easy to extend with >>>>> custom commands. >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/8bda447b/attachment-0001.html From ssilvert at redhat.com Thu Oct 22 09:03:10 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 22 Oct 2015 09:03:10 -0400 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> <5627D686.7030700@redhat.com> <5627E2B8.7060401@redhat.com> Message-ID: <5628DE8E.9040309@redhat.com> On 10/22/2015 2:05 AM, Stian Thorgersen wrote: > It can be JBoss CLI, that's no problem as long as it works, but if > datasources are unavailable in offline mode then it's not going to help. > > Parsing the standalone.xml ourselves and extracting the datasource > piece seems very brittle, that's why I was hoping there was some magic > way we could get the datasource. Everything else should be easy enough. So if it's WildFly CLI then there is obviously no problem reading standalone.xml in a standard way. The custom commands we create for WildFly CLI can do anything we want. So by pulling in Hibernate and using its JPA implementation directly, we could do it. > > On 21 October 2015 at 22:48, Marko Strukelj > wrote: > > @Stian, so your original question is then: > > Can we have a non jboss-cli CLI that will use hibernate directly, > and configure it with datasource info from keycloak-server.json > and standalone.xml? > > That would involve identifying Datasource jndi lookup name, > finding datasource definition for it, identifying the driver used, > and jboss-module containing the driver ... > > As long as Hibernate is capable of using connection url to > autodetect dialect (AFAIK it can do that) it seems to me the > answer is yes, that can be done ... > > On Oct 21, 2015 21:39, "Stian Thorgersen" > wrote: > > Nopes, that's not the job of EE containers, that's what > Hibernate does. Hibernate does that perfectly well in > standalone Java apps as well. As I said we manage our own > EntityManagerFactory. > > Have you looked at KeycloakServer inside the testsuite? You > can spin up a perfectly functional KC server with nothing but > an embedded Undertow server. > > On 21 October 2015 at 21:08, Stan Silvert > wrote: > > On 10/21/2015 2:43 PM, Stian Thorgersen wrote: >> I have no idea what you mean about containers. As I said >> we manage our own EntityManagerFactory, etc.. inside >> Keycloak. It doesn't rely on JEE for that part. > Somebody has to process the annotations in > org.keycloak.models.jpa.entities, do injection, > interception, etc. That's the job of the EE containers. > > >> >> We just need the classes which we can get with jboss-modules. >> >> On 21 October 2015 at 20:16, Stan Silvert >> > wrote: >> >> On 10/21/2015 2:08 PM, Stan Silvert wrote: >>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote: >>>> We manage our own EntityManagerFactory and >>>> EntityManager as well as our own transactions. So >>>> that's not true. >>> If all you need is the datasource info that lives in >>> standalone.xml then yes, we can get that. >> But I'm a little confused as to how this would work. >> Are you saying that you wouldn't use any of the >> classes in org.keycloak.models.jpa.entities? Those >> need containers. >>> >>>> >>>> On 21 October 2015 at 19:53, Stan Silvert >>>> > >>>> wrote: >>>> >>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >>>>> Guys - all we need is the datasource. I want >>>>> to create a "db tool" for Keycloak, this is >>>>> not for the Admin CLI >>>>> >>>>> We don't need CDI, EJB, etc.. All we need is >>>>> the datasource, or at least the connection >>>>> information for the datasource + we also need >>>>> JBoss modules so we can get the required classes. >>>>> >>>>> If offline mode can do this then that'd be >>>>> good, but I seem to remember datasources >>>>> weren't available? >>>> If you want to use our existing JPA >>>> infrastructure then you need a JPA container. >>>> That's where this other stuff all gets pulled in. >>>> >>>> Hey, let's just use JDBC! :-) >>>> >>>>> >>>>> On 21 October 2015 at 18:22, Marko Strukelj >>>>> >>>> > wrote: >>>>> >>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan >>>>> Silvert >>>> > wrote: >>>>> >>>>> On 10/21/2015 11:14 AM, Marko Strukelj >>>>> wrote: >>>>> >>>>> I haven't taken a very close look >>>>> at Swarm yet, but I assumed you >>>>> start Wildfly embedded in the same >>>>> JVM as your Main class. If that is >>>>> the case, then there should be no >>>>> problem communicating with any >>>>> kind of deployed component via >>>>> heap directly - just lookup some >>>>> singleton ... >>>>> >>>>> Classloading constraints are what you >>>>> usually run up against. You can't use >>>>> your own version of a class that was >>>>> loaded from a different classloader. I >>>>> don't think Swarm helps you get around >>>>> that, but just assumes you will access >>>>> the WAR in the usual way through an >>>>> HTTP port. But I could be wrong as I >>>>> haven't worked with Swarm either. >>>>> >>>>> Here is an explanation of the problem >>>>> based on an old version of JBoss: >>>>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>>>> >>>>> With jboss-modules, it's easier to get >>>>> around these problems, but you still >>>>> run into the isolation built into the >>>>> container itself, especially in the >>>>> case of a WAR. >>>>> >>>>> CLI running in the same JVM as Wildfly >>>>> would get bootstrapped through >>>>> jboss-modules, and would package it's >>>>> classes as a jboss module. It can then >>>>> deploy additional 'in-container' logic >>>>> that needs actual access to datasources >>>>> via many different mechanisms. It can be a >>>>> .jar containing a SLSB, a .war, a .sar, a >>>>> POJO (via pojo subsystem), it can be a >>>>> custom subsystem that gets installed ... >>>>> In every of these cases it can then have >>>>> access to resource objects bound to >>>>> java:jboss JNDI space ... And in every of >>>>> these cases it uses shared types loaded >>>>> via dependencies on jboss-modules. >>>>> >>>>> >>>>> >>>>> If that is not the case, then we >>>>> would need some kind of >>>>> interprocess communication going. >>>>> With shell the roles of who >>>>> connects where could also be >>>>> reversed, and a started up Wildfly >>>>> instance could have a service >>>>> connecting out to local port bound >>>>> by our CLI rather than the other >>>>> way around. >>>>> >>>>> I don't think the direction of the >>>>> connection matters so much as the fact >>>>> that you need a serialized format to >>>>> issue commands to a foreign container. >>>>> >>>>> Or, as I mentioned, you need the CLI >>>>> to actually live inside the container. >>>>> >>>>> >>>>> CLI needs to be able to execute its logic >>>>> inside the container in order to harness >>>>> the datasources, but the UI part that >>>>> takes care of getting the inputs and >>>>> displaying the outputs - e.g. CraSH, does >>>>> not have to be inside the container. >>>>> >>>>> I don't know what you mean by 'serialized >>>>> format to issue commands to a foreign >>>>> container', but if it means taking care of >>>>> UI interaction, CraSH looks pretty decent >>>>> CLI, easy to extend with custom commands. >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/744ddb7d/attachment-0001.html From sthorger at redhat.com Thu Oct 22 09:11:39 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Oct 2015 15:11:39 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: <5628DE8E.9040309@redhat.com> References: <56279BC2.50005@redhat.com> <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> <5627D686.7030700@redhat.com> <5627E2B8.7060401@redhat.com> <5628DE8E.9040309@redhat.com> Message-ID: If we have to extract connection information from datasources in either case we don't really get much benefit of using offline jboss cli though? On 22 October 2015 at 15:03, Stan Silvert wrote: > On 10/22/2015 2:05 AM, Stian Thorgersen wrote: > > It can be JBoss CLI, that's no problem as long as it works, but if > datasources are unavailable in offline mode then it's not going to help. > > Parsing the standalone.xml ourselves and extracting the datasource piece > seems very brittle, that's why I was hoping there was some magic way we > could get the datasource. Everything else should be easy enough. > > So if it's WildFly CLI then there is obviously no problem reading > standalone.xml in a standard way. > > The custom commands we create for WildFly CLI can do anything we want. So > by pulling in Hibernate and using its JPA implementation directly, we could > do it. > > > On 21 October 2015 at 22:48, Marko Strukelj wrote: > >> @Stian, so your original question is then: >> >> Can we have a non jboss-cli CLI that will use hibernate directly, and >> configure it with datasource info from keycloak-server.json and >> standalone.xml? >> >> That would involve identifying Datasource jndi lookup name, finding >> datasource definition for it, identifying the driver used, and jboss-module >> containing the driver ... >> >> As long as Hibernate is capable of using connection url to autodetect >> dialect (AFAIK it can do that) it seems to me the answer is yes, that can >> be done ... >> On Oct 21, 2015 21:39, "Stian Thorgersen" wrote: >> >>> Nopes, that's not the job of EE containers, that's what Hibernate does. >>> Hibernate does that perfectly well in standalone Java apps as well. As I >>> said we manage our own EntityManagerFactory. >>> >>> Have you looked at KeycloakServer inside the testsuite? You can spin up >>> a perfectly functional KC server with nothing but an embedded Undertow >>> server. >>> >>> On 21 October 2015 at 21:08, Stan Silvert wrote: >>> >>>> On 10/21/2015 2:43 PM, Stian Thorgersen wrote: >>>> >>>> I have no idea what you mean about containers. As I said we manage our >>>> own EntityManagerFactory, etc.. inside Keycloak. It doesn't rely on JEE for >>>> that part. >>>> >>>> Somebody has to process the annotations in >>>> org.keycloak.models.jpa.entities, do injection, interception, etc. That's >>>> the job of the EE containers. >>>> >>>> >>>> >>>> We just need the classes which we can get with jboss-modules. >>>> >>>> On 21 October 2015 at 20:16, Stan Silvert wrote: >>>> >>>>> On 10/21/2015 2:08 PM, Stan Silvert wrote: >>>>> >>>>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote: >>>>> >>>>> We manage our own EntityManagerFactory and EntityManager as well as >>>>> our own transactions. So that's not true. >>>>> >>>>> If all you need is the datasource info that lives in standalone.xml >>>>> then yes, we can get that. >>>>> >>>>> But I'm a little confused as to how this would work. Are you saying >>>>> that you wouldn't use any of the classes in >>>>> org.keycloak.models.jpa.entities? Those need containers. >>>>> >>>>> >>>>> >>>>> On 21 October 2015 at 19:53, Stan Silvert wrote: >>>>> >>>>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >>>>>> >>>>>> Guys - all we need is the datasource. I want to create a "db tool" >>>>>> for Keycloak, this is not for the Admin CLI >>>>>> >>>>>> We don't need CDI, EJB, etc.. All we need is the datasource, or at >>>>>> least the connection information for the datasource + we also need JBoss >>>>>> modules so we can get the required classes. >>>>>> >>>>>> If offline mode can do this then that'd be good, but I seem to >>>>>> remember datasources weren't available? >>>>>> >>>>>> If you want to use our existing JPA infrastructure then you need a >>>>>> JPA container. That's where this other stuff all gets pulled in. >>>>>> >>>>>> Hey, let's just use JDBC! :-) >>>>>> >>>>>> >>>>>> On 21 October 2015 at 18:22, Marko Strukelj >>>>>> wrote: >>>>>> >>>>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >>>>>>> wrote: >>>>>>> >>>>>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >>>>>>>> >>>>>>>>> I haven't taken a very close look at Swarm yet, but I assumed you >>>>>>>>> start Wildfly embedded in the same JVM as your Main class. If that is the >>>>>>>>> case, then there should be no problem communicating with any kind of >>>>>>>>> deployed component via heap directly - just lookup some singleton ... >>>>>>>>> >>>>>>>> Classloading constraints are what you usually run up against. You >>>>>>>> can't use your own version of a class that was loaded from a different >>>>>>>> classloader. I don't think Swarm helps you get around that, but just >>>>>>>> assumes you will access the WAR in the usual way through an HTTP port. But >>>>>>>> I could be wrong as I haven't worked with Swarm either. >>>>>>>> >>>>>>>> Here is an explanation of the problem based on an old version of >>>>>>>> JBoss: >>>>>>>> >>>>>>>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>>>>>>> >>>>>>>> With jboss-modules, it's easier to get around these problems, but >>>>>>>> you still run into the isolation built into the container itself, >>>>>>>> especially in the case of a WAR. >>>>>>> >>>>>>> >>>>>>> CLI running in the same JVM as Wildfly would get bootstrapped >>>>>>> through jboss-modules, and would package it's classes as a jboss module. It >>>>>>> can then deploy additional 'in-container' logic that needs actual access to >>>>>>> datasources via many different mechanisms. It can be a .jar containing a >>>>>>> SLSB, a .war, a .sar, a POJO (via pojo subsystem), it can be a custom >>>>>>> subsystem that gets installed ... In every of these cases it can then have >>>>>>> access to resource objects bound to java:jboss JNDI space ... And in every >>>>>>> of these cases it uses shared types loaded via dependencies on >>>>>>> jboss-modules. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> If that is not the case, then we would need some kind of >>>>>>>>> interprocess communication going. With shell the roles of who connects >>>>>>>>> where could also be reversed, and a started up Wildfly instance could have >>>>>>>>> a service connecting out to local port bound by our CLI rather than the >>>>>>>>> other way around. >>>>>>>>> >>>>>>>> I don't think the direction of the connection matters so much as >>>>>>>> the fact that you need a serialized format to issue commands to a foreign >>>>>>>> container. >>>>>>>> >>>>>>>> Or, as I mentioned, you need the CLI to actually live inside the >>>>>>>> container. >>>>>>> >>>>>>> >>>>>>> CLI needs to be able to execute its logic inside the container in >>>>>>> order to harness the datasources, but the UI part that takes care of >>>>>>> getting the inputs and displaying the outputs - e.g. CraSH, does not have >>>>>>> to be inside the container. >>>>>>> >>>>>>> I don't know what you mean by 'serialized format to issue commands >>>>>>> to a foreign container', but if it means taking care of UI interaction, >>>>>>> CraSH looks pretty decent CLI, easy to extend with custom commands. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/354125f6/attachment-0001.html From ssilvert at redhat.com Thu Oct 22 09:31:46 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 22 Oct 2015 09:31:46 -0400 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: References: <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> <5627D686.7030700@redhat.com> <5627E2B8.7060401@redhat.com> <5628DE8E.9040309@redhat.com> Message-ID: <5628E542.2030701@redhat.com> On 10/22/2015 9:11 AM, Stian Thorgersen wrote: > If we have to extract connection information from datasources in > either case we don't really get much benefit of using offline jboss > cli though? You are reading standalone.xml in a standard way, which is better than parsing it ourselves. Beyond that, I'd have to try it out to see what other benefits there would be. It could be that it is indeed very easy to get the datasource itself. Now that my brain is fixed concerning using Hibernate directly, I'm thinking this might be possible. Of course, there are lots of benefits beyond the offline CLI use case, which I've talked about at great length. > > On 22 October 2015 at 15:03, Stan Silvert > wrote: > > On 10/22/2015 2:05 AM, Stian Thorgersen wrote: >> It can be JBoss CLI, that's no problem as long as it works, but >> if datasources are unavailable in offline mode then it's not >> going to help. >> >> Parsing the standalone.xml ourselves and extracting the >> datasource piece seems very brittle, that's why I was hoping >> there was some magic way we could get the datasource. Everything >> else should be easy enough. > So if it's WildFly CLI then there is obviously no problem reading > standalone.xml in a standard way. > > The custom commands we create for WildFly CLI can do anything we > want. So by pulling in Hibernate and using its JPA implementation > directly, we could do it. > >> >> On 21 October 2015 at 22:48, Marko Strukelj > > wrote: >> >> @Stian, so your original question is then: >> >> Can we have a non jboss-cli CLI that will use hibernate >> directly, and configure it with datasource info from >> keycloak-server.json and standalone.xml? >> >> That would involve identifying Datasource jndi lookup name, >> finding datasource definition for it, identifying the driver >> used, and jboss-module containing the driver ... >> >> As long as Hibernate is capable of using connection url to >> autodetect dialect (AFAIK it can do that) it seems to me the >> answer is yes, that can be done ... >> >> On Oct 21, 2015 21:39, "Stian Thorgersen" >> > wrote: >> >> Nopes, that's not the job of EE containers, that's what >> Hibernate does. Hibernate does that perfectly well in >> standalone Java apps as well. As I said we manage our own >> EntityManagerFactory. >> >> Have you looked at KeycloakServer inside the testsuite? >> You can spin up a perfectly functional KC server with >> nothing but an embedded Undertow server. >> >> On 21 October 2015 at 21:08, Stan Silvert >> > wrote: >> >> On 10/21/2015 2:43 PM, Stian Thorgersen wrote: >>> I have no idea what you mean about containers. As I >>> said we manage our own EntityManagerFactory, etc.. >>> inside Keycloak. It doesn't rely on JEE for that part. >> Somebody has to process the annotations in >> org.keycloak.models.jpa.entities, do injection, >> interception, etc. That's the job of the EE containers. >> >> >>> >>> We just need the classes which we can get with >>> jboss-modules. >>> >>> On 21 October 2015 at 20:16, Stan Silvert >>> > >>> wrote: >>> >>> On 10/21/2015 2:08 PM, Stan Silvert wrote: >>>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote: >>>>> We manage our own EntityManagerFactory and >>>>> EntityManager as well as our own transactions. >>>>> So that's not true. >>>> If all you need is the datasource info that >>>> lives in standalone.xml then yes, we can get that. >>> But I'm a little confused as to how this would >>> work. Are you saying that you wouldn't use any >>> of the classes in >>> org.keycloak.models.jpa.entities? Those need >>> containers. >>>> >>>>> >>>>> On 21 October 2015 at 19:53, Stan Silvert >>>>> >>>> > wrote: >>>>> >>>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >>>>>> Guys - all we need is the datasource. I >>>>>> want to create a "db tool" for Keycloak, >>>>>> this is not for the Admin CLI >>>>>> >>>>>> We don't need CDI, EJB, etc.. All we need >>>>>> is the datasource, or at least the >>>>>> connection information for the datasource >>>>>> + we also need JBoss modules so we can >>>>>> get the required classes. >>>>>> >>>>>> If offline mode can do this then that'd >>>>>> be good, but I seem to remember >>>>>> datasources weren't available? >>>>> If you want to use our existing JPA >>>>> infrastructure then you need a JPA >>>>> container. That's where this other stuff >>>>> all gets pulled in. >>>>> >>>>> Hey, let's just use JDBC! :-) >>>>> >>>>>> >>>>>> On 21 October 2015 at 18:22, Marko >>>>>> Strukelj >>>>> > wrote: >>>>>> >>>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan >>>>>> Silvert >>>>> > wrote: >>>>>> >>>>>> On 10/21/2015 11:14 AM, Marko >>>>>> Strukelj wrote: >>>>>> >>>>>> I haven't taken a very close >>>>>> look at Swarm yet, but I >>>>>> assumed you start Wildfly >>>>>> embedded in the same JVM as >>>>>> your Main class. If that is >>>>>> the case, then there should >>>>>> be no problem communicating >>>>>> with any kind of deployed >>>>>> component via heap directly - >>>>>> just lookup some singleton ... >>>>>> >>>>>> Classloading constraints are what >>>>>> you usually run up against. You >>>>>> can't use your own version of a >>>>>> class that was loaded from a >>>>>> different classloader. I don't >>>>>> think Swarm helps you get around >>>>>> that, but just assumes you will >>>>>> access the WAR in the usual way >>>>>> through an HTTP port. But I could >>>>>> be wrong as I haven't worked with >>>>>> Swarm either. >>>>>> >>>>>> Here is an explanation of the >>>>>> problem based on an old version >>>>>> of JBoss: >>>>>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>>>>> >>>>>> With jboss-modules, it's easier >>>>>> to get around these problems, but >>>>>> you still run into the isolation >>>>>> built into the container itself, >>>>>> especially in the case of a WAR. >>>>>> >>>>>> CLI running in the same JVM as >>>>>> Wildfly would get bootstrapped >>>>>> through jboss-modules, and would >>>>>> package it's classes as a jboss >>>>>> module. It can then deploy additional >>>>>> 'in-container' logic that needs >>>>>> actual access to datasources via many >>>>>> different mechanisms. It can be a >>>>>> .jar containing a SLSB, a .war, a >>>>>> .sar, a POJO (via pojo subsystem), it >>>>>> can be a custom subsystem that gets >>>>>> installed ... In every of these cases >>>>>> it can then have access to resource >>>>>> objects bound to java:jboss JNDI >>>>>> space ... And in every of these cases >>>>>> it uses shared types loaded via >>>>>> dependencies on jboss-modules. >>>>>> >>>>>> >>>>>> >>>>>> If that is not the case, then >>>>>> we would need some kind of >>>>>> interprocess communication >>>>>> going. With shell the roles >>>>>> of who connects where could >>>>>> also be reversed, and a >>>>>> started up Wildfly instance >>>>>> could have a service >>>>>> connecting out to local port >>>>>> bound by our CLI rather than >>>>>> the other way around. >>>>>> >>>>>> I don't think the direction of >>>>>> the connection matters so much as >>>>>> the fact that you need a >>>>>> serialized format to issue >>>>>> commands to a foreign container. >>>>>> >>>>>> Or, as I mentioned, you need the >>>>>> CLI to actually live inside the >>>>>> container. >>>>>> >>>>>> >>>>>> CLI needs to be able to execute its >>>>>> logic inside the container in order >>>>>> to harness the datasources, but the >>>>>> UI part that takes care of getting >>>>>> the inputs and displaying the outputs >>>>>> - e.g. CraSH, does not have to be >>>>>> inside the container. >>>>>> >>>>>> I don't know what you mean by >>>>>> 'serialized format to issue commands >>>>>> to a foreign container', but if it >>>>>> means taking care of UI interaction, >>>>>> CraSH looks pretty decent CLI, easy >>>>>> to extend with custom commands. >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/adde5f4d/attachment-0001.html From sthorger at redhat.com Thu Oct 22 13:28:09 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Oct 2015 19:28:09 +0200 Subject: [keycloak-dev] Ability to set hostname for server In-Reply-To: <1445514628685.2749@aoe.com> References: <5628C52A.2030703@redhat.com> <1445514628685.2749@aoe.com> Message-ID: +1 Yep, by hostname I meant base url ;) On 22 October 2015 at 13:50, Sebastian Rose wrote: > +1 (for full origin) > > > > Regards, Sebastian > ------------------------------ > *Von:* keycloak-dev-bounces at lists.jboss.org < > keycloak-dev-bounces at lists.jboss.org> im Auftrag von Marek Posolda < > mposolda at redhat.com> > *Gesendet:* Donnerstag, 22. Oktober 2015 13:14 > *An:* stian at redhat.com; keycloak-dev > *Betreff:* Re: [keycloak-dev] Ability to set hostname for server > > +1 > > But not sure if hostname is sufficient. Shouldn't it rather be whole > origin including protocol and port? > > Marek > > On 22/10/15 08:42, Stian Thorgersen wrote: > > Currently we have a few people having issues with the fact that we use the > URL of the request as the hostname for Keycloak. For example to get the > address sent in emails or as the iss value in tokens. This works fine as > long as everyone accesses it using the proper domain name. However, it > doesn't work when servers are on the same local network use the direct IP > address or internal hostname. > > The simplest solution to this would be to add an option to set the > hostname for the server. This would be configured in keycloak-server.json, > but we'd also support setting it with a system property. Default would be > to use the request-url as we do now, but once specified we would not use > the request-url anymore and always use the configured hostname as the base > URL. > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/cd76387b/attachment.html From sthorger at redhat.com Thu Oct 22 13:29:04 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Oct 2015 19:29:04 +0200 Subject: [keycloak-dev] Access datasource from a CLI In-Reply-To: <5628E542.2030701@redhat.com> References: <5627A8EB.9000708@redhat.com> <5627B5E8.2000208@redhat.com> <5627D137.2080708@redhat.com> <5627D4B3.5030609@redhat.com> <5627D686.7030700@redhat.com> <5627E2B8.7060401@redhat.com> <5628DE8E.9040309@redhat.com> <5628E542.2030701@redhat.com> Message-ID: If you can manage to get the datasource in offline mode that'd be great, because then we don't have to do any hacks to get the connection. On 22 October 2015 at 15:31, Stan Silvert wrote: > On 10/22/2015 9:11 AM, Stian Thorgersen wrote: > > If we have to extract connection information from datasources in either > case we don't really get much benefit of using offline jboss cli though? > > You are reading standalone.xml in a standard way, which is better than > parsing it ourselves. > > Beyond that, I'd have to try it out to see what other benefits there would > be. It could be that it is indeed very easy to get the datasource > itself. Now that my brain is fixed concerning using Hibernate directly, > I'm thinking this might be possible. > > Of course, there are lots of benefits beyond the offline CLI use case, > which I've talked about at great length. > > > On 22 October 2015 at 15:03, Stan Silvert wrote: > >> On 10/22/2015 2:05 AM, Stian Thorgersen wrote: >> >> It can be JBoss CLI, that's no problem as long as it works, but if >> datasources are unavailable in offline mode then it's not going to help. >> >> Parsing the standalone.xml ourselves and extracting the datasource piece >> seems very brittle, that's why I was hoping there was some magic way we >> could get the datasource. Everything else should be easy enough. >> >> So if it's WildFly CLI then there is obviously no problem reading >> standalone.xml in a standard way. >> >> The custom commands we create for WildFly CLI can do anything we want. >> So by pulling in Hibernate and using its JPA implementation directly, we >> could do it. >> >> >> On 21 October 2015 at 22:48, Marko Strukelj wrote: >> >>> @Stian, so your original question is then: >>> >>> Can we have a non jboss-cli CLI that will use hibernate directly, and >>> configure it with datasource info from keycloak-server.json and >>> standalone.xml? >>> >>> That would involve identifying Datasource jndi lookup name, finding >>> datasource definition for it, identifying the driver used, and jboss-module >>> containing the driver ... >>> >>> As long as Hibernate is capable of using connection url to autodetect >>> dialect (AFAIK it can do that) it seems to me the answer is yes, that can >>> be done ... >>> On Oct 21, 2015 21:39, "Stian Thorgersen" wrote: >>> >>>> Nopes, that's not the job of EE containers, that's what Hibernate does. >>>> Hibernate does that perfectly well in standalone Java apps as well. As I >>>> said we manage our own EntityManagerFactory. >>>> >>>> Have you looked at KeycloakServer inside the testsuite? You can spin up >>>> a perfectly functional KC server with nothing but an embedded Undertow >>>> server. >>>> >>>> On 21 October 2015 at 21:08, Stan Silvert wrote: >>>> >>>>> On 10/21/2015 2:43 PM, Stian Thorgersen wrote: >>>>> >>>>> I have no idea what you mean about containers. As I said we manage our >>>>> own EntityManagerFactory, etc.. inside Keycloak. It doesn't rely on JEE for >>>>> that part. >>>>> >>>>> Somebody has to process the annotations in >>>>> org.keycloak.models.jpa.entities, do injection, interception, etc. That's >>>>> the job of the EE containers. >>>>> >>>>> >>>>> >>>>> We just need the classes which we can get with jboss-modules. >>>>> >>>>> On 21 October 2015 at 20:16, Stan Silvert wrote: >>>>> >>>>>> On 10/21/2015 2:08 PM, Stan Silvert wrote: >>>>>> >>>>>> On 10/21/2015 1:57 PM, Stian Thorgersen wrote: >>>>>> >>>>>> We manage our own EntityManagerFactory and EntityManager as well as >>>>>> our own transactions. So that's not true. >>>>>> >>>>>> If all you need is the datasource info that lives in standalone.xml >>>>>> then yes, we can get that. >>>>>> >>>>>> But I'm a little confused as to how this would work. Are you saying >>>>>> that you wouldn't use any of the classes in >>>>>> org.keycloak.models.jpa.entities? Those need containers. >>>>>> >>>>>> >>>>>> >>>>>> On 21 October 2015 at 19:53, Stan Silvert >>>>>> wrote: >>>>>> >>>>>>> On 10/21/2015 1:23 PM, Stian Thorgersen wrote: >>>>>>> >>>>>>> Guys - all we need is the datasource. I want to create a "db tool" >>>>>>> for Keycloak, this is not for the Admin CLI >>>>>>> >>>>>>> We don't need CDI, EJB, etc.. All we need is the datasource, or at >>>>>>> least the connection information for the datasource + we also need JBoss >>>>>>> modules so we can get the required classes. >>>>>>> >>>>>>> If offline mode can do this then that'd be good, but I seem to >>>>>>> remember datasources weren't available? >>>>>>> >>>>>>> If you want to use our existing JPA infrastructure then you need a >>>>>>> JPA container. That's where this other stuff all gets pulled in. >>>>>>> >>>>>>> Hey, let's just use JDBC! :-) >>>>>>> >>>>>>> >>>>>>> On 21 October 2015 at 18:22, Marko Strukelj >>>>>>> wrote: >>>>>>> >>>>>>>> On Wed, Oct 21, 2015 at 5:57 PM, Stan Silvert >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 10/21/2015 11:14 AM, Marko Strukelj wrote: >>>>>>>>> >>>>>>>>>> I haven't taken a very close look at Swarm yet, but I assumed you >>>>>>>>>> start Wildfly embedded in the same JVM as your Main class. If that is the >>>>>>>>>> case, then there should be no problem communicating with any kind of >>>>>>>>>> deployed component via heap directly - just lookup some singleton ... >>>>>>>>>> >>>>>>>>> Classloading constraints are what you usually run up against. You >>>>>>>>> can't use your own version of a class that was loaded from a different >>>>>>>>> classloader. I don't think Swarm helps you get around that, but just >>>>>>>>> assumes you will access the WAR in the usual way through an HTTP port. But >>>>>>>>> I could be wrong as I haven't worked with Swarm either. >>>>>>>>> >>>>>>>>> Here is an explanation of the problem based on an old version of >>>>>>>>> JBoss: >>>>>>>>> >>>>>>>>> https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/JBoss_JMX_Implementation_Architecture-Class_Loading_and_Types_in_Java.html >>>>>>>>> >>>>>>>>> With jboss-modules, it's easier to get around these problems, but >>>>>>>>> you still run into the isolation built into the container itself, >>>>>>>>> especially in the case of a WAR. >>>>>>>> >>>>>>>> >>>>>>>> CLI running in the same JVM as Wildfly would get bootstrapped >>>>>>>> through jboss-modules, and would package it's classes as a jboss module. It >>>>>>>> can then deploy additional 'in-container' logic that needs actual access to >>>>>>>> datasources via many different mechanisms. It can be a .jar containing a >>>>>>>> SLSB, a .war, a .sar, a POJO (via pojo subsystem), it can be a custom >>>>>>>> subsystem that gets installed ... In every of these cases it can then have >>>>>>>> access to resource objects bound to java:jboss JNDI space ... And in every >>>>>>>> of these cases it uses shared types loaded via dependencies on >>>>>>>> jboss-modules. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> If that is not the case, then we would need some kind of >>>>>>>>>> interprocess communication going. With shell the roles of who connects >>>>>>>>>> where could also be reversed, and a started up Wildfly instance could have >>>>>>>>>> a service connecting out to local port bound by our CLI rather than the >>>>>>>>>> other way around. >>>>>>>>>> >>>>>>>>> I don't think the direction of the connection matters so much as >>>>>>>>> the fact that you need a serialized format to issue commands to a foreign >>>>>>>>> container. >>>>>>>>> >>>>>>>>> Or, as I mentioned, you need the CLI to actually live inside the >>>>>>>>> container. >>>>>>>> >>>>>>>> >>>>>>>> CLI needs to be able to execute its logic inside the container in >>>>>>>> order to harness the datasources, but the UI part that takes care of >>>>>>>> getting the inputs and displaying the outputs - e.g. CraSH, does not have >>>>>>>> to be inside the container. >>>>>>>> >>>>>>>> I don't know what you mean by 'serialized format to issue commands >>>>>>>> to a foreign container', but if it means taking care of UI interaction, >>>>>>>> CraSH looks pretty decent CLI, easy to extend with custom commands. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/a8a71883/attachment-0001.html From sthorger at redhat.com Thu Oct 22 13:48:11 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 22 Oct 2015 19:48:11 +0200 Subject: [keycloak-dev] OpenShift and Docker updated to 1.6.0.Final Message-ID: The Keycloak OpenShift cartridge and Docker image has been updated to 1.6.0.Final -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151022/eb818c6e/attachment.html From ihamilto at redhat.com Fri Oct 23 04:14:18 2015 From: ihamilto at redhat.com (Ian Hamilton) Date: Fri, 23 Oct 2015 04:14:18 -0400 (EDT) Subject: [keycloak-dev] keycloak admin access in order to crate users In-Reply-To: <652883056.37089039.1445586951823.JavaMail.zimbra@redhat.com> Message-ID: <146171975.37097628.1445588058260.JavaMail.zimbra@redhat.com> Hi All, I am new to redHat and my role is to set up automation test frameworks for developers.redhat.com. I would like to know how to gain permissions to Keycloak admin in order create/delete new users on the fly in the tests using the Keycloak REST API? Or what the usual process is for creating users via the Keycloak. The reason for this is; when we make a new user for a test, we have a "clean slate" which allows us great control over how to shape that user for our test. And if we make that user using a REST API call, we avoid the time penalty of having to fill out a sign-up form (not to mention having to find any emails involved in confirming an email address). I would like to be able to do this locally, as well as in the staging environments. Could anyone point me in the right direction? thanks in advance, Ian From sthorger at redhat.com Fri Oct 23 04:19:19 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 23 Oct 2015 10:19:19 +0200 Subject: [keycloak-dev] keycloak admin access in order to crate users In-Reply-To: <146171975.37097628.1445588058260.JavaMail.zimbra@redhat.com> References: <652883056.37089039.1445586951823.JavaMail.zimbra@redhat.com> <146171975.37097628.1445588058260.JavaMail.zimbra@redhat.com> Message-ID: We have rest endpoints (as well as a java admin client library) for everything that can be done through the admin console. One issue at the moment is that the default username/password for the admin has to be changed through the admin console. That's something we're going to improve in the future, but for now you'd have to reset the password manually or use for example Sellenium to do it before running your tests. You can take a look at our Arquillian based testsuite that does exactly this: https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian On 23 October 2015 at 10:14, Ian Hamilton wrote: > Hi All, > > I am new to redHat and my role is to set up automation test frameworks for > developers.redhat.com. > > I would like to know how to gain permissions to Keycloak admin in order > create/delete new users on the fly in the tests using the Keycloak REST > API? Or what the usual process is for creating users via the Keycloak. > > The reason for this is; when we make a new user for a test, we have a > "clean slate" which allows us great control over how to shape that user for > our test. And if we make that user using a REST API call, we avoid the time > penalty of having to fill out a sign-up form (not to mention having to find > any emails involved in confirming an email address). > > I would like to be able to do this locally, as well as in the staging > environments. > > Could anyone point me in the right direction? > > thanks in advance, > Ian > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151023/6a81649e/attachment.html From sthorger at redhat.com Fri Oct 23 05:39:39 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 23 Oct 2015 11:39:39 +0200 Subject: [keycloak-dev] Considering to introduce release candidates Message-ID: Lately we've been following a pretty aggressive release schedule with a new Final released every 4 to 6 weeks. We want to continue having frequent releases, but at the same time it would be good to give people the opportunity to test things out in advance of a release. I propose we continue doing releases every 4-6 weeks, but instead of going straight to Final we'll release a CR1. If there are no high priority issues reported against within a week we'll release the Final. Otherwise we'll release CR2, but this time reduce the wait to roughly half a week before releasing Final (or CR3). We would not support migrating between CR releases as they are purely targeted towards testing. These releases should only be used in staging/test environments. Ideally with a copy of the production database. Basically that would mean that upgrading from 1.6.0.Final to 1.7.0.CR1 and then upgrading to 1.7.0.Final would not work. You would have to upgrade directly from 1.6.0.Final to 1.7.0.Final. I'd like to ask the community is this something that would be beneficial? Would you actually play with and test release candidates, or would you simply wait for the Final to be released? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151023/dbb27565/attachment.html From lkrzyzan at redhat.com Fri Oct 23 07:25:36 2015 From: lkrzyzan at redhat.com (Libor Krzyzanek) Date: Fri, 23 Oct 2015 13:25:36 +0200 Subject: [keycloak-dev] [keycloak-user] Considering to introduce release candidates In-Reply-To: References: Message-ID: This makes a lot of sense to me even It would not be possible to upgrade from CR1 to Final on staging. For those who?re waiting for upcoming release and need to be sure that Final version will work (like we do with 1.6.0) that approach will help for sure. Thanks for considering it. Libor Krzy?anek jboss.org Development Team > On Oct 23, 2015, at 11:39 AM, Stian Thorgersen wrote: > > Lately we've been following a pretty aggressive release schedule with a new Final released every 4 to 6 weeks. We want to continue having frequent releases, but at the same time it would be good to give people the opportunity to test things out in advance of a release. > > I propose we continue doing releases every 4-6 weeks, but instead of going straight to Final we'll release a CR1. If there are no high priority issues reported against within a week we'll release the Final. Otherwise we'll release CR2, but this time reduce the wait to roughly half a week before releasing Final (or CR3). > > We would not support migrating between CR releases as they are purely targeted towards testing. These releases should only be used in staging/test environments. Ideally with a copy of the production database. Basically that would mean that upgrading from 1.6.0.Final to 1.7.0.CR1 and then upgrading to 1.7.0.Final would not work. You would have to upgrade directly from 1.6.0.Final to 1.7.0.Final. > > I'd like to ask the community is this something that would be beneficial? Would you actually play with and test release candidates, or would you simply wait for the Final to be released? > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From ssilvert at redhat.com Fri Oct 23 07:26:11 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 23 Oct 2015 07:26:11 -0400 Subject: [keycloak-dev] keycloak admin access in order to crate users In-Reply-To: References: <652883056.37089039.1445586951823.JavaMail.zimbra@redhat.com> <146171975.37097628.1445588058260.JavaMail.zimbra@redhat.com> Message-ID: <562A1953.5030106@redhat.com> You might also consider importing a new realm at startup. It won't help with delete, but you could just delete the entire database and then rebuild it from scratch using realm import. See the documentation that here: http://keycloak.github.io/docs/userguide/keycloak-server/html/export-import.html We are planning to improve that feature as well where you can just drop a file in a directory instead of specifying it on the command line. Stan On 10/23/2015 4:19 AM, Stian Thorgersen wrote: > We have rest endpoints (as well as a java admin client library) for > everything that can be done through the admin console. One issue at > the moment is that the default username/password for the admin has to > be changed through the admin console. That's something we're going to > improve in the future, but for now you'd have to reset the password > manually or use for example Sellenium to do it before running your > tests. You can take a look at our Arquillian based testsuite that does > exactly this: > https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian > > On 23 October 2015 at 10:14, Ian Hamilton > wrote: > > Hi All, > > I am new to redHat and my role is to set up automation test > frameworks for developers.redhat.com . > > I would like to know how to gain permissions to Keycloak admin in > order create/delete new users on the fly in the tests using the > Keycloak REST API? Or what the usual process is for creating users > via the Keycloak. > > The reason for this is; when we make a new user for a test, we > have a "clean slate" which allows us great control over how to > shape that user for our test. And if we make that user using a > REST API call, we avoid the time penalty of having to fill out a > sign-up form (not to mention having to find any emails involved in > confirming an email address). > > I would like to be able to do this locally, as well as in the > staging environments. > > Could anyone point me in the right direction? > > thanks in advance, > Ian > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151023/8510a0c0/attachment-0001.html From ssilvert at redhat.com Fri Oct 23 07:33:27 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 23 Oct 2015 07:33:27 -0400 Subject: [keycloak-dev] Considering to introduce release candidates In-Reply-To: References: Message-ID: <562A1B07.6070900@redhat.com> +1 I love the idea that we release something that lets enthusiastic early adopters try new features before they go final. Even if the CR doesn't get lots of use, I think that any extra feedback we get will be helpful. Stan On 10/23/2015 5:39 AM, Stian Thorgersen wrote: > Lately we've been following a pretty aggressive release schedule with > a new Final released every 4 to 6 weeks. We want to continue having > frequent releases, but at the same time it would be good to give > people the opportunity to test things out in advance of a release. > > I propose we continue doing releases every 4-6 weeks, but instead of > going straight to Final we'll release a CR1. If there are no high > priority issues reported against within a week we'll release the > Final. Otherwise we'll release CR2, but this time reduce the wait to > roughly half a week before releasing Final (or CR3). > > We would not support migrating between CR releases as they are purely > targeted towards testing. These releases should only be used in > staging/test environments. Ideally with a copy of the production > database. Basically that would mean that upgrading from 1.6.0.Final to > 1.7.0.CR1 and then upgrading to 1.7.0.Final would not work. You would > have to upgrade directly from 1.6.0.Final to 1.7.0.Final. > > I'd like to ask the community is this something that would be > beneficial? Would you actually play with and test release candidates, > or would you simply wait for the Final to be released? > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151023/ea1d613d/attachment.html From mposolda at redhat.com Fri Oct 23 08:22:16 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 23 Oct 2015 14:22:16 +0200 Subject: [keycloak-dev] Batch import/export In-Reply-To: References: <562781FC.2020207@redhat.com> Message-ID: <562A2678.2010200@redhat.com> Sorry for late response. Is the scope of this task also to improve big long-running export/import ? We already have someone with 75.000 users in DB. It seems that export/import is kind of task, which can be easily "paginated" (Export of user1 - user500 is page1, export of user501-user1000 is page2 etc). We may have the table where you can see the progress of long-running export/import job and how many users (pages) are already exported. Besides that we may support: - Concurrency (more worker threads. Each worker doing an export of different page) - Cluster scalability (Each cluster node takes some pages and helps with the overall export task) - Cluster failover (When some cluster node crashes during export job, the whole job is not canceled but continue on other cluster nodes without problem) I've already addressed the concurrency, scalability and failover with the InfinispanUserSessionInitializer, which is used at startup for pre-load offline sessions from DB. It's based on infinispan Distributed Executor service. I think that with some minor changes (maybe even without them) it can be reused for any long running "paginatable" job (export/import, sync of big number of users from federationProvider etc) Marek On 21/10/15 14:44, Stian Thorgersen wrote: > I've just added client registration services in 1.6 which should be > more useful for that. There's also a Java library. Basically admins > and service accounts with the role create-client can create new > clients, while clients themselves have permissions to update their > config. > > You could have a client template that you change the client-id only > then use this endpoint to register the client. > > On 21 October 2015 at 14:40, Thomas Raehalme > > wrote: > > If you deploy the same application multiple times for different > customers you could have a configuration template containing all > the common bits and pieces, but have Keycloak generate keys and > secrets when you import the configuration. > > Best regards, > Thomas > > > On Wed, Oct 21, 2015 at 3:33 PM, Stian Thorgersen > > wrote: > > Can you elaborate a bit on that? > > On 21 October 2015 at 14:29, Thomas Raehalme > > wrote: > > > > On Wed, Oct 21, 2015 at 3:27 PM, Stian Thorgersen > > wrote: > > I'd like to get import/export done properly. The > addition of being able to add bits and pieces to > import in a directory would be really helpful on > Docker/OpenShift/etc.. > > > I had similar things in mind when I suggested the > re-generation of keys and secrets. You could define a > template which you'd use in a process for new deployments. > > Best regards, > Thomas > > > > > > -- > *Thomas Raehalme* > /CTO, teknologiajohtaja/ > Mobile +358 40 545 0605 > > *Aitio Finland Oy* > V?in?nkatu 26 A > 40100 JYV?SKYL?, Finland > Tel. +358 10 322 0040 > www.aitiofinland.com > > *Codecenter on nyt Aitio ? me kun ei vain koodata!* > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151023/cbee520c/attachment.html From sthorger at redhat.com Fri Oct 23 09:09:45 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 23 Oct 2015 15:09:45 +0200 Subject: [keycloak-dev] Batch import/export In-Reply-To: <562A2678.2010200@redhat.com> References: <562781FC.2020207@redhat.com> <562A2678.2010200@redhat.com> Message-ID: We already have paginated export of users though? On 23 October 2015 at 14:22, Marek Posolda wrote: > Sorry for late response. Is the scope of this task also to improve big > long-running export/import ? We already have someone with 75.000 users in > DB. > > It seems that export/import is kind of task, which can be easily > "paginated" (Export of user1 - user500 is page1, export of user501-user1000 > is page2 etc). We may have the table where you can see the progress of > long-running export/import job and how many users (pages) are already > exported. > > Besides that we may support: > - Concurrency (more worker threads. Each worker doing an export of > different page) > - Cluster scalability (Each cluster node takes some pages and helps with > the overall export task) > - Cluster failover (When some cluster node crashes during export job, the > whole job is not canceled but continue on other cluster nodes without > problem) > > I've already addressed the concurrency, scalability and failover with the InfinispanUserSessionInitializer, > which is used at startup for pre-load offline sessions from DB. It's based > on infinispan Distributed Executor service. I think that with some minor > changes (maybe even without them) it can be reused for any long running > "paginatable" job (export/import, sync of big number of users from > federationProvider etc) > > Marek > > On 21/10/15 14:44, Stian Thorgersen wrote: > > I've just added client registration services in 1.6 which should be more > useful for that. There's also a Java library. Basically admins and service > accounts with the role create-client can create new clients, while clients > themselves have permissions to update their config. > > You could have a client template that you change the client-id only then > use this endpoint to register the client. > > On 21 October 2015 at 14:40, Thomas Raehalme < > thomas.raehalme at aitiofinland.com> wrote: > >> If you deploy the same application multiple times for different customers >> you could have a configuration template containing all the common bits and >> pieces, but have Keycloak generate keys and secrets when you import the >> configuration. >> >> Best regards, >> Thomas >> >> >> On Wed, Oct 21, 2015 at 3:33 PM, Stian Thorgersen >> wrote: >> >>> Can you elaborate a bit on that? >>> >>> On 21 October 2015 at 14:29, Thomas Raehalme < >>> thomas.raehalme at aitiofinland.com> >>> wrote: >>> >>>> >>>> >>>> On Wed, Oct 21, 2015 at 3:27 PM, Stian Thorgersen < >>>> sthorger at redhat.com> wrote: >>>> >>>>> I'd like to get import/export done properly. The addition of being >>>>> able to add bits and pieces to import in a directory would be really >>>>> helpful on Docker/OpenShift/etc.. >>>>> >>>> >>>> I had similar things in mind when I suggested the re-generation of keys >>>> and secrets. You could define a template which you'd use in a process for >>>> new deployments. >>>> >>>> Best regards, >>>> Thomas >>>> >>> >>> >> >> >> -- >> *Thomas Raehalme* >> *CTO, teknologiajohtaja* >> Mobile +358 40 545 0605 <%2B358%2040%20545%200605> >> >> *Aitio Finland Oy* >> V?in?nkatu 26 A >> 40100 JYV?SKYL?, Finland >> Tel. +358 10 322 0040 <%2B358%2010%20322%200040> >> www.aitiofinland.com >> >> *Codecenter on nyt Aitio ? me kun ei vain koodata!* >> >> > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151023/31842d9a/attachment-0001.html From ssilvert at redhat.com Fri Oct 23 09:11:56 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 23 Oct 2015 09:11:56 -0400 Subject: [keycloak-dev] Batch import/export In-Reply-To: References: <562781FC.2020207@redhat.com> <562A2678.2010200@redhat.com> Message-ID: <562A321C.2090701@redhat.com> On 10/23/2015 9:09 AM, Stian Thorgersen wrote: > We already have paginated export of users though? I haven't started on export. So far, I've done batch import of users, clients, and identity providers. > > On 23 October 2015 at 14:22, Marek Posolda > wrote: > > Sorry for late response. Is the scope of this task also to improve > big long-running export/import ? We already have someone with > 75.000 users in DB. > > It seems that export/import is kind of task, which can be easily > "paginated" (Export of user1 - user500 is page1, export of > user501-user1000 is page2 etc). We may have the table where you > can see the progress of long-running export/import job and how > many users (pages) are already exported. > > Besides that we may support: > - Concurrency (more worker threads. Each worker doing an export of > different page) > - Cluster scalability (Each cluster node takes some pages and > helps with the overall export task) > - Cluster failover (When some cluster node crashes during export > job, the whole job is not canceled but continue on other cluster > nodes without problem) > > I've already addressed the concurrency, scalability and failover > with the InfinispanUserSessionInitializer, which is used at > startup for pre-load offline sessions from DB. It's based on > infinispan Distributed Executor service. I think that with some > minor changes (maybe even without them) it can be reused for any > long running "paginatable" job (export/import, sync of big number > of users from federationProvider etc) > > Marek > > On 21/10/15 14:44, Stian Thorgersen wrote: >> I've just added client registration services in 1.6 which should >> be more useful for that. There's also a Java library. Basically >> admins and service accounts with the role create-client can >> create new clients, while clients themselves have permissions to >> update their config. >> >> You could have a client template that you change the client-id >> only then use this endpoint to register the client. >> >> On 21 October 2015 at 14:40, Thomas Raehalme >> > > wrote: >> >> If you deploy the same application multiple times for >> different customers you could have a configuration template >> containing all the common bits and pieces, but have Keycloak >> generate keys and secrets when you import the configuration. >> >> Best regards, >> Thomas >> >> >> On Wed, Oct 21, 2015 at 3:33 PM, Stian Thorgersen >> > wrote: >> >> Can you elaborate a bit on that? >> >> On 21 October 2015 at 14:29, Thomas Raehalme >> > > wrote: >> >> >> >> On Wed, Oct 21, 2015 at 3:27 PM, Stian Thorgersen >> > wrote: >> >> I'd like to get import/export done properly. The >> addition of being able to add bits and pieces to >> import in a directory would be really helpful on >> Docker/OpenShift/etc.. >> >> >> I had similar things in mind when I suggested the >> re-generation of keys and secrets. You could define a >> template which you'd use in a process for new >> deployments. >> >> Best regards, >> Thomas >> >> >> >> >> >> -- >> *Thomas Raehalme* >> /CTO, teknologiajohtaja/ >> Mobile +358 40 545 0605 >> >> *Aitio Finland Oy* >> V?in?nkatu 26 A >> 40100 JYV?SKYL?, Finland >> Tel. +358 10 322 0040 >> www.aitiofinland.com >> >> *Codecenter on nyt Aitio -- me kun ei vain koodata!* >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151023/d118c850/attachment.html From sthorger at redhat.com Fri Oct 23 09:14:47 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 23 Oct 2015 15:14:47 +0200 Subject: [keycloak-dev] Batch import/export In-Reply-To: <562A321C.2090701@redhat.com> References: <562781FC.2020207@redhat.com> <562A2678.2010200@redhat.com> <562A321C.2090701@redhat.com> Message-ID: The good old import/export stuff does pagination. I don't think the admin console export you're working on needs pagination. On 23 October 2015 at 15:11, Stan Silvert wrote: > On 10/23/2015 9:09 AM, Stian Thorgersen wrote: > > We already have paginated export of users though? > > I haven't started on export. So far, I've done batch import of users, > clients, and identity providers. > > > On 23 October 2015 at 14:22, Marek Posolda wrote: > >> Sorry for late response. Is the scope of this task also to improve big >> long-running export/import ? We already have someone with 75.000 users in >> DB. >> >> It seems that export/import is kind of task, which can be easily >> "paginated" (Export of user1 - user500 is page1, export of user501-user1000 >> is page2 etc). We may have the table where you can see the progress of >> long-running export/import job and how many users (pages) are already >> exported. >> >> Besides that we may support: >> - Concurrency (more worker threads. Each worker doing an export of >> different page) >> - Cluster scalability (Each cluster node takes some pages and helps with >> the overall export task) >> - Cluster failover (When some cluster node crashes during export job, the >> whole job is not canceled but continue on other cluster nodes without >> problem) >> >> I've already addressed the concurrency, scalability and failover with the InfinispanUserSessionInitializer, >> which is used at startup for pre-load offline sessions from DB. It's based >> on infinispan Distributed Executor service. I think that with some minor >> changes (maybe even without them) it can be reused for any long running >> "paginatable" job (export/import, sync of big number of users from >> federationProvider etc) >> >> Marek >> >> On 21/10/15 14:44, Stian Thorgersen wrote: >> >> I've just added client registration services in 1.6 which should be more >> useful for that. There's also a Java library. Basically admins and service >> accounts with the role create-client can create new clients, while clients >> themselves have permissions to update their config. >> >> You could have a client template that you change the client-id only then >> use this endpoint to register the client. >> >> On 21 October 2015 at 14:40, Thomas Raehalme < >> thomas.raehalme at aitiofinland.com> wrote: >> >>> If you deploy the same application multiple times for different >>> customers you could have a configuration template containing all the common >>> bits and pieces, but have Keycloak generate keys and secrets when you >>> import the configuration. >>> >>> Best regards, >>> Thomas >>> >>> >>> On Wed, Oct 21, 2015 at 3:33 PM, Stian Thorgersen >>> wrote: >>> >>>> Can you elaborate a bit on that? >>>> >>>> On 21 October 2015 at 14:29, Thomas Raehalme < >>>> thomas.raehalme at aitiofinland.com> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Oct 21, 2015 at 3:27 PM, Stian Thorgersen >>>> > wrote: >>>>> >>>>>> I'd like to get import/export done properly. The addition of being >>>>>> able to add bits and pieces to import in a directory would be really >>>>>> helpful on Docker/OpenShift/etc.. >>>>>> >>>>> >>>>> I had similar things in mind when I suggested the re-generation of >>>>> keys and secrets. You could define a template which you'd use in a process >>>>> for new deployments. >>>>> >>>>> Best regards, >>>>> Thomas >>>>> >>>> >>>> >>> >>> >>> -- >>> *Thomas Raehalme* >>> *CTO, teknologiajohtaja* >>> Mobile +358 40 545 0605 >>> >>> *Aitio Finland Oy* >>> V?in?nkatu 26 A >>> 40100 JYV?SKYL?, Finland >>> Tel. +358 10 322 0040 >>> www.aitiofinland.com >>> >>> *Codecenter on nyt Aitio ? me kun ei vain koodata!* >>> >>> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151023/48742e09/attachment-0001.html From mposolda at redhat.com Fri Oct 23 10:37:53 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 23 Oct 2015 16:37:53 +0200 Subject: [keycloak-dev] Batch import/export In-Reply-To: References: <562781FC.2020207@redhat.com> <562A2678.2010200@redhat.com> Message-ID: <562A4641.3050901@redhat.com> Yes, DirExportProvider provides pagination in separate transactions. But it's doing everything sequentially on single cluster node (no cluster awareness). If host crashes after 50.000 users exported, you need to start again. In shortcut, what we don't yet have is: concurrency, cluster scalability + failover, possibility to see progress of long running task in admin console Marek On 23/10/15 15:09, Stian Thorgersen wrote: > We already have paginated export of users though? > > On 23 October 2015 at 14:22, Marek Posolda > wrote: > > Sorry for late response. Is the scope of this task also to improve > big long-running export/import ? We already have someone with > 75.000 users in DB. > > It seems that export/import is kind of task, which can be easily > "paginated" (Export of user1 - user500 is page1, export of > user501-user1000 is page2 etc). We may have the table where you > can see the progress of long-running export/import job and how > many users (pages) are already exported. > > Besides that we may support: > - Concurrency (more worker threads. Each worker doing an export of > different page) > - Cluster scalability (Each cluster node takes some pages and > helps with the overall export task) > - Cluster failover (When some cluster node crashes during export > job, the whole job is not canceled but continue on other cluster > nodes without problem) > > I've already addressed the concurrency, scalability and failover > with the InfinispanUserSessionInitializer, which is used at > startup for pre-load offline sessions from DB. It's based on > infinispan Distributed Executor service. I think that with some > minor changes (maybe even without them) it can be reused for any > long running "paginatable" job (export/import, sync of big number > of users from federationProvider etc) > > Marek > > On 21/10/15 14:44, Stian Thorgersen wrote: >> I've just added client registration services in 1.6 which should >> be more useful for that. There's also a Java library. Basically >> admins and service accounts with the role create-client can >> create new clients, while clients themselves have permissions to >> update their config. >> >> You could have a client template that you change the client-id >> only then use this endpoint to register the client. >> >> On 21 October 2015 at 14:40, Thomas Raehalme >> > > wrote: >> >> If you deploy the same application multiple times for >> different customers you could have a configuration template >> containing all the common bits and pieces, but have Keycloak >> generate keys and secrets when you import the configuration. >> >> Best regards, >> Thomas >> >> >> On Wed, Oct 21, 2015 at 3:33 PM, Stian Thorgersen >> > wrote: >> >> Can you elaborate a bit on that? >> >> On 21 October 2015 at 14:29, Thomas Raehalme >> > > wrote: >> >> >> >> On Wed, Oct 21, 2015 at 3:27 PM, Stian Thorgersen >> > wrote: >> >> I'd like to get import/export done properly. The >> addition of being able to add bits and pieces to >> import in a directory would be really helpful on >> Docker/OpenShift/etc.. >> >> >> I had similar things in mind when I suggested the >> re-generation of keys and secrets. You could define a >> template which you'd use in a process for new >> deployments. >> >> Best regards, >> Thomas >> >> >> >> >> >> -- >> *Thomas Raehalme* >> /CTO, teknologiajohtaja/ >> Mobile +358 40 545 0605 >> >> *Aitio Finland Oy* >> V?in?nkatu 26 A >> 40100 JYV?SKYL?, Finland >> Tel. +358 10 322 0040 >> www.aitiofinland.com >> >> *Codecenter on nyt Aitio ? me kun ei vain koodata!* >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151023/5787c241/attachment.html From andipansa at gmail.com Sun Oct 25 16:51:26 2015 From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=) Date: Sun, 25 Oct 2015 21:51:26 +0100 Subject: [keycloak-dev] Keycloak - unit tests Message-ID: Hi everyone! I decided to implement KEYCLOAK-1797 and started to look at the code (federation/ldap). I noticed lack of unit tests without which refactoring may be very error prone. I like writing test so I can write tests for that part. What are you thinking about it?? Best Regards, Andrzej -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151025/ce33020a/attachment.html From mposolda at redhat.com Mon Oct 26 03:41:02 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 26 Oct 2015 08:41:02 +0100 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: References: Message-ID: <562DD90E.6010405@redhat.com> Hi, most of the tests are in the testsuite/integration or testsuite/integration-arquillian, not in the modules itself. For the federation and ldap, you can take a look especially to package org.keycloak.testsuite.federation . Marek On 25/10/15 21:51, Andrzej Go?awski wrote: > Hi everyone! > > I decided to implement KEYCLOAK-1797 and started to look at the code > (federation/ldap). I noticed lack of unit tests without which > refactoring may be very error prone. I like writing test so I can > write tests for that part. What are you thinking about it?? > > Best Regards, > Andrzej > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151026/1c46bb1b/attachment-0001.html From andipansa at gmail.com Mon Oct 26 03:55:20 2015 From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=) Date: Mon, 26 Oct 2015 08:55:20 +0100 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: <562DD90E.6010405@redhat.com> References: <562DD90E.6010405@redhat.com> Message-ID: Hi Marek, Thanks for reply! I saw those test, but personally I prefer unit tests over integrated tests:) I really recommend this: https://vimeo.com/80533536 Best Regards, Andrzej 2015-10-26 8:41 GMT+01:00 Marek Posolda : > Hi, > > most of the tests are in the testsuite/integration or > testsuite/integration-arquillian, not in the modules itself. For the > federation and ldap, you can take a look especially to package > org.keycloak.testsuite.federation . > > Marek > > On 25/10/15 21:51, Andrzej Go?awski wrote: > > Hi everyone! > > I decided to implement KEYCLOAK-1797 and started to look at the code > (federation/ldap). I noticed lack of unit tests without which refactoring > may be very error prone. I like writing test so I can write tests for that > part. What are you thinking about it?? > > Best Regards, > Andrzej > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151026/690173d8/attachment.html From mposolda at redhat.com Mon Oct 26 09:11:02 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 26 Oct 2015 14:11:02 +0100 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: References: <562DD90E.6010405@redhat.com> Message-ID: <562E2666.6080700@redhat.com> We prefer integration tests as you usually need more things to have available. For example for federation, you need realm and user DB and you need to have realm configured with federationProvider. There is not much you can test within single module, so we have just very simple tests in individual modules (like LDAPDnTest or PasswordPolicyTest), but most of the stuff is tested in testsuite. For KEYCLOAK-1797 I prefer to take a look at LDAPRoleMappingsTest and possibly add new test methods here. Btv. what's your plan for KEYCLOAK-1797 ? And in your LDAP environment, is it often that new role is added as member to some other roles? I wonder if we need to always do "deep" search in runtime, or if we can instead do it just at some point and rely on Keycloak composite roles . If you always need deep search and do something based on it, it will be good to have a flag in configuration, which will allow to disable it (for performance reasons). Marek On 26/10/15 08:55, Andrzej Go?awski wrote: > Hi Marek, > > Thanks for reply! > I saw those test, but personally I prefer unit tests over integrated > tests:) > I really recommend this: https://vimeo.com/80533536 > > Best Regards, > Andrzej > > 2015-10-26 8:41 GMT+01:00 Marek Posolda >: > > Hi, > > most of the tests are in the testsuite/integration or > testsuite/integration-arquillian, not in the modules itself. For > the federation and ldap, you can take a look especially to package > org.keycloak.testsuite.federation . > > Marek > > On 25/10/15 21:51, Andrzej Go?awski wrote: >> Hi everyone! >> >> I decided to implement KEYCLOAK-1797 and started to look at the >> code (federation/ldap). I noticed lack of unit tests without >> which refactoring may be very error prone. I like writing test so >> I can write tests for that part. What are you thinking about it?? >> >> Best Regards, >> Andrzej >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151026/d46e547b/attachment.html From mposolda at redhat.com Tue Oct 27 04:33:44 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 27 Oct 2015 09:33:44 +0100 Subject: [keycloak-dev] Plan for "First login with identity brokers" Message-ID: <562F36E8.9060501@redhat.com> I went again through all the previous discussions, related JIRAs and requirements. As of now, my plan is to: - Use authentication SPI to handle the flow and related actions for first social login. (Update user profile, Detect duplicated account, Verify email or reauthenticate user if duplication is detected, Create social link to existing account). This allows most flexibility for admins to specify how exactly the linking should work - Detecting duplication will be based on email only by default - (For example duplication is detected if Facebook user with email bob at gmail.com authenticates, but there is already Keycloak user with email bob at gmail.com ). The people can provide their own execution if they want different way for detect duplications - It seems it's more proper to postpone creating user account later, once we know that there is no duplication. In other words, if "Update profile on first login" is enabled, the user account is not yet created when the update profile page is shown. All the info related to BrokeredIdentityContext stuff will be available on ClientSession. This seems to me easier and more proper solution then creating temporary account with email in some "temporary" attribute. Temporary accounts have other challenges (Cleaner thread for delete outdated unmerged accounts etc). - If "trustEmail" flag is on for IdentityProvider, the provider link will be created automatically. (For example if Facebook user bob at gmail.com authenticates for the first time and there is already Keycloak user with email bob at gmail.com and trustEmail is on, the Facebook link is automatically created for Keycloak account bob at gmail.com without any additional verification) - If "trustEmail" flag is off, there would need to be other way to verify user before creating social link. The user will first confirm if he wants to merge the accounts. Then there will be either: -- Email verification: The mail will be sent to bob at gmail.com like "Someone authenticates to Keycloak server http://www.keycloak.org:8080 through Facebook account bob at gmail.com and wants to link Facebook account with existing Keycloak account bob at gmail.com . If it is you, click here" . After user clicks, the social link is created -- Further authentication: User will need to authenticate to existing bob at gmail.com keycloak account through password (or OTP or both or something else) All of this is configurable through flows, so admin can disable the "Do you want to create social link?" screen, or enforce email verification instead of authentication, configure required authenticators etc. - I am not sure if we want to handle just merge with existing account during first broker login, or if we also want to handle merging of accounts in account management? For now, I am planning to handle just the login flow and possibly address Account management later if there is need for it. The merging accounts in account management might be quite a challenge as there is merge of 2 already existing user accounts with various issues related to it (Which roles/permissions should merged account have? Which attributes it should have? Which federation link? etc.). But at least, I am planning to address the issue with redirect to login forms error screen instead of stay in account management - https://issues.jboss.org/browse/KEYCLOAK-1822 Marek From andipansa at gmail.com Tue Oct 27 04:41:14 2015 From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=) Date: Tue, 27 Oct 2015 09:41:14 +0100 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: <562E2666.6080700@redhat.com> References: <562DD90E.6010405@redhat.com> <562E2666.6080700@redhat.com> Message-ID: "For example for federation, you need realm and user DB and you need to have realm configured with federation Provider" In such cases you can use mocks, stubs and object factories. "There is not much you can test within single module" IMHO there are still few things which would be nice to test. Look at the first class in the module LDAP Config for example. There are few comments suggesting refactoring it in the feature. I find refactoring single class or classes with heavy integration test painful and insufficient. Look at spring framework code. There are plenty of small unit tests which test only one thing so that it is really well tested as a whole! I think good testing is especially important in case of open source - where everybody adds some code. For instance me :) For me LDAP it is a new topic, but I would like to add some code to this part ... so I expect to make o a lot of mistakes :D "Btv. what's your plan for KEYCLOAK-1797" And now the hardest part :) As I said, I'm new in this topic (LDAP) so I decided to wrap my head around it for a while - can you reccommend me any reading materials suitable for beginners? "And in your LDAP environment, is it often that new role is added as member to some other roles?" No .. but it is critical in my company. "I wonder if we need to always do "deep" search in runtime, or if we can instead do it just at some point and rely on Keycloak composite roles . If you always need deep search and do something based on it, it will be good to have a flag in configuration, which will allow to disable it (for performance reasons)." Thank you for the hint :) I couldn't agree more. Best regards, Andrzej 2015-10-26 14:11 GMT+01:00 Marek Posolda : > We prefer integration tests as you usually need more things to have > available. For example for federation, you need realm and user DB and you > need to have realm configured with federationProvider. There is not much > you can test within single module, so we have just very simple tests in > individual modules (like LDAPDnTest or PasswordPolicyTest), but most of the > stuff is tested in testsuite. For KEYCLOAK-1797 I prefer to take a look at LDAPRoleMappingsTest > and possibly add new test methods here. > > Btv. what's your plan for KEYCLOAK-1797 ? And in your LDAP environment, is > it often that new role is added as member to some other roles? I wonder if > we need to always do "deep" search in runtime, or if we can instead do it > just at some point and rely on Keycloak composite roles . If you always > need deep search and do something based on it, it will be good to have a > flag in configuration, which will allow to disable it (for performance > reasons). > > Marek > > On 26/10/15 08:55, Andrzej Go?awski wrote: > > Hi Marek, > > Thanks for reply! > I saw those test, but personally I prefer unit tests over integrated > tests:) > I really recommend this: https://vimeo.com/80533536 > > Best Regards, > Andrzej > > 2015-10-26 8:41 GMT+01:00 Marek Posolda : > >> Hi, >> >> most of the tests are in the testsuite/integration or >> testsuite/integration-arquillian, not in the modules itself. For the >> federation and ldap, you can take a look especially to package >> org.keycloak.testsuite.federation . >> >> Marek >> >> On 25/10/15 21:51, Andrzej Go?awski wrote: >> >> Hi everyone! >> >> I decided to implement KEYCLOAK-1797 and started to look at the code >> (federation/ldap). I noticed lack of unit tests without which refactoring >> may be very error prone. I like writing test so I can write tests for that >> part. What are you thinking about it?? >> >> Best Regards, >> Andrzej >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151027/d73304b1/attachment-0001.html From ssilvert at redhat.com Tue Oct 27 07:26:56 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 27 Oct 2015 07:26:56 -0400 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: References: <562DD90E.6010405@redhat.com> <562E2666.6080700@redhat.com> Message-ID: <562F5F80.2050107@redhat.com> You should never use mocks again. I elaborated on this topic in Bill's blog several years ago and he wrote a followup article: http://bill.burkecentral.com/2012/05/01/mocks-are-a-mockery/ On 10/27/2015 4:41 AM, Andrzej Go?awski wrote: > "For example for federation, you need realm and user DB and you need > to have realm configured with federation Provider" > > In such cases you can use mocks, stubs and object factories. > > "There is not much you can test within single module" > > IMHO there are still few things which would be nice to test. Look at > the first class in the module LDAP Config for example. There are few > comments suggesting refactoring it in the feature. I find refactoring > single class or classes with heavy integration test painful and > insufficient. Look at spring framework code. There are plenty of small > unit tests which test only one thing so that it is really well tested > as a whole! I think good testing is especially important in case of > open source - where everybody adds some code. For instance me :) For > me LDAP it is a new topic, but I would like to add some code to this > part ... so I expect to make o a lot of mistakes :D > "Btv. what's your plan for KEYCLOAK-1797" > And now the hardest part :) As I said, I'm new in this topic (LDAP) > so I decided to wrap my head around it for a while - can you > reccommend me any reading materials suitable for beginners? > > "And in your LDAP environment, is it often that new role is added as > member to some other roles?" > > No .. but it is critical in my company. > > "I wonder if we need to always do "deep" search in runtime, or if we > can instead do it just at some point and rely on Keycloak composite > roles . If you always need deep search and do something based on it, > it will be good to have a flag in configuration, which will allow to > disable it (for performance reasons)." > > Thank you for the hint :) I couldn't agree more. > > Best regards, > > Andrzej > > 2015-10-26 14:11 GMT+01:00 Marek Posolda >: > > We prefer integration tests as you usually need more things to > have available. For example for federation, you need realm and > user DB and you need to have realm configured with > federationProvider. There is not much you can test within single > module, so we have just very simple tests in individual modules > (like LDAPDnTest or PasswordPolicyTest), but most of the stuff is > tested in testsuite. For KEYCLOAK-1797 I prefer to take a look at > LDAPRoleMappingsTest and possibly add new test methods here. > > Btv. what's your plan for KEYCLOAK-1797 ? And in your LDAP > environment, is it often that new role is added as member to some > other roles? I wonder if we need to always do "deep" search in > runtime, or if we can instead do it just at some point and rely on > Keycloak composite roles . If you always need deep search and do > something based on it, it will be good to have a flag in > configuration, which will allow to disable it (for performance > reasons). > > Marek > > On 26/10/15 08:55, Andrzej Go?awski wrote: >> Hi Marek, >> >> Thanks for reply! >> I saw those test, but personally I prefer unit tests over >> integrated tests:) >> I really recommend this: https://vimeo.com/80533536 >> >> Best Regards, >> Andrzej >> >> 2015-10-26 8:41 GMT+01:00 Marek Posolda > >: >> >> Hi, >> >> most of the tests are in the testsuite/integration or >> testsuite/integration-arquillian, not in the modules itself. >> For the federation and ldap, you can take a look especially >> to package org.keycloak.testsuite.federation . >> >> Marek >> >> On 25/10/15 21:51, Andrzej Go?awski wrote: >>> Hi everyone! >>> >>> I decided to implement KEYCLOAK-1797 and started to look at >>> the code (federation/ldap). I noticed lack of unit tests >>> without which refactoring may be very error prone. I like >>> writing test so I can write tests for that part. What are >>> you thinking about it?? >>> >>> Best Regards, >>> Andrzej >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151027/b75dd295/attachment.html From bburke at redhat.com Tue Oct 27 09:05:23 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 27 Oct 2015 09:05:23 -0400 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: <562F36E8.9060501@redhat.com> References: <562F36E8.9060501@redhat.com> Message-ID: <562F7693.80805@redhat.com> IMO, most applications will not care about account duplication. Most users won't care about account linking. So, IMO: 1) users should not be required to link accounts. In the case where an account cannot be automatically linked a duplicate account should be created 2) Providers should be trusted by default. Trusted providers can just automatically link themselves to existing accounts that were logged in by other trusted providers. 3) Untrusted providers can automatically link if email has been verified for all parties. 4) Users can merge accounts that have verified emails. 5) An alternative to user self merging of account could be requiring to enter in a temporary code after logging into each account. #1 and #2 can be added with minimal changes to code. #3 requires a flow on broker login and a rework of the broker SPI. #4 is account service changes. #5 might be as easy as adding a required action. I guess it depends if ultimate flexibility is needed. #1, #2 and #4 might be enough and require the least amount of changes and SPI refactoring. On 10/27/2015 4:33 AM, Marek Posolda wrote: > I went again through all the previous discussions, related JIRAs and > requirements. As of now, my plan is to: > > - Use authentication SPI to handle the flow and related actions for > first social login. (Update user profile, Detect duplicated account, > Verify email or reauthenticate user if duplication is detected, Create > social link to existing account). This allows most flexibility for > admins to specify how exactly the linking should work > > - Detecting duplication will be based on email only by default - (For > example duplication is detected if Facebook user with email > bob at gmail.com authenticates, but there is already Keycloak user with > email bob at gmail.com ). The people can provide their own execution if > they want different way for detect duplications > > - It seems it's more proper to postpone creating user account later, > once we know that there is no duplication. In other words, if "Update > profile on first login" is enabled, the user account is not yet created > when the update profile page is shown. All the info related to > BrokeredIdentityContext stuff will be available on ClientSession. This > seems to me easier and more proper solution then creating temporary > account with email in some "temporary" attribute. Temporary accounts > have other challenges (Cleaner thread for delete outdated unmerged > accounts etc). > > - If "trustEmail" flag is on for IdentityProvider, the provider link > will be created automatically. (For example if Facebook user > bob at gmail.com authenticates for the first time and there is already > Keycloak user with email bob at gmail.com and trustEmail is on, the > Facebook link is automatically created for Keycloak account > bob at gmail.com without any additional verification) > > - If "trustEmail" flag is off, there would need to be other way to > verify user before creating social link. The user will first confirm if > he wants to merge the accounts. Then there will be either: > -- Email verification: The mail will be sent to bob at gmail.com like > "Someone authenticates to Keycloak server http://www.keycloak.org:8080 > through Facebook account bob at gmail.com and wants to link Facebook > account with existing Keycloak account bob at gmail.com . If it is you, > click here" . After user clicks, the social link is created > -- Further authentication: User will need to authenticate to existing > bob at gmail.com keycloak account through password (or OTP or both or > something else) > All of this is configurable through flows, so admin can disable the "Do > you want to create social link?" screen, or enforce email verification > instead of authentication, configure required authenticators etc. > > - I am not sure if we want to handle just merge with existing account > during first broker login, or if we also want to handle merging of > accounts in account management? For now, I am planning to handle just > the login flow and possibly address Account management later if there is > need for it. The merging accounts in account management might be quite a > challenge as there is merge of 2 already existing user accounts with > various issues related to it (Which roles/permissions should merged > account have? Which attributes it should have? Which federation link? > etc.). But at least, I am planning to address the issue with redirect to > login forms error screen instead of stay in account management - > https://issues.jboss.org/browse/KEYCLOAK-1822 > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From giulio.vito.demusso at gmail.com Tue Oct 27 10:09:37 2015 From: giulio.vito.demusso at gmail.com (Giulio Vito de Musso) Date: Tue, 27 Oct 2015 15:09:37 +0100 Subject: [keycloak-dev] Trying to use Admin WS but got 401 Unauthorized Message-ID: Hello you all, I need to configure realms in Keycloak through the Admin WS accessible at the path http://KeycloakServer:8081/auth/admin/realms So in Postman I run the following request URL: http://KeycloakServer:8081/auth/admin/realms Method: POST Body: { "enabled": true, "id": "TestRealm", } I get a 401 Unauthorized response, so I think it is necessary to authenticate to the Admin WS. But in the docs I cannot find any information about the type of authentication required and the syntax. Do you know how to authenticate to the Keycloak WSs? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151027/cea0c248/attachment-0001.html From sthorger at redhat.com Tue Oct 27 10:58:33 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 27 Oct 2015 07:58:33 -0700 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: <562F5F80.2050107@redhat.com> References: <562DD90E.6010405@redhat.com> <562E2666.6080700@redhat.com> <562F5F80.2050107@redhat.com> Message-ID: Integration tests have many disguises, some are good others are bad. As Keycloak is not a framework or set of libraries, but a ready to use service it's a lot more important that we test the real thing than test individual bits and pieces. I agree it wouldn't hurt to have unit tests as well, but they are generally a pain to maintain. Especially if you want to refactor something. Mocks make things even worse in that regard. Personally I see unit tests and mocks more as a great development tool than actual quality assurance. End of the day what you care about is that your login page and your rest services behaves as expected there's just no need for unit tests. On 27 October 2015 at 04:26, Stan Silvert wrote: > You should never use mocks again. I elaborated on this topic in Bill's > blog several years ago and he wrote a followup article: > http://bill.burkecentral.com/2012/05/01/mocks-are-a-mockery/ > > > On 10/27/2015 4:41 AM, Andrzej Go?awski wrote: > > "For example for federation, you need realm and user DB and you need to > have realm configured with federation Provider" > > In such cases you can use mocks, stubs and object factories. > > "There is not much you can test within single module" > > IMHO there are still few things which would be nice to test. Look at the > first class in the module LDAP Config for example. There are few comments > suggesting refactoring it in the feature. I find refactoring single class > or classes with heavy integration test painful and insufficient. Look at > spring framework code. There are plenty of small unit tests which test only > one thing so that it is really well tested as a whole! I think good testing > is especially important in case of open source - where everybody adds some > code. For instance me :) For me LDAP it is a new topic, but I would like to > add some code to this part ... so I expect to make o a lot of mistakes :D > "Btv. what's your plan for KEYCLOAK-1797" > And now the hardest part :) As I said, I'm new in this topic (LDAP) so I > decided to wrap my head around it for a while - can you reccommend me any > reading materials suitable for beginners? > > "And in your LDAP environment, is it often that new role is added as > member to some other roles?" > > No .. but it is critical in my company. > > "I wonder if we need to always do "deep" search in runtime, or if we can > instead do it just at some point and rely on Keycloak composite roles . If > you always need deep search and do something based on it, it will be good > to have a flag in configuration, which will allow to disable it (for > performance reasons)." > > Thank you for the hint :) I couldn't agree more. > > Best regards, > > Andrzej > > 2015-10-26 14:11 GMT+01:00 Marek Posolda : > >> We prefer integration tests as you usually need more things to have >> available. For example for federation, you need realm and user DB and you >> need to have realm configured with federationProvider. There is not much >> you can test within single module, so we have just very simple tests in >> individual modules (like LDAPDnTest or PasswordPolicyTest), but most of the >> stuff is tested in testsuite. For KEYCLOAK-1797 I prefer to take a look at LDAPRoleMappingsTest >> and possibly add new test methods here. >> >> Btv. what's your plan for KEYCLOAK-1797 ? And in your LDAP environment, >> is it often that new role is added as member to some other roles? I wonder >> if we need to always do "deep" search in runtime, or if we can instead do >> it just at some point and rely on Keycloak composite roles . If you always >> need deep search and do something based on it, it will be good to have a >> flag in configuration, which will allow to disable it (for performance >> reasons). >> >> Marek >> >> On 26/10/15 08:55, Andrzej Go?awski wrote: >> >> Hi Marek, >> >> Thanks for reply! >> I saw those test, but personally I prefer unit tests over integrated >> tests:) >> I really recommend this: https://vimeo.com/80533536 >> >> Best Regards, >> Andrzej >> >> 2015-10-26 8:41 GMT+01:00 Marek Posolda : >> >>> Hi, >>> >>> most of the tests are in the testsuite/integration or >>> testsuite/integration-arquillian, not in the modules itself. For the >>> federation and ldap, you can take a look especially to package >>> org.keycloak.testsuite.federation . >>> >>> Marek >>> >>> On 25/10/15 21:51, Andrzej Go?awski wrote: >>> >>> Hi everyone! >>> >>> I decided to implement KEYCLOAK-1797 and started to look at the code >>> (federation/ldap). I noticed lack of unit tests without which refactoring >>> may be very error prone. I like writing test so I can write tests for that >>> part. What are you thinking about it?? >>> >>> Best Regards, >>> Andrzej >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >> >> > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151027/2cdb8a50/attachment.html From mposolda at redhat.com Tue Oct 27 11:04:38 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 27 Oct 2015 16:04:38 +0100 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: <562F7693.80805@redhat.com> References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> Message-ID: <562F9286.5020205@redhat.com> On 27/10/15 14:05, Bill Burke wrote: > IMO, most applications will not care about account duplication. Most > users won't care about account linking. So, IMO: Remember you mentioned that already in the previous discussions. IMO people care and usually want to have single account on single site. If you have 2 accounts, you never know to which of your accounts you are authenticated. This causes various issues, like permissions available to account1, but you are logged with account2 etc. Remember some time ago I messed on some site and have 2 accounts like "mposolda" and "mposolda at redhat.com" . I had always issues like that when I was logged as "mposolda" I had "Access denied" when going to page I was supposed to have permission. So needed to logout and login again as "mposolda at redhat.com" etc. > > 1) users should not be required to link accounts. In the case where an > account cannot be automatically linked a duplicate account should be > created > 2) Providers should be trusted by default. Trusted providers can just > automatically link themselves to existing accounts that were logged in > by other trusted providers. > 3) Untrusted providers can automatically link if email has been verified > for all parties. > 4) Users can merge accounts that have verified emails. > 5) An alternative to user self merging of account could be requiring to > enter in a temporary code after logging into each account. > > > #1 and #2 can be added with minimal changes to code. #3 requires a flow > on broker login and a rework of the broker SPI. #4 is account service > changes. #5 might be as easy as adding a required action. > > I guess it depends if ultimate flexibility is needed. #1, #2 and #4 > might be enough and require the least amount of changes and SPI refactoring. I think that flexibility is needed based on various JIRAs and feedback. Just talked with Vlasta Elias from jboss.org. They have even more requirements for possible conditions when accounts should be merged and how to merge accounts. For example Vlasta mentioned the usecase like: - When user logges with Facebook (or other provider) account, which is not yet linked to any Keycloak account, then new account on Keycloak side shouldn't be created automatically. Even if I logged with Facebook bob at gmail.com and there is no KC account for email bob at gmail.com, there is requirement to always show the screen like: "You just logged with facebook account bob at gmail.com. Do you want to link it with existing keycloak account?" If user agree, he would need to provide Keycloak account he wants to merge and then verify email or re-authenticate to link Facebook with existing account - Another use-case was to merge account automatically based on username from thirdparty SAML provider. For example the SAMLResponse with username "john" returned from SAML provider, there is a need to automatically merge it with Keycloak account "john" . In this case, they know that "john" will be always available on Keycloak side because of Federation provider, which SAML IDP uses as storage as well. Based on all of this, it looks that introducing Auth SPI for first time broker login is a way to go. This will address all of #1, #2 and #3 and many other usecases. For your #2, I agree that providers should be trusted by default. But not all of providers, because some of them don't verify email. AFAIK Facebook and Google verify email. But Github doesn't . It will be a security hole to trust github provider by default because then user can do something like: - He can create github account with any email he wants like "mposolda at redhat.com" - Login with this github account into Keycloak. If we trust the email by default, he will be logged into Keycloak to account "mposolda at redhat.com", which is not his email -> FAIL I am not sure about support for merging accounts in Account management (like #4 and #5), will try to work on login flow first and will try to possibly look at account management then. Marek > > > On 10/27/2015 4:33 AM, Marek Posolda wrote: >> I went again through all the previous discussions, related JIRAs and >> requirements. As of now, my plan is to: >> >> - Use authentication SPI to handle the flow and related actions for >> first social login. (Update user profile, Detect duplicated account, >> Verify email or reauthenticate user if duplication is detected, Create >> social link to existing account). This allows most flexibility for >> admins to specify how exactly the linking should work >> >> - Detecting duplication will be based on email only by default - (For >> example duplication is detected if Facebook user with email >> bob at gmail.com authenticates, but there is already Keycloak user with >> email bob at gmail.com ). The people can provide their own execution if >> they want different way for detect duplications >> >> - It seems it's more proper to postpone creating user account later, >> once we know that there is no duplication. In other words, if "Update >> profile on first login" is enabled, the user account is not yet created >> when the update profile page is shown. All the info related to >> BrokeredIdentityContext stuff will be available on ClientSession. This >> seems to me easier and more proper solution then creating temporary >> account with email in some "temporary" attribute. Temporary accounts >> have other challenges (Cleaner thread for delete outdated unmerged >> accounts etc). >> >> - If "trustEmail" flag is on for IdentityProvider, the provider link >> will be created automatically. (For example if Facebook user >> bob at gmail.com authenticates for the first time and there is already >> Keycloak user with email bob at gmail.com and trustEmail is on, the >> Facebook link is automatically created for Keycloak account >> bob at gmail.com without any additional verification) >> >> - If "trustEmail" flag is off, there would need to be other way to >> verify user before creating social link. The user will first confirm if >> he wants to merge the accounts. Then there will be either: >> -- Email verification: The mail will be sent to bob at gmail.com like >> "Someone authenticates to Keycloak server http://www.keycloak.org:8080 >> through Facebook account bob at gmail.com and wants to link Facebook >> account with existing Keycloak account bob at gmail.com . If it is you, >> click here" . After user clicks, the social link is created >> -- Further authentication: User will need to authenticate to existing >> bob at gmail.com keycloak account through password (or OTP or both or >> something else) >> All of this is configurable through flows, so admin can disable the "Do >> you want to create social link?" screen, or enforce email verification >> instead of authentication, configure required authenticators etc. >> >> - I am not sure if we want to handle just merge with existing account >> during first broker login, or if we also want to handle merging of >> accounts in account management? For now, I am planning to handle just >> the login flow and possibly address Account management later if there is >> need for it. The merging accounts in account management might be quite a >> challenge as there is merge of 2 already existing user accounts with >> various issues related to it (Which roles/permissions should merged >> account have? Which attributes it should have? Which federation link? >> etc.). But at least, I am planning to address the issue with redirect to >> login forms error screen instead of stay in account management - >> https://issues.jboss.org/browse/KEYCLOAK-1822 >> >> Marek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From sthorger at redhat.com Tue Oct 27 12:40:19 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 27 Oct 2015 09:40:19 -0700 Subject: [keycloak-dev] Keycloak 1.6.1.Final Released Message-ID: We've just released Keycloak 1.6.1.Final. After releasing 1.6.0.Final we discovered some issues with migration that has been resolved in this release. There's also a fix to a medium security issue that was introduced in 1.6.0.Final. For the full list of issues resolved check out JIRA and to download the release go to the Keycloak homepage . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151027/4ee00d66/attachment-0001.html From andipansa at gmail.com Tue Oct 27 16:41:24 2015 From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=) Date: Tue, 27 Oct 2015 21:41:24 +0100 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: References: <562DD90E.6010405@redhat.com> <562E2666.6080700@redhat.com> <562F5F80.2050107@redhat.com> Message-ID: Thanks for your response and an interesting article! @Stan Generally I agree with your opinion about Mockacks (people definitely tend to overuse them and confuse them with Stubs) though I wouldn't "scratch them off menu" completely because of that. I find equalization between unit and integration tests rather controvertial. E.g. It's hard to imagine TDD with tests demanding full context, new condition of system and hitting the database each time. In my opinion a well done unit test is characterized by the following: 1. has only one reason to fail; 2. is independent of other tests - so that it may be launched in parallel with them; 3. last but not least - it's fast - which is critical for TDD! I love Arquillian from the first sight (I use it to do integration test) but I would never use it to unit tests. Of course, you're invited to make me change my mind. :) @Stian "I agree it wouldn't hurt to have unit tests as well, but they are generally a pain to maintain" In the subject of problems with maintaining tests I recommend you to listen to a lecture given by my friend - about tricky things in TDD. It's available here: https://vimeo.com/120572733 "Mocks make things even worse in that regard." Come on, don't be obsessed with these Mocks! :P I shouldn't have mentioned about it? ;) "Personally I see unit tests and mocks more as a great development tool than actual quality assurance" Well, I think that if the unit tests have helped you to write a good working code than it's just another proof of their reliability? ;) "End of the day what you care about is that your login page and your rest services behaves as expected there's just no need for unit tests" Buisness value. :) Personally, I'm fully satisfied with my work only if the code I've written is clean and well tested. Furthermore, I prefer clean, tested but not error-free code than working one, which is embroiled and unclear. Best regards, Andrzej 2015-10-27 15:58 GMT+01:00 Stian Thorgersen : > Integration tests have many disguises, some are good others are bad. As > Keycloak is not a framework or set of libraries, but a ready to use service > it's a lot more important that we test the real thing than test individual > bits and pieces. > > I agree it wouldn't hurt to have unit tests as well, but they are > generally a pain to maintain. Especially if you want to refactor something. > Mocks make things even worse in that regard. Personally I see unit tests > and mocks more as a great development tool than actual quality assurance. > End of the day what you care about is that your login page and your rest > services behaves as expected there's just no need for unit tests. > > On 27 October 2015 at 04:26, Stan Silvert wrote: > >> You should never use mocks again. I elaborated on this topic in Bill's >> blog several years ago and he wrote a followup article: >> http://bill.burkecentral.com/2012/05/01/mocks-are-a-mockery/ >> >> >> On 10/27/2015 4:41 AM, Andrzej Go?awski wrote: >> >> "For example for federation, you need realm and user DB and you need to >> have realm configured with federation Provider" >> >> In such cases you can use mocks, stubs and object factories. >> >> "There is not much you can test within single module" >> >> IMHO there are still few things which would be nice to test. Look at the >> first class in the module LDAP Config for example. There are few comments >> suggesting refactoring it in the feature. I find refactoring single class >> or classes with heavy integration test painful and insufficient. Look at >> spring framework code. There are plenty of small unit tests which test only >> one thing so that it is really well tested as a whole! I think good testing >> is especially important in case of open source - where everybody adds some >> code. For instance me :) For me LDAP it is a new topic, but I would like to >> add some code to this part ... so I expect to make o a lot of mistakes :D >> "Btv. what's your plan for KEYCLOAK-1797" >> And now the hardest part :) As I said, I'm new in this topic (LDAP) so I >> decided to wrap my head around it for a while - can you reccommend me any >> reading materials suitable for beginners? >> >> "And in your LDAP environment, is it often that new role is added as >> member to some other roles?" >> >> No .. but it is critical in my company. >> >> "I wonder if we need to always do "deep" search in runtime, or if we can >> instead do it just at some point and rely on Keycloak composite roles . If >> you always need deep search and do something based on it, it will be good >> to have a flag in configuration, which will allow to disable it (for >> performance reasons)." >> >> Thank you for the hint :) I couldn't agree more. >> >> Best regards, >> >> Andrzej >> >> 2015-10-26 14:11 GMT+01:00 Marek Posolda : >> >>> We prefer integration tests as you usually need more things to have >>> available. For example for federation, you need realm and user DB and you >>> need to have realm configured with federationProvider. There is not much >>> you can test within single module, so we have just very simple tests in >>> individual modules (like LDAPDnTest or PasswordPolicyTest), but most of the >>> stuff is tested in testsuite. For KEYCLOAK-1797 I prefer to take a look at LDAPRoleMappingsTest >>> and possibly add new test methods here. >>> >>> Btv. what's your plan for KEYCLOAK-1797 ? And in your LDAP environment, >>> is it often that new role is added as member to some other roles? I wonder >>> if we need to always do "deep" search in runtime, or if we can instead do >>> it just at some point and rely on Keycloak composite roles . If you always >>> need deep search and do something based on it, it will be good to have a >>> flag in configuration, which will allow to disable it (for performance >>> reasons). >>> >>> Marek >>> >>> On 26/10/15 08:55, Andrzej Go?awski wrote: >>> >>> Hi Marek, >>> >>> Thanks for reply! >>> I saw those test, but personally I prefer unit tests over integrated >>> tests:) >>> I really recommend this: https://vimeo.com/80533536 >>> >>> Best Regards, >>> Andrzej >>> >>> 2015-10-26 8:41 GMT+01:00 Marek Posolda : >>> >>>> Hi, >>>> >>>> most of the tests are in the testsuite/integration or >>>> testsuite/integration-arquillian, not in the modules itself. For the >>>> federation and ldap, you can take a look especially to package >>>> org.keycloak.testsuite.federation . >>>> >>>> Marek >>>> >>>> On 25/10/15 21:51, Andrzej Go?awski wrote: >>>> >>>> Hi everyone! >>>> >>>> I decided to implement KEYCLOAK-1797 and started to look at the code >>>> (federation/ldap). I noticed lack of unit tests without which refactoring >>>> may be very error prone. I like writing test so I can write tests for that >>>> part. What are you thinking about it?? >>>> >>>> Best Regards, >>>> Andrzej >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>> >>> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151027/46d7108d/attachment.html From mposolda at redhat.com Tue Oct 27 17:11:39 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 27 Oct 2015 22:11:39 +0100 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: References: <562DD90E.6010405@redhat.com> <562E2666.6080700@redhat.com> Message-ID: <562FE88B.8060406@redhat.com> On 27/10/15 09:41, Andrzej Go?awski wrote: > "For example for federation, you need realm and user DB and you need > to have realm configured with federation Provider" > > In such cases you can use mocks, stubs and object factories. > > "There is not much you can test within single module" > > IMHO there are still few things which would be nice to test. Look at > the first class in the module LDAP Config for example. There are few > comments suggesting refactoring it in the feature. I find refactoring > single class or classes with heavy integration test painful and > insufficient. Look at spring framework code. There are plenty of small > unit tests which test only one thing so that it is really well tested > as a whole! I think good testing is especially important in case of > open source - where everybody adds some code. For instance me :) For > me LDAP it is a new topic, but I would like to add some code to this > part ... so I expect to make o a lot of mistakes :D > "Btv. what's your plan for KEYCLOAK-1797" > And now the hardest part :) As I said, I'm new in this topic (LDAP) > so I decided to wrap my head around it for a while - can you > reccommend me any reading materials suitable for beginners? You can start with some generic Java + LDAP tutorial: https://docs.oracle.com/javase/tutorial/jndi/ops/index.html Then you can take a look at Keycloak Federation and LDAP documentation and to the code itself. And also I suggest to take a look at Keycloak composite roles. Personally I would like to avoid doing "deep" search at every request, but instead do the deep search just from time to time and use the keycloak composite roles. Method RoleLDAPFederationMapper.syncRolesFromLDAP is currently checking LDAP and it's syncing roles from LDAP into Keycloak DB. This method is not called at every request but just at some moments (For example during user's sync). This method can be extended to also do the "deep" search and assign composite roles to Keycloak based on LDAP memberships. In your example in JIRA, the role "Group1" wil be put as composite role of "Group1.1" in Keycloak DB. Then during normal user search, just the simple search is performed so just the LDAP role "Group1.1" is returned from the LDAP search as role of user TestUser. But Keycloak will treat the user to be member of role "Group1" as well because this role is composite role of "Group1.1" . So the final result is, that keycloak will treat "TestUser" to be member of both "Group1" and "Group1.1" . Thing is that Bill is actually working on adding Groups support to Keycloak and composite roles are going to be refactored or removed entirely and replaced by groups. So there is not very good time to introduce this feature now, but rather wait for 1.7 release once Group support is in. Is it ok for you to wait for 1.7 release? Marek > > "And in your LDAP environment, is it often that new role is added as > member to some other roles?" > > No .. but it is critical in my company. > > "I wonder if we need to always do "deep" search in runtime, or if we > can instead do it just at some point and rely on Keycloak composite > roles . If you always need deep search and do something based on it, > it will be good to have a flag in configuration, which will allow to > disable it (for performance reasons)." > > Thank you for the hint :) I couldn't agree more. > > Best regards, > > Andrzej > > 2015-10-26 14:11 GMT+01:00 Marek Posolda >: > > We prefer integration tests as you usually need more things to > have available. For example for federation, you need realm and > user DB and you need to have realm configured with > federationProvider. There is not much you can test within single > module, so we have just very simple tests in individual modules > (like LDAPDnTest or PasswordPolicyTest), but most of the stuff is > tested in testsuite. For KEYCLOAK-1797 I prefer to take a look at > LDAPRoleMappingsTest and possibly add new test methods here. > > Btv. what's your plan for KEYCLOAK-1797 ? And in your LDAP > environment, is it often that new role is added as member to some > other roles? I wonder if we need to always do "deep" search in > runtime, or if we can instead do it just at some point and rely on > Keycloak composite roles . If you always need deep search and do > something based on it, it will be good to have a flag in > configuration, which will allow to disable it (for performance > reasons). > > Marek > > On 26/10/15 08:55, Andrzej Go?awski wrote: >> Hi Marek, >> >> Thanks for reply! >> I saw those test, but personally I prefer unit tests over >> integrated tests:) >> I really recommend this: https://vimeo.com/80533536 >> >> Best Regards, >> Andrzej >> >> 2015-10-26 8:41 GMT+01:00 Marek Posolda > >: >> >> Hi, >> >> most of the tests are in the testsuite/integration or >> testsuite/integration-arquillian, not in the modules itself. >> For the federation and ldap, you can take a look especially >> to package org.keycloak.testsuite.federation . >> >> Marek >> >> On 25/10/15 21:51, Andrzej Go?awski wrote: >>> Hi everyone! >>> >>> I decided to implement KEYCLOAK-1797 and started to look at >>> the code (federation/ldap). I noticed lack of unit tests >>> without which refactoring may be very error prone. I like >>> writing test so I can write tests for that part. What are >>> you thinking about it?? >>> >>> Best Regards, >>> Andrzej >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151027/b5193159/attachment-0001.html From bburke at redhat.com Tue Oct 27 17:17:02 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 27 Oct 2015 17:17:02 -0400 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: References: <562DD90E.6010405@redhat.com> <562E2666.6080700@redhat.com> <562F5F80.2050107@redhat.com> Message-ID: <562FE9CE.6050903@redhat.com> On 10/27/2015 4:41 PM, Andrzej Go?awski wrote: > Thanks for your response and an interesting article! > > @Stan > Generally I agree with your opinion about Mockacks (people definitely > tend to overuse them and confuse them with Stubs) though I wouldn't > "scratch them off menu" completely because of that. > I find equalization between unit and integration tests rather > controvertial. E.g. It's hard to imagine TDD with tests demanding full > context, new condition of system and hitting the database each time. > > In my opinion a well done unit test is characterized by the following: > 1. has only one reason to fail; > 2. is independent of other tests - so that it may be launched in > parallel with them; > 3. last but not least - it's fast - which is critical for TDD! > As for point #3 its irrelevant how fast the unit tests are. We would not accept PRs that didn't pass our integration tests. Our main build would run the main integration testsuite. We're always happy to accept additional tests from the community. But as for the full time dev team, integration tests provide much bigger bang for the buck so we'll be focusing on them. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From andipansa at gmail.com Tue Oct 27 18:51:09 2015 From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=) Date: Tue, 27 Oct 2015 23:51:09 +0100 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: <562FE88B.8060406@redhat.com> References: <562DD90E.6010405@redhat.com> <562E2666.6080700@redhat.com> <562FE88B.8060406@redhat.com> Message-ID: Thank you for materials and lots of hints !! :) "Thing is that Bill is actually working on adding Groups support to Keycloak and composite roles are going to be refactored or removed entirely and replaced by groups" Does it gonna be done with one commit, or maybe there are some ready to use parts in the model? "Is it ok for you to wait for 1.7 release?" It will have to :) Best Regards, Andrzej 2015-10-27 22:11 GMT+01:00 Marek Posolda : > On 27/10/15 09:41, Andrzej Go?awski wrote: > > "For example for federation, you need realm and user DB and you need to > have realm configured with federation Provider" > > In such cases you can use mocks, stubs and object factories. > > "There is not much you can test within single module" > > IMHO there are still few things which would be nice to test. Look at the > first class in the module LDAP Config for example. There are few comments > suggesting refactoring it in the feature. I find refactoring single class > or classes with heavy integration test painful and insufficient. Look at > spring framework code. There are plenty of small unit tests which test only > one thing so that it is really well tested as a whole! I think good testing > is especially important in case of open source - where everybody adds some > code. For instance me :) For me LDAP it is a new topic, but I would like to > add some code to this part ... so I expect to make o a lot of mistakes :D > "Btv. what's your plan for KEYCLOAK-1797" > And now the hardest part :) As I said, I'm new in this topic (LDAP) so I > decided to wrap my head around it for a while - can you reccommend me any > reading materials suitable for beginners? > > You can start with some generic Java + LDAP tutorial: > https://docs.oracle.com/javase/tutorial/jndi/ops/index.html > > Then you can take a look at Keycloak Federation and LDAP documentation and > to the code itself. And also I suggest to take a look at Keycloak composite > roles. > > Personally I would like to avoid doing "deep" search at every request, but > instead do the deep search just from time to time and use the keycloak > composite roles. Method RoleLDAPFederationMapper.syncRolesFromLDAP is > currently checking LDAP and it's syncing roles from LDAP into Keycloak DB. > This method is not called at every request but just at some moments (For > example during user's sync). This method can be extended to also do the > "deep" search and assign composite roles to Keycloak based on LDAP > memberships. In your example in JIRA, the role "Group1" wil be put as > composite role of "Group1.1" in Keycloak DB. > > Then during normal user search, just the simple search is performed so > just the LDAP role "Group1.1" is returned from the LDAP search as role of > user TestUser. But Keycloak will treat the user to be member of role > "Group1" as well because this role is composite role of "Group1.1" . So the > final result is, that keycloak will treat "TestUser" to be member of both > "Group1" and "Group1.1" . > > Thing is that Bill is actually working on adding Groups support to > Keycloak and composite roles are going to be refactored or removed entirely > and replaced by groups. So there is not very good time to introduce this > feature now, but rather wait for 1.7 release once Group support is in. > > Is it ok for you to wait for 1.7 release? > > Marek > > > "And in your LDAP environment, is it often that new role is added as > member to some other roles?" > > No .. but it is critical in my company. > > "I wonder if we need to always do "deep" search in runtime, or if we can > instead do it just at some point and rely on Keycloak composite roles . If > you always need deep search and do something based on it, it will be good > to have a flag in configuration, which will allow to disable it (for > performance reasons)." > > Thank you for the hint :) I couldn't agree more. > > Best regards, > > Andrzej > > 2015-10-26 14:11 GMT+01:00 Marek Posolda : > >> We prefer integration tests as you usually need more things to have >> available. For example for federation, you need realm and user DB and you >> need to have realm configured with federationProvider. There is not much >> you can test within single module, so we have just very simple tests in >> individual modules (like LDAPDnTest or PasswordPolicyTest), but most of the >> stuff is tested in testsuite. For KEYCLOAK-1797 I prefer to take a look at LDAPRoleMappingsTest >> and possibly add new test methods here. >> >> Btv. what's your plan for KEYCLOAK-1797 ? And in your LDAP environment, >> is it often that new role is added as member to some other roles? I wonder >> if we need to always do "deep" search in runtime, or if we can instead do >> it just at some point and rely on Keycloak composite roles . If you always >> need deep search and do something based on it, it will be good to have a >> flag in configuration, which will allow to disable it (for performance >> reasons). >> >> Marek >> >> On 26/10/15 08:55, Andrzej Go?awski wrote: >> >> Hi Marek, >> >> Thanks for reply! >> I saw those test, but personally I prefer unit tests over integrated >> tests:) >> I really recommend this: >> https://vimeo.com/80533536 >> >> Best Regards, >> Andrzej >> >> 2015-10-26 8:41 GMT+01:00 Marek Posolda < >> mposolda at redhat.com>: >> >>> Hi, >>> >>> most of the tests are in the testsuite/integration or >>> testsuite/integration-arquillian, not in the modules itself. For the >>> federation and ldap, you can take a look especially to package >>> org.keycloak.testsuite.federation . >>> >>> Marek >>> >>> On 25/10/15 21:51, Andrzej Go?awski wrote: >>> >>> Hi everyone! >>> >>> I decided to implement KEYCLOAK-1797 and started to look at the code >>> (federation/ldap). I noticed lack of unit tests without which refactoring >>> may be very error prone. I like writing test so I can write tests for that >>> part. What are you thinking about it?? >>> >>> Best Regards, >>> Andrzej >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151027/f62013f0/attachment.html From sthorger at redhat.com Tue Oct 27 22:49:06 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 27 Oct 2015 19:49:06 -0700 Subject: [keycloak-dev] Trying to use Admin WS but got 401 Unauthorized In-Reply-To: References: Message-ID: You'll need a bearer token to invoke the services. A token can be obtained either using the direct grant (or resource owner password grant as oauth calls it) or using the standard web flow. Take a look at: https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java Or if you are invoking from Java, simply use our Java admin client lib: https://github.com/keycloak/keycloak/blob/master/examples/admin-client/src/main/webapp/index.jsp On 27 October 2015 at 07:09, Giulio Vito de Musso < giulio.vito.demusso at gmail.com> wrote: > > Hello you all, > > I need to configure realms in Keycloak through the Admin WS accessible at > the path > > http://KeycloakServer:8081/auth/admin/realms > > So in Postman I run the following request > > URL: http://KeycloakServer:8081/auth/admin/realms > > Method: POST > > Body: > > { > "enabled": true, > "id": "TestRealm", > } > > I get a 401 Unauthorized response, so I think it is necessary to > authenticate to the Admin WS. But in the docs I cannot find any information > about the type of authentication required and the syntax. Do you know how > to authenticate to the Keycloak WSs? > > Thank you > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151027/3405655e/attachment-0001.html From sthorger at redhat.com Tue Oct 27 22:59:21 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 27 Oct 2015 19:59:21 -0700 Subject: [keycloak-dev] [keycloak-user] Keycloak 1.6.1.Final Released In-Reply-To: References: Message-ID: There's an issue with the website at the moment so it's not updating itself correctly. Should be fixed soon, but in the mean time you can use http://keycloak.jboss.org/keycloak/downloads-archive.html?dir=0%3D1.6.1.Final%3B to download 1.6.1.Final. On 27 October 2015 at 10:22, Hristo Stoyanov wrote: > 1.6.1 still not showing on the web site for download? > > /Hristo Stoyanov > On Oct 27, 2015 9:41 AM, "Stian Thorgersen" wrote: > >> We've just released Keycloak 1.6.1.Final. After releasing 1.6.0.Final we >> discovered some issues with migration that has been resolved in this >> release. There's also a fix to a medium security issue that was introduced >> in 1.6.0.Final. >> >> For the full list of issues resolved check out JIRA >> and >> to download the release go to the Keycloak homepage >> . >> >> _______________________________________________ >> 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-dev/attachments/20151027/a74ebca7/attachment.html From giulio.vito.demusso at gmail.com Wed Oct 28 09:17:17 2015 From: giulio.vito.demusso at gmail.com (Giulio Vito de Musso) Date: Wed, 28 Oct 2015 14:17:17 +0100 Subject: [keycloak-dev] Trying to use Admin WS but got 401 Unauthorized In-Reply-To: References: Message-ID: Hi Stian, all, Reading your first link I can see that the URL to call to get a token is http:/auth/realms/{realm-name}/protocol/openid-connect/token" But what is the realm-name to use? I'm trying to execute an operation which is above all realms (which is create a new realm posting the JSON) Moreover I should provide a client_id in the request body, but I don't know which client ID to use. Thanks Giulio 2015-10-28 3:49 GMT+01:00 Stian Thorgersen : > You'll need a bearer token to invoke the services. A token can be obtained > either using the direct grant (or resource owner password grant as oauth > calls it) or using the standard web flow. > > Take a look at: > > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java > > Or if you are invoking from Java, simply use our Java admin client lib: > > https://github.com/keycloak/keycloak/blob/master/examples/admin-client/src/main/webapp/index.jsp > > On 27 October 2015 at 07:09, Giulio Vito de Musso < > giulio.vito.demusso at gmail.com> wrote: > >> >> Hello you all, >> >> I need to configure realms in Keycloak through the Admin WS accessible at >> the path >> >> http://KeycloakServer:8081/auth/admin/realms >> >> So in Postman I run the following request >> >> URL: http://KeycloakServer:8081/auth/admin/realms >> >> Method: POST >> >> Body: >> >> { >> "enabled": true, >> "id": "TestRealm", >> } >> >> I get a 401 Unauthorized response, so I think it is necessary to >> authenticate to the Admin WS. But in the docs I cannot find any information >> about the type of authentication required and the syntax. Do you know how >> to authenticate to the Keycloak WSs? >> >> Thank you >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151028/48b74f8e/attachment.html From gerbermichi at me.com Wed Oct 28 10:53:22 2015 From: gerbermichi at me.com (Michael Gerber) Date: Wed, 28 Oct 2015 14:53:22 +0000 (GMT) Subject: [keycloak-dev] username guessing Message-ID: Hi all, it is possible to guess the username of disabled users.? This was not possible in earlier versions of keycloak.?Is this on purpose? Best Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151028/33692bc9/attachment.html From sthorger at redhat.com Wed Oct 28 10:54:48 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 28 Oct 2015 07:54:48 -0700 Subject: [keycloak-dev] Trying to use Admin WS but got 401 Unauthorized In-Reply-To: References: Message-ID: You should use the master realm as it permits access to all realms as well as creating realms. Create a client ;) On 28 October 2015 at 06:17, Giulio Vito de Musso < giulio.vito.demusso at gmail.com> wrote: > Hi Stian, all, > > Reading your first link I can see that the URL to call to get a token is > > http:/auth/realms/{realm-name}/protocol/openid-connect/token > " > > But what is the realm-name to use? I'm trying to execute an operation > which is above all realms (which is create a new realm posting the JSON) > > Moreover I should provide a client_id in the request body, but I don't > know which client ID to use. > > Thanks > Giulio > > > 2015-10-28 3:49 GMT+01:00 Stian Thorgersen : > >> You'll need a bearer token to invoke the services. A token can be >> obtained either using the direct grant (or resource owner password grant as >> oauth calls it) or using the standard web flow. >> >> Take a look at: >> >> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java >> >> Or if you are invoking from Java, simply use our Java admin client lib: >> >> https://github.com/keycloak/keycloak/blob/master/examples/admin-client/src/main/webapp/index.jsp >> >> On 27 October 2015 at 07:09, Giulio Vito de Musso < >> giulio.vito.demusso at gmail.com> wrote: >> >>> >>> Hello you all, >>> >>> I need to configure realms in Keycloak through the Admin WS accessible >>> at the path >>> >>> http://KeycloakServer:8081/auth/admin/realms >>> >>> So in Postman I run the following request >>> >>> URL: http://KeycloakServer:8081/auth/admin/realms >>> >>> Method: POST >>> >>> Body: >>> >>> { >>> "enabled": true, >>> "id": "TestRealm", >>> } >>> >>> I get a 401 Unauthorized response, so I think it is necessary to >>> authenticate to the Admin WS. But in the docs I cannot find any information >>> about the type of authentication required and the syntax. Do you know how >>> to authenticate to the Keycloak WSs? >>> >>> Thank you >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151028/f4f9f6ea/attachment-0001.html From sthorger at redhat.com Wed Oct 28 10:55:35 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 28 Oct 2015 07:55:35 -0700 Subject: [keycloak-dev] username guessing In-Reply-To: References: Message-ID: No, that's a bug On 28 October 2015 at 07:53, Michael Gerber wrote: > Hi all, > > it is possible to guess the username of disabled users. > This was not possible in earlier versions of keycloak. Is this on purpose? > > Best > Michael > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151028/7dd94e73/attachment.html From sthorger at redhat.com Wed Oct 28 11:06:47 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 28 Oct 2015 08:06:47 -0700 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: <562F9286.5020205@redhat.com> References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> Message-ID: I'm quite concerned about auto linking accounts. If someone has loads of social networks enabled and a user has a single of those compromised (that happens quite frequently) the attackers would then also be able to gain access to whatever Keycloak secures. The user wouldn't even know they have access to Keycloak, since the user has never used to compromised account to login to Keycloak. I strongly feel we should never link to any account without requiring user to first authenticate to the account we are linking with. On 27 October 2015 at 08:04, Marek Posolda wrote: > On 27/10/15 14:05, Bill Burke wrote: > > IMO, most applications will not care about account duplication. Most > > users won't care about account linking. So, IMO: > Remember you mentioned that already in the previous discussions. IMO > people care and usually want to have single account on single site. If > you have 2 accounts, you never know to which of your accounts you are > authenticated. This causes various issues, like permissions available to > account1, but you are logged with account2 etc. > > Remember some time ago I messed on some site and have 2 accounts like > "mposolda" and "mposolda at redhat.com" . I had always issues like that > when I was logged as "mposolda" I had "Access denied" when going to page > I was supposed to have permission. So needed to logout and login again > as "mposolda at redhat.com" etc. > > > > 1) users should not be required to link accounts. In the case where an > > account cannot be automatically linked a duplicate account should be > > created > > 2) Providers should be trusted by default. Trusted providers can just > > automatically link themselves to existing accounts that were logged in > > by other trusted providers. > > 3) Untrusted providers can automatically link if email has been verified > > for all parties. > > 4) Users can merge accounts that have verified emails. > > 5) An alternative to user self merging of account could be requiring to > > enter in a temporary code after logging into each account. > > > > > > #1 and #2 can be added with minimal changes to code. #3 requires a flow > > on broker login and a rework of the broker SPI. #4 is account service > > changes. #5 might be as easy as adding a required action. > > > > I guess it depends if ultimate flexibility is needed. #1, #2 and #4 > > might be enough and require the least amount of changes and SPI > refactoring. > I think that flexibility is needed based on various JIRAs and feedback. > Just talked with Vlasta Elias from jboss.org. They have even more > requirements for possible conditions when accounts should be merged and > how to merge accounts. For example Vlasta mentioned the usecase like: > - When user logges with Facebook (or other provider) account, which is > not yet linked to any Keycloak account, then new account on Keycloak > side shouldn't be created automatically. Even if I logged with Facebook > bob at gmail.com and there is no KC account for email bob at gmail.com, there > is requirement to always show the screen like: "You just logged with > facebook account bob at gmail.com. Do you want to link it with existing > keycloak account?" If user agree, he would need to provide Keycloak > account he wants to merge and then verify email or re-authenticate to > link Facebook with existing account > > - Another use-case was to merge account automatically based on username > from thirdparty SAML provider. For example the SAMLResponse with > username "john" returned from SAML provider, there is a need to > automatically merge it with Keycloak account "john" . In this case, they > know that "john" will be always available on Keycloak side because of > Federation provider, which SAML IDP uses as storage as well. > > Based on all of this, it looks that introducing Auth SPI for first time > broker login is a way to go. This will address all of #1, #2 and #3 and > many other usecases. > > For your #2, I agree that providers should be trusted by default. But > not all of providers, because some of them don't verify email. AFAIK > Facebook and Google verify email. But Github doesn't . It will be a > security hole to trust github provider by default because then user can > do something like: > - He can create github account with any email he wants like > "mposolda at redhat.com" > - Login with this github account into Keycloak. If we trust the email by > default, he will be logged into Keycloak to account > "mposolda at redhat.com", which is not his email -> FAIL > > I am not sure about support for merging accounts in Account management > (like #4 and #5), will try to work on login flow first and will try to > possibly look at account management then. > > Marek > > > > > > On 10/27/2015 4:33 AM, Marek Posolda wrote: > >> I went again through all the previous discussions, related JIRAs and > >> requirements. As of now, my plan is to: > >> > >> - Use authentication SPI to handle the flow and related actions for > >> first social login. (Update user profile, Detect duplicated account, > >> Verify email or reauthenticate user if duplication is detected, Create > >> social link to existing account). This allows most flexibility for > >> admins to specify how exactly the linking should work > >> > >> - Detecting duplication will be based on email only by default - (For > >> example duplication is detected if Facebook user with email > >> bob at gmail.com authenticates, but there is already Keycloak user with > >> email bob at gmail.com ). The people can provide their own execution if > >> they want different way for detect duplications > >> > >> - It seems it's more proper to postpone creating user account later, > >> once we know that there is no duplication. In other words, if "Update > >> profile on first login" is enabled, the user account is not yet created > >> when the update profile page is shown. All the info related to > >> BrokeredIdentityContext stuff will be available on ClientSession. This > >> seems to me easier and more proper solution then creating temporary > >> account with email in some "temporary" attribute. Temporary accounts > >> have other challenges (Cleaner thread for delete outdated unmerged > >> accounts etc). > >> > >> - If "trustEmail" flag is on for IdentityProvider, the provider link > >> will be created automatically. (For example if Facebook user > >> bob at gmail.com authenticates for the first time and there is already > >> Keycloak user with email bob at gmail.com and trustEmail is on, the > >> Facebook link is automatically created for Keycloak account > >> bob at gmail.com without any additional verification) > >> > >> - If "trustEmail" flag is off, there would need to be other way to > >> verify user before creating social link. The user will first confirm if > >> he wants to merge the accounts. Then there will be either: > >> -- Email verification: The mail will be sent to bob at gmail.com like > >> "Someone authenticates to Keycloak server http://www.keycloak.org:8080 > >> through Facebook account bob at gmail.com and wants to link Facebook > >> account with existing Keycloak account bob at gmail.com . If it is you, > >> click here" . After user clicks, the social link is created > >> -- Further authentication: User will need to authenticate to existing > >> bob at gmail.com keycloak account through password (or OTP or both or > >> something else) > >> All of this is configurable through flows, so admin can disable the "Do > >> you want to create social link?" screen, or enforce email verification > >> instead of authentication, configure required authenticators etc. > >> > >> - I am not sure if we want to handle just merge with existing account > >> during first broker login, or if we also want to handle merging of > >> accounts in account management? For now, I am planning to handle just > >> the login flow and possibly address Account management later if there is > >> need for it. The merging accounts in account management might be quite a > >> challenge as there is merge of 2 already existing user accounts with > >> various issues related to it (Which roles/permissions should merged > >> account have? Which attributes it should have? Which federation link? > >> etc.). But at least, I am planning to address the issue with redirect to > >> login forms error screen instead of stay in account management - > >> https://issues.jboss.org/browse/KEYCLOAK-1822 > >> > >> Marek > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151028/b6ce6052/attachment.html From Scott.Rehorn at software.dell.com Wed Oct 28 12:34:00 2015 From: Scott.Rehorn at software.dell.com (Scott Rehorn) Date: Wed, 28 Oct 2015 16:34:00 +0000 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> Message-ID: I agree with Stian here ? the process to normalize a collection of logins requires human-interaction nuance that should not be automated. I think Keycloak can provide a nice user experience to aid the process, but it should always be an interactive process with plenty of re-authentication challenges to make sure an individual still retains ownership of the various candidate linked accounts. From: > on behalf of Stian Thorgersen > Reply-To: "stian at redhat.com" > Date: Wednesday, October 28, 2015 at 8:06 AM To: Marek Posolda > Cc: keycloak-dev > Subject: Re: [keycloak-dev] Plan for "First login with identity brokers" I'm quite concerned about auto linking accounts. If someone has loads of social networks enabled and a user has a single of those compromised (that happens quite frequently) the attackers would then also be able to gain access to whatever Keycloak secures. The user wouldn't even know they have access to Keycloak, since the user has never used to compromised account to login to Keycloak. I strongly feel we should never link to any account without requiring user to first authenticate to the account we are linking with. On 27 October 2015 at 08:04, Marek Posolda > wrote: On 27/10/15 14:05, Bill Burke wrote: > IMO, most applications will not care about account duplication. Most > users won't care about account linking. So, IMO: Remember you mentioned that already in the previous discussions. IMO people care and usually want to have single account on single site. If you have 2 accounts, you never know to which of your accounts you are authenticated. This causes various issues, like permissions available to account1, but you are logged with account2 etc. Remember some time ago I messed on some site and have 2 accounts like "mposolda" and "mposolda at redhat.com" . I had always issues like that when I was logged as "mposolda" I had "Access denied" when going to page I was supposed to have permission. So needed to logout and login again as "mposolda at redhat.com" etc. > > 1) users should not be required to link accounts. In the case where an > account cannot be automatically linked a duplicate account should be > created > 2) Providers should be trusted by default. Trusted providers can just > automatically link themselves to existing accounts that were logged in > by other trusted providers. > 3) Untrusted providers can automatically link if email has been verified > for all parties. > 4) Users can merge accounts that have verified emails. > 5) An alternative to user self merging of account could be requiring to > enter in a temporary code after logging into each account. > > > #1 and #2 can be added with minimal changes to code. #3 requires a flow > on broker login and a rework of the broker SPI. #4 is account service > changes. #5 might be as easy as adding a required action. > > I guess it depends if ultimate flexibility is needed. #1, #2 and #4 > might be enough and require the least amount of changes and SPI refactoring. I think that flexibility is needed based on various JIRAs and feedback. Just talked with Vlasta Elias from jboss.org. They have even more requirements for possible conditions when accounts should be merged and how to merge accounts. For example Vlasta mentioned the usecase like: - When user logges with Facebook (or other provider) account, which is not yet linked to any Keycloak account, then new account on Keycloak side shouldn't be created automatically. Even if I logged with Facebook bob at gmail.com and there is no KC account for email bob at gmail.com, there is requirement to always show the screen like: "You just logged with facebook account bob at gmail.com. Do you want to link it with existing keycloak account?" If user agree, he would need to provide Keycloak account he wants to merge and then verify email or re-authenticate to link Facebook with existing account - Another use-case was to merge account automatically based on username from thirdparty SAML provider. For example the SAMLResponse with username "john" returned from SAML provider, there is a need to automatically merge it with Keycloak account "john" . In this case, they know that "john" will be always available on Keycloak side because of Federation provider, which SAML IDP uses as storage as well. Based on all of this, it looks that introducing Auth SPI for first time broker login is a way to go. This will address all of #1, #2 and #3 and many other usecases. For your #2, I agree that providers should be trusted by default. But not all of providers, because some of them don't verify email. AFAIK Facebook and Google verify email. But Github doesn't . It will be a security hole to trust github provider by default because then user can do something like: - He can create github account with any email he wants like "mposolda at redhat.com" - Login with this github account into Keycloak. If we trust the email by default, he will be logged into Keycloak to account "mposolda at redhat.com", which is not his email -> FAIL I am not sure about support for merging accounts in Account management (like #4 and #5), will try to work on login flow first and will try to possibly look at account management then. Marek > > > On 10/27/2015 4:33 AM, Marek Posolda wrote: >> I went again through all the previous discussions, related JIRAs and >> requirements. As of now, my plan is to: >> >> - Use authentication SPI to handle the flow and related actions for >> first social login. (Update user profile, Detect duplicated account, >> Verify email or reauthenticate user if duplication is detected, Create >> social link to existing account). This allows most flexibility for >> admins to specify how exactly the linking should work >> >> - Detecting duplication will be based on email only by default - (For >> example duplication is detected if Facebook user with email >> bob at gmail.com authenticates, but there is already Keycloak user with >> email bob at gmail.com ). The people can provide their own execution if >> they want different way for detect duplications >> >> - It seems it's more proper to postpone creating user account later, >> once we know that there is no duplication. In other words, if "Update >> profile on first login" is enabled, the user account is not yet created >> when the update profile page is shown. All the info related to >> BrokeredIdentityContext stuff will be available on ClientSession. This >> seems to me easier and more proper solution then creating temporary >> account with email in some "temporary" attribute. Temporary accounts >> have other challenges (Cleaner thread for delete outdated unmerged >> accounts etc). >> >> - If "trustEmail" flag is on for IdentityProvider, the provider link >> will be created automatically. (For example if Facebook user >> bob at gmail.com authenticates for the first time and there is already >> Keycloak user with email bob at gmail.com and trustEmail is on, the >> Facebook link is automatically created for Keycloak account >> bob at gmail.com without any additional verification) >> >> - If "trustEmail" flag is off, there would need to be other way to >> verify user before creating social link. The user will first confirm if >> he wants to merge the accounts. Then there will be either: >> -- Email verification: The mail will be sent to bob at gmail.com like >> "Someone authenticates to Keycloak server http://www.keycloak.org:8080 >> through Facebook account bob at gmail.com and wants to link Facebook >> account with existing Keycloak account bob at gmail.com . If it is you, >> click here" . After user clicks, the social link is created >> -- Further authentication: User will need to authenticate to existing >> bob at gmail.com keycloak account through password (or OTP or both or >> something else) >> All of this is configurable through flows, so admin can disable the "Do >> you want to create social link?" screen, or enforce email verification >> instead of authentication, configure required authenticators etc. >> >> - I am not sure if we want to handle just merge with existing account >> during first broker login, or if we also want to handle merging of >> accounts in account management? For now, I am planning to handle just >> the login flow and possibly address Account management later if there is >> need for it. The merging accounts in account management might be quite a >> challenge as there is merge of 2 already existing user accounts with >> various issues related to it (Which roles/permissions should merged >> account have? Which attributes it should have? Which federation link? >> etc.). But at least, I am planning to address the issue with redirect to >> login forms error screen instead of stay in account management - >> https://issues.jboss.org/browse/KEYCLOAK-1822 >> >> Marek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151028/6786d917/attachment-0001.html From bloy at smartling.com Wed Oct 28 14:51:48 2015 From: bloy at smartling.com (Benjamin Loy) Date: Wed, 28 Oct 2015 18:51:48 +0000 Subject: [keycloak-dev] Adding a minimum TTL for token refreshes Message-ID: Hello all, We are using Keycloak in production and wanted to make a change to it to handle tokens that are about to expire. We have a number of services that rely on the bearer token sent from our web servers for authentication. Users will land on the web server, we verify their token is alive, and send the bearer token to a service. Our issue is sometimes the user has an extremely small amount of time left, the bearer token expires by the time we do the security checks on the services, and the request fails. We are considering adding a minimum TTL in RefreshableKeycloakSecurityContext that will refresh an active token if it has less than a configurable amount of time left before it expires. This will let us build a time window that will prevent the token from expiring when interacting with services under normal circumstances. Would you be interested in our work on this or have any interest to do this yourselves? I can create a Jira and a pull request if you want us to implement this feature. Thanks, Ben -- Benjamin Loy Senior Software Engineer bloy at smartling.com | o: (866) 707 6278 smartling.com | linkedIn | @smartling -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151028/891b54cf/attachment.html From bburke at redhat.com Wed Oct 28 15:50:16 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 28 Oct 2015 15:50:16 -0400 Subject: [keycloak-dev] username guessing In-Reply-To: References: Message-ID: <563126F8.7080600@redhat.com> How is this possible? On 10/28/2015 10:53 AM, Michael Gerber wrote: > Hi all, > > it is possible to guess the username of disabled users. > This was not possible in earlier versions of keycloak. Is this on purpose? > > Best > Michael > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Oct 28 16:32:27 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 28 Oct 2015 16:32:27 -0400 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> Message-ID: <563130DB.2090604@redhat.com> If a user has loads of social networks and links a bunch of them, if *any one* of them is compromised the entire account is compromised. Most sites using social login, the only reason is there is a login is for the appliation to collect marketing data. So, the default behavior should make things as simple as possible for the user. At a minimum, by default, the user should not be required to link an account if there is a conflicting duplicate email given by the provider. I have found develoeprs.redhat.com very difficult to use. On 10/28/2015 12:34 PM, Scott Rehorn wrote: > I agree with Stian here ? the process to normalize a collection of > logins requires human-interaction nuance that should not be automated. I > think Keycloak can provide a nice user experience to aid the process, > but it should always be an interactive process with plenty of > re-authentication challenges to make sure an individual still retains > ownership of the various candidate linked accounts. > > From: > on behalf of Stian > Thorgersen > > Reply-To: "stian at redhat.com " > > Date: Wednesday, October 28, 2015 at 8:06 AM > To: Marek Posolda > > Cc: keycloak-dev > > Subject: Re: [keycloak-dev] Plan for "First login with identity brokers" > > I'm quite concerned about auto linking accounts. If someone has loads of > social networks enabled and a user has a single of those compromised > (that happens quite frequently) the attackers would then also be able to > gain access to whatever Keycloak secures. The user wouldn't even know > they have access to Keycloak, since the user has never used to > compromised account to login to Keycloak. > > I strongly feel we should never link to any account without requiring > user to first authenticate to the account we are linking with. > > On 27 October 2015 at 08:04, Marek Posolda > wrote: > > On 27/10/15 14:05, Bill Burke wrote: > > IMO, most applications will not care about account duplication. Most > > users won't care about account linking. So, IMO: > Remember you mentioned that already in the previous discussions. IMO > people care and usually want to have single account on single site. If > you have 2 accounts, you never know to which of your accounts you are > authenticated. This causes various issues, like permissions available to > account1, but you are logged with account2 etc. > > Remember some time ago I messed on some site and have 2 accounts like > "mposolda" and "mposolda at redhat.com " . > I had always issues like that > when I was logged as "mposolda" I had "Access denied" when going to page > I was supposed to have permission. So needed to logout and login again > as "mposolda at redhat.com " etc. > > > > 1) users should not be required to link accounts. In the case where an > > account cannot be automatically linked a duplicate account should be > > created > > 2) Providers should be trusted by default. Trusted providers can just > > automatically link themselves to existing accounts that were logged in > > by other trusted providers. > > 3) Untrusted providers can automatically link if email has been verified > > for all parties. > > 4) Users can merge accounts that have verified emails. > > 5) An alternative to user self merging of account could be requiring to > > enter in a temporary code after logging into each account. > > > > > > #1 and #2 can be added with minimal changes to code. #3 requires a flow > > on broker login and a rework of the broker SPI. #4 is account service > > changes. #5 might be as easy as adding a required action. > > > > I guess it depends if ultimate flexibility is needed. #1, #2 and #4 > > might be enough and require the least amount of changes and SPI refactoring. > I think that flexibility is needed based on various JIRAs and feedback. > Just talked with Vlasta Elias from jboss.org . > They have even more > requirements for possible conditions when accounts should be merged and > how to merge accounts. For example Vlasta mentioned the usecase like: > - When user logges with Facebook (or other provider) account, which is > not yet linked to any Keycloak account, then new account on Keycloak > side shouldn't be created automatically. Even if I logged with Facebook > bob at gmail.com and there is no KC account for > email bob at gmail.com , there > is requirement to always show the screen like: "You just logged with > facebook account bob at gmail.com . Do you want > to link it with existing > keycloak account?" If user agree, he would need to provide Keycloak > account he wants to merge and then verify email or re-authenticate to > link Facebook with existing account > > - Another use-case was to merge account automatically based on username > from thirdparty SAML provider. For example the SAMLResponse with > username "john" returned from SAML provider, there is a need to > automatically merge it with Keycloak account "john" . In this case, they > know that "john" will be always available on Keycloak side because of > Federation provider, which SAML IDP uses as storage as well. > > Based on all of this, it looks that introducing Auth SPI for first time > broker login is a way to go. This will address all of #1, #2 and #3 and > many other usecases. > > For your #2, I agree that providers should be trusted by default. But > not all of providers, because some of them don't verify email. AFAIK > Facebook and Google verify email. But Github doesn't . It will be a > security hole to trust github provider by default because then user can > do something like: > - He can create github account with any email he wants like > "mposolda at redhat.com " > - Login with this github account into Keycloak. If we trust the email by > default, he will be logged into Keycloak to account > "mposolda at redhat.com ", which is not his > email -> FAIL > > I am not sure about support for merging accounts in Account management > (like #4 and #5), will try to work on login flow first and will try to > possibly look at account management then. > > Marek > > > > > > On 10/27/2015 4:33 AM, Marek Posolda wrote: > >> I went again through all the previous discussions, related JIRAs and > >> requirements. As of now, my plan is to: > >> > >> - Use authentication SPI to handle the flow and related actions for > >> first social login. (Update user profile, Detect duplicated account, > >> Verify email or reauthenticate user if duplication is detected, Create > >> social link to existing account). This allows most flexibility for > >> admins to specify how exactly the linking should work > >> > >> - Detecting duplication will be based on email only by default - (For > >> example duplication is detected if Facebook user with email > >>bob at gmail.com authenticates, but there is > already Keycloak user with > >> emailbob at gmail.com ). The people can provide their > own execution if > >> they want different way for detect duplications > >> > >> - It seems it's more proper to postpone creating user account later, > >> once we know that there is no duplication. In other words, if "Update > >> profile on first login" is enabled, the user account is not yet created > >> when the update profile page is shown. All the info related to > >> BrokeredIdentityContext stuff will be available on ClientSession. This > >> seems to me easier and more proper solution then creating temporary > >> account with email in some "temporary" attribute. Temporary accounts > >> have other challenges (Cleaner thread for delete outdated unmerged > >> accounts etc). > >> > >> - If "trustEmail" flag is on for IdentityProvider, the provider link > >> will be created automatically. (For example if Facebook user > >>bob at gmail.com authenticates for the first > time and there is already > >> Keycloak user with emailbob at gmail.com and trustEmail is on, the > >> Facebook link is automatically created for Keycloak account > >>bob at gmail.com without any additional > verification) > >> > >> - If "trustEmail" flag is off, there would need to be other way to > >> verify user before creating social link. The user will first confirm if > >> he wants to merge the accounts. Then there will be either: > >> -- Email verification: The mail will be sent tobob at gmail.com like > >> "Someone authenticates to Keycloak serverhttp://www.keycloak.org:8080 > >> through Facebook accountbob at gmail.com and wants to link Facebook > >> account with existing Keycloak accountbob at gmail.com . If it is you, > >> click here" . After user clicks, the social link is created > >> -- Further authentication: User will need to authenticate to existing > >>bob at gmail.com keycloak account through > password (or OTP or both or > >> something else) > >> All of this is configurable through flows, so admin can disable the "Do > >> you want to create social link?" screen, or enforce email verification > >> instead of authentication, configure required authenticators etc. > >> > >> - I am not sure if we want to handle just merge with existing account > >> during first broker login, or if we also want to handle merging of > >> accounts in account management? For now, I am planning to handle just > >> the login flow and possibly address Account management later if there is > >> need for it. The merging accounts in account management might be quite a > >> challenge as there is merge of 2 already existing user accounts with > >> various issues related to it (Which roles/permissions should merged > >> account have? Which attributes it should have? Which federation link? > >> etc.). But at least, I am planning to address the issue with redirect to > >> login forms error screen instead of stay in account management - > >>https://issues.jboss.org/browse/KEYCLOAK-1822 > >> > >> Marek > >> _______________________________________________ > >> keycloak-dev mailing list > >>keycloak-dev at lists.jboss.org > >>https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From gerbermichi at me.com Wed Oct 28 17:48:36 2015 From: gerbermichi at me.com (Michael Gerber) Date: Wed, 28 Oct 2015 22:48:36 +0100 Subject: [keycloak-dev] username guessing In-Reply-To: <563126F8.7080600@redhat.com> References: <563126F8.7080600@redhat.com> Message-ID: Just create a new user, disable it and try to log in with the username and a wrong password. And you will get the following error message: Account is disabled, contact admin. > On 28.10.2015, at 20:50, Bill Burke wrote: > > How is this possible? > > On 10/28/2015 10:53 AM, Michael Gerber wrote: >> Hi all, >> >> it is possible to guess the username of disabled users. >> This was not possible in earlier versions of keycloak. Is this on purpose? >> >> Best >> Michael >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From srossillo at smartling.com Wed Oct 28 18:44:07 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Wed, 28 Oct 2015 18:44:07 -0400 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: <563130DB.2090604@redhat.com> References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> <563130DB.2090604@redhat.com> Message-ID: <27E56C7A-FAEC-4114-AA48-5D79EEF374AB@smartling.com> It?s important to allow for account linking without a manual step if the trust email is true. I?m not against optionally forcing the user to link accounts. However, if the user never confirms they want to link, I?d want to identity broker account to never be created. Hope that makes sense. I know there are a lot of use cases you?re considering here but I?d rather not have to write code to maintain automatic account linking (with or without a verification step). Also, if user me at gmail.com is registered in Keycloak and then uses Google+ authentication, it would be silly to make the user confirm they want the accounts linked. Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On Oct 28, 2015, at 4:32 PM, Bill Burke wrote: > > If a user has loads of social networks and links a bunch of them, if > *any one* of them is compromised the entire account is compromised. > Most sites using social login, the only reason is there is a login is > for the appliation to collect marketing data. So, the default behavior > should make things as simple as possible for the user. > > At a minimum, by default, the user should not be required to link an > account if there is a conflicting duplicate email given by the provider. > I have found develoeprs.redhat.com very difficult to use. > > > > On 10/28/2015 12:34 PM, Scott Rehorn wrote: >> I agree with Stian here ? the process to normalize a collection of >> logins requires human-interaction nuance that should not be automated. I >> think Keycloak can provide a nice user experience to aid the process, >> but it should always be an interactive process with plenty of >> re-authentication challenges to make sure an individual still retains >> ownership of the various candidate linked accounts. >> >> From: > > on behalf of Stian >> Thorgersen > >> Reply-To: "stian at redhat.com " > > >> Date: Wednesday, October 28, 2015 at 8:06 AM >> To: Marek Posolda > >> Cc: keycloak-dev > > >> Subject: Re: [keycloak-dev] Plan for "First login with identity brokers" >> >> I'm quite concerned about auto linking accounts. If someone has loads of >> social networks enabled and a user has a single of those compromised >> (that happens quite frequently) the attackers would then also be able to >> gain access to whatever Keycloak secures. The user wouldn't even know >> they have access to Keycloak, since the user has never used to >> compromised account to login to Keycloak. >> >> I strongly feel we should never link to any account without requiring >> user to first authenticate to the account we are linking with. >> >> On 27 October 2015 at 08:04, Marek Posolda > > wrote: >> >> On 27/10/15 14:05, Bill Burke wrote: >>> IMO, most applications will not care about account duplication. Most >>> users won't care about account linking. So, IMO: >> Remember you mentioned that already in the previous discussions. IMO >> people care and usually want to have single account on single site. If >> you have 2 accounts, you never know to which of your accounts you are >> authenticated. This causes various issues, like permissions available to >> account1, but you are logged with account2 etc. >> >> Remember some time ago I messed on some site and have 2 accounts like >> "mposolda" and "mposolda at redhat.com " . >> I had always issues like that >> when I was logged as "mposolda" I had "Access denied" when going to page >> I was supposed to have permission. So needed to logout and login again >> as "mposolda at redhat.com " etc. >>> >>> 1) users should not be required to link accounts. In the case where an >>> account cannot be automatically linked a duplicate account should be >>> created >>> 2) Providers should be trusted by default. Trusted providers can just >>> automatically link themselves to existing accounts that were logged in >>> by other trusted providers. >>> 3) Untrusted providers can automatically link if email has been verified >>> for all parties. >>> 4) Users can merge accounts that have verified emails. >>> 5) An alternative to user self merging of account could be requiring to >>> enter in a temporary code after logging into each account. >>> >>> >>> #1 and #2 can be added with minimal changes to code. #3 requires a flow >>> on broker login and a rework of the broker SPI. #4 is account service >>> changes. #5 might be as easy as adding a required action. >>> >>> I guess it depends if ultimate flexibility is needed. #1, #2 and #4 >>> might be enough and require the least amount of changes and SPI refactoring. >> I think that flexibility is needed based on various JIRAs and feedback. >> Just talked with Vlasta Elias from jboss.org . >> They have even more >> requirements for possible conditions when accounts should be merged and >> how to merge accounts. For example Vlasta mentioned the usecase like: >> - When user logges with Facebook (or other provider) account, which is >> not yet linked to any Keycloak account, then new account on Keycloak >> side shouldn't be created automatically. Even if I logged with Facebook >> bob at gmail.com and there is no KC account for >> email bob at gmail.com , there >> is requirement to always show the screen like: "You just logged with >> facebook account bob at gmail.com . Do you want >> to link it with existing >> keycloak account?" If user agree, he would need to provide Keycloak >> account he wants to merge and then verify email or re-authenticate to >> link Facebook with existing account >> >> - Another use-case was to merge account automatically based on username >> from thirdparty SAML provider. For example the SAMLResponse with >> username "john" returned from SAML provider, there is a need to >> automatically merge it with Keycloak account "john" . In this case, they >> know that "john" will be always available on Keycloak side because of >> Federation provider, which SAML IDP uses as storage as well. >> >> Based on all of this, it looks that introducing Auth SPI for first time >> broker login is a way to go. This will address all of #1, #2 and #3 and >> many other usecases. >> >> For your #2, I agree that providers should be trusted by default. But >> not all of providers, because some of them don't verify email. AFAIK >> Facebook and Google verify email. But Github doesn't . It will be a >> security hole to trust github provider by default because then user can >> do something like: >> - He can create github account with any email he wants like >> "mposolda at redhat.com " >> - Login with this github account into Keycloak. If we trust the email by >> default, he will be logged into Keycloak to account >> "mposolda at redhat.com ", which is not his >> email -> FAIL >> >> I am not sure about support for merging accounts in Account management >> (like #4 and #5), will try to work on login flow first and will try to >> possibly look at account management then. >> >> Marek >>> >>> >>> On 10/27/2015 4:33 AM, Marek Posolda wrote: >>>> I went again through all the previous discussions, related JIRAs and >>>> requirements. As of now, my plan is to: >>>> >>>> - Use authentication SPI to handle the flow and related actions for >>>> first social login. (Update user profile, Detect duplicated account, >>>> Verify email or reauthenticate user if duplication is detected, Create >>>> social link to existing account). This allows most flexibility for >>>> admins to specify how exactly the linking should work >>>> >>>> - Detecting duplication will be based on email only by default - (For >>>> example duplication is detected if Facebook user with email >>>> bob at gmail.com authenticates, but there is >> already Keycloak user with >>>> emailbob at gmail.com ). The people can provide their >> own execution if >>>> they want different way for detect duplications >>>> >>>> - It seems it's more proper to postpone creating user account later, >>>> once we know that there is no duplication. In other words, if "Update >>>> profile on first login" is enabled, the user account is not yet created >>>> when the update profile page is shown. All the info related to >>>> BrokeredIdentityContext stuff will be available on ClientSession. This >>>> seems to me easier and more proper solution then creating temporary >>>> account with email in some "temporary" attribute. Temporary accounts >>>> have other challenges (Cleaner thread for delete outdated unmerged >>>> accounts etc). >>>> >>>> - If "trustEmail" flag is on for IdentityProvider, the provider link >>>> will be created automatically. (For example if Facebook user >>>> bob at gmail.com authenticates for the first >> time and there is already >>>> Keycloak user with emailbob at gmail.com and trustEmail is on, the >>>> Facebook link is automatically created for Keycloak account >>>> bob at gmail.com without any additional >> verification) >>>> >>>> - If "trustEmail" flag is off, there would need to be other way to >>>> verify user before creating social link. The user will first confirm if >>>> he wants to merge the accounts. Then there will be either: >>>> -- Email verification: The mail will be sent tobob at gmail.com like >>>> "Someone authenticates to Keycloak serverhttp://www.keycloak.org:8080 >>>> through Facebook accountbob at gmail.com and wants to link Facebook >>>> account with existing Keycloak accountbob at gmail.com . If it is you, >>>> click here" . After user clicks, the social link is created >>>> -- Further authentication: User will need to authenticate to existing >>>> bob at gmail.com keycloak account through >> password (or OTP or both or >>>> something else) >>>> All of this is configurable through flows, so admin can disable the "Do >>>> you want to create social link?" screen, or enforce email verification >>>> instead of authentication, configure required authenticators etc. >>>> >>>> - I am not sure if we want to handle just merge with existing account >>>> during first broker login, or if we also want to handle merging of >>>> accounts in account management? For now, I am planning to handle just >>>> the login flow and possibly address Account management later if there is >>>> need for it. The merging accounts in account management might be quite a >>>> challenge as there is merge of 2 already existing user accounts with >>>> various issues related to it (Which roles/permissions should merged >>>> account have? Which attributes it should have? Which federation link? >>>> etc.). But at least, I am planning to address the issue with redirect to >>>> login forms error screen instead of stay in account management - >>>> https://issues.jboss.org/browse/KEYCLOAK-1822 >>>> >>>> Marek >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151028/d25c9282/attachment-0001.html From bburke at redhat.com Wed Oct 28 19:42:47 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 28 Oct 2015 19:42:47 -0400 Subject: [keycloak-dev] username guessing In-Reply-To: References: <563126F8.7080600@redhat.com> Message-ID: <56315D77.2030408@redhat.com> Hmmm...IIRC I kept that there because, if the account is disabled how would the user ever know? This is even more important with a temporarily disabled account. On 10/28/2015 5:48 PM, Michael Gerber wrote: > Just create a new user, disable it and try to log in with the username and a wrong password. > And you will get the following error message: > Account is disabled, contact admin. > > >> On 28.10.2015, at 20:50, Bill Burke wrote: >> >> How is this possible? >> >> On 10/28/2015 10:53 AM, Michael Gerber wrote: >>> Hi all, >>> >>> it is possible to guess the username of disabled users. >>> This was not possible in earlier versions of keycloak. Is this on purpose? >>> >>> Best >>> Michael >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From gerbermichi at me.com Thu Oct 29 02:14:05 2015 From: gerbermichi at me.com (Michael Gerber) Date: Thu, 29 Oct 2015 07:14:05 +0100 Subject: [keycloak-dev] username guessing In-Reply-To: <56315D77.2030408@redhat.com> References: <563126F8.7080600@redhat.com> <56315D77.2030408@redhat.com> Message-ID: <11CF2BBE-E875-4246-9064-8C9354E470BB@me.com> You showed in the passt the correct error message only if the user has entered the correct password. In other words, you can split the userValidation into a pre and post validation, so you have the possibility to show sensitive messages only to authenticated users. > Am 29.10.2015 um 00:42 schrieb Bill Burke : > > Hmmm...IIRC I kept that there because, if the account is disabled how would the user ever know? This is even more important with a temporarily disabled account. > >> On 10/28/2015 5:48 PM, Michael Gerber wrote: >> Just create a new user, disable it and try to log in with the username and a wrong password. >> And you will get the following error message: >> Account is disabled, contact admin. >> >> >>> On 28.10.2015, at 20:50, Bill Burke wrote: >>> >>> How is this possible? >>> >>>> On 10/28/2015 10:53 AM, Michael Gerber wrote: >>>> Hi all, >>>> >>>> it is possible to guess the username of disabled users. >>>> This was not possible in earlier versions of keycloak. Is this on purpose? >>>> >>>> Best >>>> Michael >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com From mposolda at redhat.com Thu Oct 29 03:37:53 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 29 Oct 2015 08:37:53 +0100 Subject: [keycloak-dev] Keycloak - unit tests In-Reply-To: References: <562DD90E.6010405@redhat.com> <562E2666.6080700@redhat.com> <562FE88B.8060406@redhat.com> Message-ID: <5631CCD1.6060700@redhat.com> On 27/10/15 23:51, Andrzej Go?awski wrote: > Thank you for materials and lots of hints !! :) > > "Thing is that Bill is actually working on adding Groups support to > Keycloak and composite roles are going to be refactored or removed > entirely and replaced by groups" > Does it gonna be done with one commit, or maybe there are some ready > to use parts in the model? AFAIK 1.7 with the ready to use Groups support should be around end of November or start of December. So I would rather wait for it, because if we do something regarding KEYCLOAK-1797 now, it would likely need to be rewritten later. Marek > > "Is it ok for you to wait for 1.7 release?" > It will have to :) > > Best Regards, > Andrzej > > 2015-10-27 22:11 GMT+01:00 Marek Posolda >: > > On 27/10/15 09:41, Andrzej Go?awski wrote: >> "For example for federation, you need realm and user DB and you >> need to have realm configured with federation Provider" >> >> In such cases you can use mocks, stubs and object factories. >> >> "There is not much you can test within single module" >> >> IMHO there are still few things which would be nice to test. Look >> at the first class in the module LDAP Config for example. There >> are few comments suggesting refactoring it in the feature. I find >> refactoring single class or classes with heavy integration test >> painful and insufficient. Look at spring framework code. There >> are plenty of small unit tests which test only one thing so that >> it is really well tested as a whole! I think good testing is >> especially important in case of open source - where everybody >> adds some code. For instance me :) For me LDAP it is a new topic, >> but I would like to add some code to this part ... so I expect to >> make o a lot of mistakes :D >> "Btv. what's your plan for KEYCLOAK-1797" >> And now the hardest part :) As I said, I'm new in this topic >> (LDAP) so I decided to wrap my head around it for a while - can >> you reccommend me any reading materials suitable for beginners? > You can start with some generic Java + LDAP tutorial: > https://docs.oracle.com/javase/tutorial/jndi/ops/index.html > > Then you can take a look at Keycloak Federation and LDAP > documentation and to the code itself. And also I suggest to take a > look at Keycloak composite roles. > > Personally I would like to avoid doing "deep" search at every > request, but instead do the deep search just from time to time and > use the keycloak composite roles. Method > RoleLDAPFederationMapper.syncRolesFromLDAP is currently checking > LDAP and it's syncing roles from LDAP into Keycloak DB. This > method is not called at every request but just at some moments > (For example during user's sync). This method can be extended to > also do the "deep" search and assign composite roles to Keycloak > based on LDAP memberships. In your example in JIRA, the role > "Group1" wil be put as composite role of "Group1.1" in Keycloak DB. > > Then during normal user search, just the simple search is > performed so just the LDAP role "Group1.1" is returned from the > LDAP search as role of user TestUser. But Keycloak will treat the > user to be member of role "Group1" as well because this role is > composite role of "Group1.1" . So the final result is, that > keycloak will treat "TestUser" to be member of both "Group1" and > "Group1.1" . > > Thing is that Bill is actually working on adding Groups support to > Keycloak and composite roles are going to be refactored or removed > entirely and replaced by groups. So there is not very good time to > introduce this feature now, but rather wait for 1.7 release once > Group support is in. > > Is it ok for you to wait for 1.7 release? > > Marek >> >> "And in your LDAP environment, is it often that new role is added >> as member to some other roles?" >> >> No .. but it is critical in my company. >> >> "I wonder if we need to always do "deep" search in runtime, or if >> we can instead do it just at some point and rely on Keycloak >> composite roles . If you always need deep search and do something >> based on it, it will be good to have a flag in configuration, >> which will allow to disable it (for performance reasons)." >> >> Thank you for the hint :) I couldn't agree more. >> >> Best regards, >> >> Andrzej >> >> 2015-10-26 14:11 GMT+01:00 Marek Posolda > >: >> >> We prefer integration tests as you usually need more things >> to have available. For example for federation, you need realm >> and user DB and you need to have realm configured with >> federationProvider. There is not much you can test within >> single module, so we have just very simple tests in >> individual modules (like LDAPDnTest or PasswordPolicyTest), >> but most of the stuff is tested in testsuite. For >> KEYCLOAK-1797 I prefer to take a look at LDAPRoleMappingsTest >> and possibly add new test methods here. >> >> Btv. what's your plan for KEYCLOAK-1797 ? And in your LDAP >> environment, is it often that new role is added as member to >> some other roles? I wonder if we need to always do "deep" >> search in runtime, or if we can instead do it just at some >> point and rely on Keycloak composite roles . If you always >> need deep search and do something based on it, it will be >> good to have a flag in configuration, which will allow to >> disable it (for performance reasons). >> >> Marek >> >> On 26/10/15 08:55, Andrzej Go?awski wrote: >>> Hi Marek, >>> >>> Thanks for reply! >>> I saw those test, but personally I prefer unit tests over >>> integrated tests:) >>> I really recommend this: https://vimeo.com/80533536 >>> >>> Best Regards, >>> Andrzej >>> >>> 2015-10-26 8:41 GMT+01:00 Marek Posolda >> >: >>> >>> Hi, >>> https://www.linkedin.com/comm/profile/view?id=AAsAAAIX5nMBKyxtfQeuzKzJrFFz_psQoQwK6og&midToken=AQF7PTojMnRaJA&trk=eml-network_updates_digest-network_profile_updates-9-otherprofile%7Eprof&trkEmail=eml-network_updates_digest-network_profile_updates-9-otherprofile%7Eprof-null-4x6itt%7Eig9h49l1%7E1n >>> most of the tests are in the testsuite/integration or >>> testsuite/integration-arquillian, not in the modules >>> itself. For the federation and ldap, you can take a look >>> especially to package org.keycloak.testsuite.federation . >>> >>> Marek >>> >>> On 25/10/15 21:51, Andrzej Go?awski wrote: >>>> Hi everyone! >>>> >>>> I decided to implement KEYCLOAK-1797 and started to >>>> look at the code (federation/ldap). I noticed lack of >>>> unit tests without which refactoring may be very error >>>> prone. I like writing test so I can write tests for >>>> that part. What are you thinking about it?? >>>> >>>> Best Regards, >>>> Andrzej >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151029/98c6bb7d/attachment-0001.html From mposolda at redhat.com Thu Oct 29 04:05:41 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 29 Oct 2015 09:05:41 +0100 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: <27E56C7A-FAEC-4114-AA48-5D79EEF374AB@smartling.com> References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> <563130DB.2090604@redhat.com> <27E56C7A-FAEC-4114-AA48-5D79EEF374AB@smartling.com> Message-ID: <5631D355.6000402@redhat.com> On 28/10/15 23:44, Scott Rossillo wrote: > It?s important to allow for account linking without a manual step if > the trust email is true. I?m not against optionally forcing the user > to link accounts. However, if the user never confirms they want to > link, I?d want to identity broker account to never be created. > > Hope that makes sense. I know there are a lot of use cases you?re > considering here but I?d rather not have to write code to maintain > automatic account linking (with or without a verification step) > > Also, if user me at gmail.com is registered in > Keycloak and then uses Google+ authentication, it would be silly to > make the user confirm they want the accounts linked. With the authentication flows, it's possible to do things very flexible. However the question is what should be the default behaviour. I think we will have the possibility to "autolink" without additional verification/reauthentication, but it won't be likely enabled by default. As Stian mentioned, there is some security impact with autolinking even for trusted providers like Google. Marek > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > > Powered by Sigstr > >> On Oct 28, 2015, at 4:32 PM, Bill Burke > > wrote: >> >> If a user has loads of social networks and links a bunch of them, if >> *any one* of them is compromised the entire account is compromised. >> Most sites using social login, the only reason is there is a login is >> for the appliation to collect marketing data. So, the default behavior >> should make things as simple as possible for the user. >> >> At a minimum, by default, the user should not be required to link an >> account if there is a conflicting duplicate email given by the provider. >> I have found develoeprs.redhat.com >> very difficult to use. >> >> >> >> On 10/28/2015 12:34 PM, Scott Rehorn wrote: >>> I agree with Stian here ? the process to normalize a collection of >>> logins requires human-interaction nuance that should not be automated. I >>> think Keycloak can provide a nice user experience to aid the process, >>> but it should always be an interactive process with plenty of >>> re-authentication challenges to make sure an individual still retains >>> ownership of the various candidate linked accounts. >>> >>> From: >> >>> > on behalf of Stian >>> Thorgersen >>> > >>> Reply-To: "stian at redhat.com >>> " >>> > >>> Date: Wednesday, October 28, 2015 at 8:06 AM >>> To: Marek Posolda >>> > >>> Cc: keycloak-dev >> >>> > >>> Subject: Re: [keycloak-dev] Plan for "First login with identity brokers" >>> >>> I'm quite concerned about auto linking accounts. If someone has loads of >>> social networks enabled and a user has a single of those compromised >>> (that happens quite frequently) the attackers would then also be able to >>> gain access to whatever Keycloak secures. The user wouldn't even know >>> they have access to Keycloak, since the user has never used to >>> compromised account to login to Keycloak. >>> >>> I strongly feel we should never link to any account without requiring >>> user to first authenticate to the account we are linking with. >>> >>> On 27 October 2015 at 08:04, Marek Posolda >> >>> > wrote: >>> >>> On 27/10/15 14:05, Bill Burke wrote: >>>> IMO, most applications will not care about account duplication. Most >>>> users won't care about account linking. So, IMO: >>> Remember you mentioned that already in the previous discussions. IMO >>> people care and usually want to have single account on single >>> site. If >>> you have 2 accounts, you never know to which of your accounts you are >>> authenticated. This causes various issues, like permissions >>> available to >>> account1, but you are logged with account2 etc. >>> >>> Remember some time ago I messed on some site and have 2 accounts like >>> "mposolda" and "mposolda at redhat.com >>> " . >>> I had always issues like that >>> when I was logged as "mposolda" I had "Access denied" when going >>> to page >>> I was supposed to have permission. So needed to logout and login >>> again >>> as "mposolda at redhat.com >>> " etc. >>>> >>>> 1) users should not be required to link accounts. In the case where an >>>> account cannot be automatically linked a duplicate account should be >>>> created >>>> 2) Providers should be trusted by default. Trusted providers can just >>>> automatically link themselves to existing accounts that were logged in >>>> by other trusted providers. >>>> 3) Untrusted providers can automatically link if email has been >>>> verified >>>> for all parties. >>>> 4) Users can merge accounts that have verified emails. >>>> 5) An alternative to user self merging of account could be requiring to >>>> enter in a temporary code after logging into each account. >>>> >>>> >>>> #1 and #2 can be added with minimal changes to code. #3 requires a >>>> flow >>>> on broker login and a rework of the broker SPI. #4 is account service >>>> changes. #5 might be as easy as adding a required action. >>>> >>>> I guess it depends if ultimate flexibility is needed. #1, #2 and #4 >>>> might be enough and require the least amount of changes and SPI >>>> refactoring. >>> I think that flexibility is needed based on various JIRAs and >>> feedback. >>> Just talked with Vlasta Elias from jboss.org >>> . >>> They have even more >>> requirements for possible conditions when accounts should be >>> merged and >>> how to merge accounts. For example Vlasta mentioned the usecase like: >>> - When user logges with Facebook (or other provider) account, >>> which is >>> not yet linked to any Keycloak account, then new account on Keycloak >>> side shouldn't be created automatically. Even if I logged with >>> Facebook >>> bob at gmail.com and >>> there is no KC account for >>> email bob at gmail.com >>> , there >>> is requirement to always show the screen like: "You just logged with >>> facebook account bob at gmail.com >>> . Do you want >>> to link it with existing >>> keycloak account?" If user agree, he would need to provide Keycloak >>> account he wants to merge and then verify email or re-authenticate to >>> link Facebook with existing account >>> >>> - Another use-case was to merge account automatically based on >>> username >>> from thirdparty SAML provider. For example the SAMLResponse with >>> username "john" returned from SAML provider, there is a need to >>> automatically merge it with Keycloak account "john" . In this >>> case, they >>> know that "john" will be always available on Keycloak side because of >>> Federation provider, which SAML IDP uses as storage as well. >>> >>> Based on all of this, it looks that introducing Auth SPI for >>> first time >>> broker login is a way to go. This will address all of #1, #2 and >>> #3 and >>> many other usecases. >>> >>> For your #2, I agree that providers should be trusted by default. But >>> not all of providers, because some of them don't verify email. AFAIK >>> Facebook and Google verify email. But Github doesn't . It will be a >>> security hole to trust github provider by default because then >>> user can >>> do something like: >>> - He can create github account with any email he wants like >>> "mposolda at redhat.com >>> " >>> - Login with this github account into Keycloak. If we trust the >>> email by >>> default, he will be logged into Keycloak to account >>> "mposolda at redhat.com >>> ", which is not his >>> email -> FAIL >>> >>> I am not sure about support for merging accounts in Account >>> management >>> (like #4 and #5), will try to work on login flow first and will >>> try to >>> possibly look at account management then. >>> >>> Marek >>>> >>>> >>>> On 10/27/2015 4:33 AM, Marek Posolda wrote: >>>>> I went again through all the previous discussions, related JIRAs and >>>>> requirements. As of now, my plan is to: >>>>> >>>>> - Use authentication SPI to handle the flow and related actions for >>>>> first social login. (Update user profile, Detect duplicated account, >>>>> Verify email or reauthenticate user if duplication is detected, Create >>>>> social link to existing account). This allows most flexibility for >>>>> admins to specify how exactly the linking should work >>>>> >>>>> - Detecting duplication will be based on email only by default - (For >>>>> example duplication is detected if Facebook user with email >>>>> bob at gmail.com >>>>> authenticates, but there is >>> already Keycloak user with >>>>> emailbob at gmail.com >>>>> ). The people can provide their >>> own execution if >>>>> they want different way for detect duplications >>>>> >>>>> - It seems it's more proper to postpone creating user account later, >>>>> once we know that there is no duplication. In other words, if "Update >>>>> profile on first login" is enabled, the user account is not yet >>>>> created >>>>> when the update profile page is shown. All the info related to >>>>> BrokeredIdentityContext stuff will be available on ClientSession. This >>>>> seems to me easier and more proper solution then creating temporary >>>>> account with email in some "temporary" attribute. Temporary accounts >>>>> have other challenges (Cleaner thread for delete outdated unmerged >>>>> accounts etc). >>>>> >>>>> - If "trustEmail" flag is on for IdentityProvider, the provider link >>>>> will be created automatically. (For example if Facebook user >>>>> bob at gmail.com >>>>> authenticates for the first >>> time and there is already >>>>> Keycloak user with emailbob at gmail.com >>>>> and trustEmail is on, the >>>>> Facebook link is automatically created for Keycloak account >>>>> bob at gmail.com >>>>> without any additional >>> verification) >>>>> >>>>> - If "trustEmail" flag is off, there would need to be other way to >>>>> verify user before creating social link. The user will first >>>>> confirm if >>>>> he wants to merge the accounts. Then there will be either: >>>>> -- Email verification: The mail will be sent tobob at gmail.com >>>>> like >>>>> "Someone authenticates to Keycloak serverhttp://www.keycloak.org:8080 >>>>> through Facebook accountbob at gmail.com >>>>> and wants to >>>>> link Facebook >>>>> account with existing Keycloak accountbob at gmail.com >>>>> . If it is you, >>>>> click here" . After user clicks, the social link is created >>>>> -- Further authentication: User will need to authenticate to existing >>>>> bob at gmail.com >>>>> keycloak account through >>> password (or OTP or both or >>>>> realms/rhd/login-actions/email-verification?code=KYxAcXLs140rGN8CwQFtQssOj2es7aZBa6DrbbdGHng.822f5fb1-e05b-4e17-bb90-e6bbb8fba68esomething >>>>> else) >>>>> All of this is configurable through flows, so admin can disable >>>>> the "Do >>>>> you want to create social link?" screen, or enforce email verification >>>>> instead of authentication, configure required authenticators etc. >>>>> >>>>> - I am not sure if we want to handle just merge with existing account >>>>> during first broker login, or if we also want to handle merging of >>>>> accounts in account management? For now, I am planning to handle just >>>>> the login flow and possibly address Account management later if >>>>> there is >>>>> need for it. The merging accounts in account management might be >>>>> quite a >>>>> challenge as there is merge of 2 already existing user accounts with >>>>> various issues related to it (Which roles/permissions should merged >>>>> account have? Which attributes it should have? Which federation link? >>>>> etc.). But at least, I am planning to address the issue with >>>>> redirect to >>>>> login forms error screen instead of stay in account management - >>>>> https://issues.jboss.org/browse/KEYCLOAK-1822 >>>>> >>>>> Marek >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151029/0a743933/attachment-0001.html From mposolda at redhat.com Thu Oct 29 04:11:08 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 29 Oct 2015 09:11:08 +0100 Subject: [keycloak-dev] Adding a minimum TTL for token refreshes In-Reply-To: References: Message-ID: <5631D49C.4050003@redhat.com> +1 for this. I might have already created JIRA some months ago, but not sure. If you don't found, create your own JIRA. Our javascript adapter keycloak.js already has support for this (method "update" in keycloak.js), but java adapters don't have it. Looks we may need to add the new option on adapter config ( keycloak.js ) for this. Not sure what should be it's default value, 5 seconds? Marek On 28/10/15 19:51, Benjamin Loy wrote: > Hello all, > > We are using Keycloak in production and wanted to make a change to it > to handle tokens that are about to expire. We have a number of > services that rely on the bearer token sent from our web servers for > authentication. Users will land on the web server, we verify their > token is alive, and send the bearer token to a service. Our issue is > sometimes the user has an extremely small amount of time left, the > bearer token expires by the time we do the security checks on the > services, and the request fails. > > We are considering adding a minimum TTL > in RefreshableKeycloakSecurityContext that will refresh an active > token if it has less than a configurable amount of time left before it > expires. This will let us build a time window that will prevent the > token from expiring when interacting with services under normal > circumstances. > > Would you be interested in our work on this or have any interest to do > this yourselves? I can create a Jira and a pull request if you want > us to implement this feature. > > Thanks, > > Ben > > > -- > > Benjamin Loy > > Senior Software Engineer > > bloy at smartling.com | o: (866) 707 6278 > > smartling.com | linkedIn| @smartling > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151029/83cf1949/attachment.html From mposolda at redhat.com Thu Oct 29 04:13:45 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 29 Oct 2015 09:13:45 +0100 Subject: [keycloak-dev] Adding a minimum TTL for token refreshes In-Reply-To: <5631D49C.4050003@redhat.com> References: <5631D49C.4050003@redhat.com> Message-ID: <5631D539.6070603@redhat.com> On 29/10/15 09:11, Marek Posolda wrote: > +1 for this. I might have already created JIRA some months ago, but > not sure. If you don't found, create your own JIRA. > > Our javascript adapter keycloak.js already has support for this > (method "update" in keycloak.js), but java adapters don't have it. > > Looks we may need to add the new option on adapter config ( > keycloak.js ) for this. Not sure what should be it's default value, 5 > seconds? Sorry, i meant keycloak.json in the last sentence about adapter config. Marek > > Marek > > > On 28/10/15 19:51, Benjamin Loy wrote: >> Hello all, >> >> We are using Keycloak in production and wanted to make a change to it >> to handle tokens that are about to expire. We have a number of >> services that rely on the bearer token sent from our web servers for >> authentication. Users will land on the web server, we verify their >> token is alive, and send the bearer token to a service. Our issue >> is sometimes the user has an extremely small amount of time left, the >> bearer token expires by the time we do the security checks on the >> services, and the request fails. >> >> We are considering adding a minimum TTL >> in RefreshableKeycloakSecurityContext that will refresh an active >> token if it has less than a configurable amount of time left before >> it expires. This will let us build a time window that will prevent >> the token from expiring when interacting with services under normal >> circumstances. >> >> Would you be interested in our work on this or have any interest to >> do this yourselves? I can create a Jira and a pull request if you >> want us to implement this feature. >> >> Thanks, >> >> Ben >> >> >> -- >> >> Benjamin Loy >> >> Senior Software Engineer >> >> bloy at smartling.com | o: (866) 707 6278 >> >> smartling.com | linkedIn| @smartling >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151029/39a24210/attachment.html From velias at redhat.com Thu Oct 29 05:42:18 2015 From: velias at redhat.com (Vlastimil Elias) Date: Thu, 29 Oct 2015 10:42:18 +0100 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: <563130DB.2090604@redhat.com> References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> <563130DB.2090604@redhat.com> Message-ID: <5631E9FA.1050302@redhat.com> On 28.10.2015 21:32, Bill Burke wrote: > If a user has loads of social networks and links a bunch of them, if > *any one* of them is compromised the entire account is compromised. > Most sites using social login, the only reason is there is a login is > for the appliation to collect marketing data. So, the default behavior > should make things as simple as possible for the user. > > At a minimum, by default, the user should not be required to link an > account if there is a conflicting duplicate email given by the provider. > I have found develoeprs.redhat.com very difficult to use. yep, it is difficult to use because it have to follow company's policy with unique emails and Keycloak do not provide necessary support for simple and user friendly account linking currently ;-) Vl. > > > On 10/28/2015 12:34 PM, Scott Rehorn wrote: >> I agree with Stian here ? the process to normalize a collection of >> logins requires human-interaction nuance that should not be automated. I >> think Keycloak can provide a nice user experience to aid the process, >> but it should always be an interactive process with plenty of >> re-authentication challenges to make sure an individual still retains >> ownership of the various candidate linked accounts. >> >> From: > > on behalf of Stian >> Thorgersen > >> Reply-To: "stian at redhat.com " > > >> Date: Wednesday, October 28, 2015 at 8:06 AM >> To: Marek Posolda > >> Cc: keycloak-dev > > >> Subject: Re: [keycloak-dev] Plan for "First login with identity brokers" >> >> I'm quite concerned about auto linking accounts. If someone has loads of >> social networks enabled and a user has a single of those compromised >> (that happens quite frequently) the attackers would then also be able to >> gain access to whatever Keycloak secures. The user wouldn't even know >> they have access to Keycloak, since the user has never used to >> compromised account to login to Keycloak. >> >> I strongly feel we should never link to any account without requiring >> user to first authenticate to the account we are linking with. >> >> On 27 October 2015 at 08:04, Marek Posolda > > wrote: >> >> On 27/10/15 14:05, Bill Burke wrote: >> > IMO, most applications will not care about account duplication. Most >> > users won't care about account linking. So, IMO: >> Remember you mentioned that already in the previous discussions. IMO >> people care and usually want to have single account on single site. If >> you have 2 accounts, you never know to which of your accounts you are >> authenticated. This causes various issues, like permissions available to >> account1, but you are logged with account2 etc. >> >> Remember some time ago I messed on some site and have 2 accounts like >> "mposolda" and "mposolda at redhat.com " . >> I had always issues like that >> when I was logged as "mposolda" I had "Access denied" when going to page >> I was supposed to have permission. So needed to logout and login again >> as "mposolda at redhat.com " etc. >> > >> > 1) users should not be required to link accounts. In the case where an >> > account cannot be automatically linked a duplicate account should be >> > created >> > 2) Providers should be trusted by default. Trusted providers can just >> > automatically link themselves to existing accounts that were logged in >> > by other trusted providers. >> > 3) Untrusted providers can automatically link if email has been verified >> > for all parties. >> > 4) Users can merge accounts that have verified emails. >> > 5) An alternative to user self merging of account could be requiring to >> > enter in a temporary code after logging into each account. >> > >> > >> > #1 and #2 can be added with minimal changes to code. #3 requires a flow >> > on broker login and a rework of the broker SPI. #4 is account service >> > changes. #5 might be as easy as adding a required action. >> > >> > I guess it depends if ultimate flexibility is needed. #1, #2 and #4 >> > might be enough and require the least amount of changes and SPI refactoring. >> I think that flexibility is needed based on various JIRAs and feedback. >> Just talked with Vlasta Elias from jboss.org . >> They have even more >> requirements for possible conditions when accounts should be merged and >> how to merge accounts. For example Vlasta mentioned the usecase like: >> - When user logges with Facebook (or other provider) account, which is >> not yet linked to any Keycloak account, then new account on Keycloak >> side shouldn't be created automatically. Even if I logged with Facebook >> bob at gmail.com and there is no KC account for >> email bob at gmail.com , there >> is requirement to always show the screen like: "You just logged with >> facebook account bob at gmail.com . Do you want >> to link it with existing >> keycloak account?" If user agree, he would need to provide Keycloak >> account he wants to merge and then verify email or re-authenticate to >> link Facebook with existing account >> >> - Another use-case was to merge account automatically based on username >> from thirdparty SAML provider. For example the SAMLResponse with >> username "john" returned from SAML provider, there is a need to >> automatically merge it with Keycloak account "john" . In this case, they >> know that "john" will be always available on Keycloak side because of >> Federation provider, which SAML IDP uses as storage as well. >> >> Based on all of this, it looks that introducing Auth SPI for first time >> broker login is a way to go. This will address all of #1, #2 and #3 and >> many other usecases. >> >> For your #2, I agree that providers should be trusted by default. But >> not all of providers, because some of them don't verify email. AFAIK >> Facebook and Google verify email. But Github doesn't . It will be a >> security hole to trust github provider by default because then user can >> do something like: >> - He can create github account with any email he wants like >> "mposolda at redhat.com " >> - Login with this github account into Keycloak. If we trust the email by >> default, he will be logged into Keycloak to account >> "mposolda at redhat.com ", which is not his >> email -> FAIL >> >> I am not sure about support for merging accounts in Account management >> (like #4 and #5), will try to work on login flow first and will try to >> possibly look at account management then. >> >> Marek >> > >> > >> > On 10/27/2015 4:33 AM, Marek Posolda wrote: >> >> I went again through all the previous discussions, related JIRAs and >> >> requirements. As of now, my plan is to: >> >> >> >> - Use authentication SPI to handle the flow and related actions for >> >> first social login. (Update user profile, Detect duplicated account, >> >> Verify email or reauthenticate user if duplication is detected, Create >> >> social link to existing account). This allows most flexibility for >> >> admins to specify how exactly the linking should work >> >> >> >> - Detecting duplication will be based on email only by default - (For >> >> example duplication is detected if Facebook user with email >> >>bob at gmail.com authenticates, but there is >> already Keycloak user with >> >> emailbob at gmail.com ). The people can provide their >> own execution if >> >> they want different way for detect duplications >> >> >> >> - It seems it's more proper to postpone creating user account later, >> >> once we know that there is no duplication. In other words, if "Update >> >> profile on first login" is enabled, the user account is not yet created >> >> when the update profile page is shown. All the info related to >> >> BrokeredIdentityContext stuff will be available on ClientSession. This >> >> seems to me easier and more proper solution then creating temporary >> >> account with email in some "temporary" attribute. Temporary accounts >> >> have other challenges (Cleaner thread for delete outdated unmerged >> >> accounts etc). >> >> >> >> - If "trustEmail" flag is on for IdentityProvider, the provider link >> >> will be created automatically. (For example if Facebook user >> >>bob at gmail.com authenticates for the first >> time and there is already >> >> Keycloak user with emailbob at gmail.com and trustEmail is on, the >> >> Facebook link is automatically created for Keycloak account >> >>bob at gmail.com without any additional >> verification) >> >> >> >> - If "trustEmail" flag is off, there would need to be other way to >> >> verify user before creating social link. The user will first confirm if >> >> he wants to merge the accounts. Then there will be either: >> >> -- Email verification: The mail will be sent tobob at gmail.com like >> >> "Someone authenticates to Keycloak serverhttp://www.keycloak.org:8080 >> >> through Facebook accountbob at gmail.com and wants to link Facebook >> >> account with existing Keycloak accountbob at gmail.com . If it is you, >> >> click here" . After user clicks, the social link is created >> >> -- Further authentication: User will need to authenticate to existing >> >>bob at gmail.com keycloak account through >> password (or OTP or both or >> >> something else) >> >> All of this is configurable through flows, so admin can disable the "Do >> >> you want to create social link?" screen, or enforce email verification >> >> instead of authentication, configure required authenticators etc. >> >> >> >> - I am not sure if we want to handle just merge with existing account >> >> during first broker login, or if we also want to handle merging of >> >> accounts in account management? For now, I am planning to handle just >> >> the login flow and possibly address Account management later if there is >> >> need for it. The merging accounts in account management might be quite a >> >> challenge as there is merge of 2 already existing user accounts with >> >> various issues related to it (Which roles/permissions should merged >> >> account have? Which attributes it should have? Which federation link? >> >> etc.). But at least, I am planning to address the issue with redirect to >> >> login forms error screen instead of stay in account management - >> >>https://issues.jboss.org/browse/KEYCLOAK-1822 >> >> >> >> Marek >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >>keycloak-dev at lists.jboss.org >> >>https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From velias at redhat.com Thu Oct 29 05:44:18 2015 From: velias at redhat.com (Vlastimil Elias) Date: Thu, 29 Oct 2015 10:44:18 +0100 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: <5631D355.6000402@redhat.com> References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> <563130DB.2090604@redhat.com> <27E56C7A-FAEC-4114-AA48-5D79EEF374AB@smartling.com> <5631D355.6000402@redhat.com> Message-ID: <5631EA72.7000707@redhat.com> On 29.10.2015 09:05, Marek Posolda wrote: > On 28/10/15 23:44, Scott Rossillo wrote: >> It?s important to allow for account linking without a manual step if >> the trust email is true. I?m not against optionally forcing the user >> to link accounts. However, if the user never confirms they want to >> link, I?d want to identity broker account to never be created. >> >> Hope that makes sense. I know there are a lot of use cases you?re >> considering here but I?d rather not have to write code to maintain >> automatic account linking (with or without a verification step) >> >> Also, if user me at gmail.com is registered in >> Keycloak and then uses Google+ authentication, it would be silly to >> make the user confirm they want the accounts linked. > > With the authentication flows, it's possible to do things very > flexible. However the question is what should be the default > behaviour. I think we will have the possibility to "autolink" without > additional verification/reauthentication, but it won't be likely > enabled by default. As Stian mentioned, there is some security impact > with autolinking even for trusted providers like Google. +1000 for flexibility but sane and secure defaults. Vl > > Marek >> >> Scott Rossillo >> Smartling | Senior Software Engineer >> srossillo at smartling.com >> >> Powered by Sigstr >> >>> On Oct 28, 2015, at 4:32 PM, Bill Burke wrote: >>> >>> If a user has loads of social networks and links a bunch of them, if >>> *any one* of them is compromised the entire account is compromised. >>> Most sites using social login, the only reason is there is a login is >>> for the appliation to collect marketing data. So, the default behavior >>> should make things as simple as possible for the user. >>> >>> At a minimum, by default, the user should not be required to link an >>> account if there is a conflicting duplicate email given by the >>> provider. >>> I have found develoeprs.redhat.com >>> very difficult to use. >>> >>> >>> >>> On 10/28/2015 12:34 PM, Scott Rehorn wrote: >>>> I agree with Stian here ? the process to normalize a collection of >>>> logins requires human-interaction nuance that should not be >>>> automated. I >>>> think Keycloak can provide a nice user experience to aid the process, >>>> but it should always be an interactive process with plenty of >>>> re-authentication challenges to make sure an individual still retains >>>> ownership of the various candidate linked accounts. >>>> >>>> From: >>> >>>> > on behalf of Stian >>>> Thorgersen >>>> > >>>> Reply-To: "stian at redhat.com >>>> " >>>> > >>>> Date: Wednesday, October 28, 2015 at 8:06 AM >>>> To: Marek Posolda >>>> > >>>> Cc: keycloak-dev >>> >>>> > >>>> Subject: Re: [keycloak-dev] Plan for "First login with identity >>>> brokers" >>>> >>>> I'm quite concerned about auto linking accounts. If someone has >>>> loads of >>>> social networks enabled and a user has a single of those compromised >>>> (that happens quite frequently) the attackers would then also be >>>> able to >>>> gain access to whatever Keycloak secures. The user wouldn't even know >>>> they have access to Keycloak, since the user has never used to >>>> compromised account to login to Keycloak. >>>> >>>> I strongly feel we should never link to any account without requiring >>>> user to first authenticate to the account we are linking with. >>>> >>>> On 27 October 2015 at 08:04, Marek Posolda >>> > wrote: >>>> >>>> On 27/10/15 14:05, Bill Burke wrote: >>>>> IMO, most applications will not care about account duplication. Most >>>>> users won't care about account linking. So, IMO: >>>> Remember you mentioned that already in the previous discussions. IMO >>>> people care and usually want to have single account on single >>>> site. If >>>> you have 2 accounts, you never know to which of your accounts >>>> you are >>>> authenticated. This causes various issues, like permissions >>>> available to >>>> account1, but you are logged with account2 etc. >>>> >>>> Remember some time ago I messed on some site and have 2 accounts >>>> like >>>> "mposolda" and "mposolda at redhat.com >>>> " . >>>> I had always issues like that >>>> when I was logged as "mposolda" I had "Access denied" when going >>>> to page >>>> I was supposed to have permission. So needed to logout and login >>>> again >>>> as "mposolda at redhat.com >>>> " etc. >>>>> >>>>> 1) users should not be required to link accounts. In the case >>>>> where an >>>>> account cannot be automatically linked a duplicate account should be >>>>> created >>>>> 2) Providers should be trusted by default. Trusted providers can just >>>>> automatically link themselves to existing accounts that were logged in >>>>> by other trusted providers. >>>>> 3) Untrusted providers can automatically link if email has been >>>>> verified >>>>> for all parties. >>>>> 4) Users can merge accounts that have verified emails. >>>>> 5) An alternative to user self merging of account could be >>>>> requiring to >>>>> enter in a temporary code after logging into each account. >>>>> >>>>> >>>>> #1 and #2 can be added with minimal changes to code. #3 requires >>>>> a flow >>>>> on broker login and a rework of the broker SPI. #4 is account service >>>>> changes. #5 might be as easy as adding a required action. >>>>> >>>>> I guess it depends if ultimate flexibility is needed. #1, #2 and #4 >>>>> might be enough and require the least amount of changes and SPI >>>>> refactoring. >>>> I think that flexibility is needed based on various JIRAs and >>>> feedback. >>>> Just talked with Vlasta Elias from jboss.org >>>> . >>>> They have even more >>>> requirements for possible conditions when accounts should be >>>> merged and >>>> how to merge accounts. For example Vlasta mentioned the usecase >>>> like: >>>> - When user logges with Facebook (or other provider) account, >>>> which is >>>> not yet linked to any Keycloak account, then new account on Keycloak >>>> side shouldn't be created automatically. Even if I logged with >>>> Facebook >>>> bob at gmail.com and >>>> there is no KC account for >>>> email bob at gmail.com >>>> , there >>>> is requirement to always show the screen like: "You just logged with >>>> facebook account bob at gmail.com >>>> . Do you want >>>> to link it with existing >>>> keycloak account?" If user agree, he would need to provide Keycloak >>>> account he wants to merge and then verify email or >>>> re-authenticate to >>>> link Facebook with existing account >>>> >>>> - Another use-case was to merge account automatically based on >>>> username >>>> from thirdparty SAML provider. For example the SAMLResponse with >>>> username "john" returned from SAML provider, there is a need to >>>> automatically merge it with Keycloak account "john" . In this >>>> case, they >>>> know that "john" will be always available on Keycloak side >>>> because of >>>> Federation provider, which SAML IDP uses as storage as well. >>>> >>>> Based on all of this, it looks that introducing Auth SPI for >>>> first time >>>> broker login is a way to go. This will address all of #1, #2 and >>>> #3 and >>>> many other usecases. >>>> >>>> For your #2, I agree that providers should be trusted by >>>> default. But >>>> not all of providers, because some of them don't verify email. AFAIK >>>> Facebook and Google verify email. But Github doesn't . It will be a >>>> security hole to trust github provider by default because then >>>> user can >>>> do something like: >>>> - He can create github account with any email he wants like >>>> "mposolda at redhat.com >>>> " >>>> - Login with this github account into Keycloak. If we trust the >>>> email by >>>> default, he will be logged into Keycloak to account >>>> "mposolda at redhat.com >>>> ", which is not his >>>> email -> FAIL >>>> >>>> I am not sure about support for merging accounts in Account >>>> management >>>> (like #4 and #5), will try to work on login flow first and will >>>> try to >>>> possibly look at account management then. >>>> >>>> Marek >>>>> >>>>> >>>>> On 10/27/2015 4:33 AM, Marek Posolda wrote: >>>>>> I went again through all the previous discussions, related JIRAs and >>>>>> requirements. As of now, my plan is to: >>>>>> >>>>>> - Use authentication SPI to handle the flow and related actions for >>>>>> first social login. (Update user profile, Detect duplicated account, >>>>>> Verify email or reauthenticate user if duplication is detected, >>>>>> Create >>>>>> social link to existing account). This allows most flexibility for >>>>>> admins to specify how exactly the linking should work >>>>>> >>>>>> - Detecting duplication will be based on email only by default - (For >>>>>> example duplication is detected if Facebook user with email >>>>>> bob at gmail.com >>>>>> authenticates, but there is >>>> already Keycloak user with >>>>>> emailbob at gmail.com ). The people can >>>>>> provide their >>>> own execution if >>>>>> they want different way for detect duplications >>>>>> >>>>>> - It seems it's more proper to postpone creating user account later, >>>>>> once we know that there is no duplication. In other words, if "Update >>>>>> profile on first login" is enabled, the user account is not yet >>>>>> created >>>>>> when the update profile page is shown. All the info related to >>>>>> BrokeredIdentityContext stuff will be available on ClientSession. >>>>>> This >>>>>> seems to me easier and more proper solution then creating temporary >>>>>> account with email in some "temporary" attribute. Temporary accounts >>>>>> have other challenges (Cleaner thread for delete outdated unmerged >>>>>> accounts etc). >>>>>> >>>>>> - If "trustEmail" flag is on for IdentityProvider, the provider link >>>>>> will be created automatically. (For example if Facebook user >>>>>> bob at gmail.com >>>>>> authenticates for the first >>>> time and there is already >>>>>> Keycloak user with emailbob at gmail.com >>>>>> and trustEmail is on, the >>>>>> Facebook link is automatically created for Keycloak account >>>>>> bob at gmail.com >>>>>> without any additional >>>> verification) >>>>>> >>>>>> - If "trustEmail" flag is off, there would need to be other way to >>>>>> verify user before creating social link. The user will first >>>>>> confirm if >>>>>> he wants to merge the accounts. Then there will be either: >>>>>> -- Email verification: The mail will be sent tobob at gmail.com >>>>>> like >>>>>> "Someone authenticates to Keycloak serverhttp://www.keycloak.org:8080 >>>>>> through Facebook accountbob at gmail.com >>>>>> and wants to >>>>>> link Facebook >>>>>> account with existing Keycloak accountbob at gmail.com >>>>>> . If it is you, >>>>>> click here" . After user clicks, the social link is created >>>>>> -- Further authentication: User will need to authenticate to existing >>>>>> bob at gmail.com >>>>>> keycloak account through >>>> password (or OTP or both or >>>>>> realms/rhd/login-actions/email-verification?code=KYxAcXLs140rGN8CwQFtQssOj2es7aZBa6DrbbdGHng.822f5fb1-e05b-4e17-bb90-e6bbb8fba68esomething >>>>>> else) >>>>>> All of this is configurable through flows, so admin can disable >>>>>> the "Do >>>>>> you want to create social link?" screen, or enforce email >>>>>> verification >>>>>> instead of authentication, configure required authenticators etc. >>>>>> >>>>>> - I am not sure if we want to handle just merge with existing account >>>>>> during first broker login, or if we also want to handle merging of >>>>>> accounts in account management? For now, I am planning to handle just >>>>>> the login flow and possibly address Account management later if >>>>>> there is >>>>>> need for it. The merging accounts in account management might be >>>>>> quite a >>>>>> challenge as there is merge of 2 already existing user accounts with >>>>>> various issues related to it (Which roles/permissions should merged >>>>>> account have? Which attributes it should have? Which federation link? >>>>>> etc.). But at least, I am planning to address the issue with >>>>>> redirect to >>>>>> login forms error screen instead of stay in account management - >>>>>> https://issues.jboss.org/browse/KEYCLOAK-1822 >>>>>> >>>>>> Marek >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151029/b516ef2d/attachment-0001.html From bburke at redhat.com Thu Oct 29 09:37:33 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 29 Oct 2015 09:37:33 -0400 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: <5631E9FA.1050302@redhat.com> References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> <563130DB.2090604@redhat.com> <5631E9FA.1050302@redhat.com> Message-ID: <5632211D.5020706@redhat.com> On 10/29/2015 5:42 AM, Vlastimil Elias wrote: > > > On 28.10.2015 21:32, Bill Burke wrote: >> If a user has loads of social networks and links a bunch of them, if >> *any one* of them is compromised the entire account is compromised. >> Most sites using social login, the only reason is there is a login is >> for the appliation to collect marketing data. So, the default behavior >> should make things as simple as possible for the user. >> >> At a minimum, by default, the user should not be required to link an >> account if there is a conflicting duplicate email given by the provider. >> I have found develoeprs.redhat.com very difficult to use. > > yep, it is difficult to use because it have to follow company's policy > with unique emails and Keycloak do not provide necessary support for > simple and user friendly account linking currently ;-) > Yeah, its not your fault. Its ours. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Thu Oct 29 16:35:45 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 29 Oct 2015 13:35:45 -0700 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: <5632211D.5020706@redhat.com> References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> <563130DB.2090604@redhat.com> <5631E9FA.1050302@redhat.com> <5632211D.5020706@redhat.com> Message-ID: Linking accounts automatically is fine, but we should not have an option that can do that without requiring users to authenticate first. There are so many cases where a user could have one social account compromised. They may not care that much about the account, they may never use the service so they've completely forgotten about it. Imagine the following scenario: * Tom signed up for GMail in 2005 - figured it was great and continued using the service the rest of his life * Tom signed up for Twitter in 2005 - figured it was not to his taste and never used the account again * Tom now read about two factor auth and configured it on his GMail account * Mary (a bad person) figured that the password to Toms twitter account was 'password' so she's gained access to Tom's Twitter - Tom doesn't know, but he doesn't care either * Tom signs up for a website that uses Keycloak and logs in with his trusted GMail account * Now if we let Mary login to the website that uses Keycloak with Toms old Twitter account, without first proving she's Tom (which she can't), would be just plain daft! On 29 October 2015 at 06:37, Bill Burke wrote: > > > On 10/29/2015 5:42 AM, Vlastimil Elias wrote: > > > > > > On 28.10.2015 21:32, Bill Burke wrote: > >> If a user has loads of social networks and links a bunch of them, if > >> *any one* of them is compromised the entire account is compromised. > >> Most sites using social login, the only reason is there is a login is > >> for the appliation to collect marketing data. So, the default behavior > >> should make things as simple as possible for the user. > >> > >> At a minimum, by default, the user should not be required to link an > >> account if there is a conflicting duplicate email given by the provider. > >> I have found develoeprs.redhat.com very difficult to use. > > > > yep, it is difficult to use because it have to follow company's policy > > with unique emails and Keycloak do not provide necessary support for > > simple and user friendly account linking currently ;-) > > > > Yeah, its not your fault. Its ours. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151029/875a9b5f/attachment.html From sthorger at redhat.com Thu Oct 29 16:43:08 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 29 Oct 2015 13:43:08 -0700 Subject: [keycloak-dev] Adding a minimum TTL for token refreshes In-Reply-To: <5631D539.6070603@redhat.com> References: <5631D49C.4050003@redhat.com> <5631D539.6070603@redhat.com> Message-ID: +1 This is absolutely needed On 29 October 2015 at 01:13, Marek Posolda wrote: > On 29/10/15 09:11, Marek Posolda wrote: > > +1 for this. I might have already created JIRA some months ago, but not > sure. If you don't found, create your own JIRA. > > Our javascript adapter keycloak.js already has support for this (method > "update" in keycloak.js), but java adapters don't have it. > > Looks we may need to add the new option on adapter config ( keycloak.js ) > for this. Not sure what should be it's default value, 5 seconds? > > Sorry, i meant keycloak.json in the last sentence about adapter config. > > Marek > > > Marek > > > On 28/10/15 19:51, Benjamin Loy wrote: > > Hello all, > > We are using Keycloak in production and wanted to make a change to it to > handle tokens that are about to expire. We have a number of services that > rely on the bearer token sent from our web servers for authentication. > Users will land on the web server, we verify their token is alive, and > send the bearer token to a service. Our issue is sometimes the user has an > extremely small amount of time left, the bearer token expires by the time > we do the security checks on the services, and the request fails. > > We are considering adding a minimum TTL > in RefreshableKeycloakSecurityContext that will refresh an active token if > it has less than a configurable amount of time left before it expires. > This will let us build a time window that will prevent the token from > expiring when interacting with services under normal circumstances. > > Would you be interested in our work on this or have any interest to do > this yourselves? I can create a Jira and a pull request if you want us to > implement this feature. > > Thanks, > > Ben > > > -- > > Benjamin Loy > > Senior Software Engineer > > bloy at smartling.com | o: (866) 707 6278 > smartling.com | linkedIn | @smartling > > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151029/9e4da717/attachment.html From mposolda at redhat.com Fri Oct 30 05:08:34 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 30 Oct 2015 10:08:34 +0100 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> <563130DB.2090604@redhat.com> <5631E9FA.1050302@redhat.com> <5632211D.5020706@redhat.com> Message-ID: <56333392.1010800@redhat.com> Ok, for now I can do it without possibility for automatic autolink without re-authentication. Marek On 29/10/15 21:35, Stian Thorgersen wrote: > Linking accounts automatically is fine, but we should not have an > option that can do that without requiring users to authenticate first. > > There are so many cases where a user could have one social account > compromised. They may not care that much about the account, they may > never use the service so they've completely forgotten about it. > > Imagine the following scenario: > > * Tom signed up for GMail in 2005 - figured it was great and continued > using the service the rest of his life > * Tom signed up for Twitter in 2005 - figured it was not to his taste > and never used the account again > * Tom now read about two factor auth and configured it on his GMail > account > * Mary (a bad person) figured that the password to Toms twitter > account was 'password' so she's gained access to Tom's Twitter - Tom > doesn't know, but he doesn't care either > * Tom signs up for a website that uses Keycloak and logs in with his > trusted GMail account > * Now if we let Mary login to the website that uses Keycloak with Toms > old Twitter account, without first proving she's Tom (which she > can't), would be just plain daft! > > On 29 October 2015 at 06:37, Bill Burke > wrote: > > > > On 10/29/2015 5:42 AM, Vlastimil Elias wrote: > > > > > > On 28.10.2015 21:32, Bill Burke wrote: > >> If a user has loads of social networks and links a bunch of > them, if > >> *any one* of them is compromised the entire account is compromised. > >> Most sites using social login, the only reason is there is a > login is > >> for the appliation to collect marketing data. So, the default > behavior > >> should make things as simple as possible for the user. > >> > >> At a minimum, by default, the user should not be required to > link an > >> account if there is a conflicting duplicate email given by the > provider. > >> I have found develoeprs.redhat.com > very difficult to use. > > > > yep, it is difficult to use because it have to follow company's > policy > > with unique emails and Keycloak do not provide necessary support for > > simple and user friendly account linking currently ;-) > > > > Yeah, its not your fault. Its ours. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151030/688a2954/attachment-0001.html From bburke at redhat.com Fri Oct 30 10:57:05 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 30 Oct 2015 10:57:05 -0400 Subject: [keycloak-dev] Plan for "First login with identity brokers" In-Reply-To: References: <562F36E8.9060501@redhat.com> <562F7693.80805@redhat.com> <562F9286.5020205@redhat.com> <563130DB.2090604@redhat.com> <5631E9FA.1050302@redhat.com> <5632211D.5020706@redhat.com> Message-ID: <56338541.5060403@redhat.com> There's an alternative problem. Logs in with Twitter in 2005. Logs in again 2015 with Google. Is required to link with Twitter, says "screw it" because he doesn't remember his Twitter password and just closes his browser and doesn't use the website. I've been on really popular high-traffic sites where their google login was broken for months (mmqb.si.com which is an NFL website for Sports Illustrated). I used my Facebook identity instead. If I had been required to merge accounts manually, I would have not been able to use the site. On 10/29/2015 4:35 PM, Stian Thorgersen wrote: > Linking accounts automatically is fine, but we should not have an option > that can do that without requiring users to authenticate first. > > There are so many cases where a user could have one social account > compromised. They may not care that much about the account, they may > never use the service so they've completely forgotten about it. > > Imagine the following scenario: > > * Tom signed up for GMail in 2005 - figured it was great and continued > using the service the rest of his life > * Tom signed up for Twitter in 2005 - figured it was not to his taste > and never used the account again > * Tom now read about two factor auth and configured it on his GMail account > * Mary (a bad person) figured that the password to Toms twitter account > was 'password' so she's gained access to Tom's Twitter - Tom doesn't > know, but he doesn't care either > * Tom signs up for a website that uses Keycloak and logs in with his > trusted GMail account > * Now if we let Mary login to the website that uses Keycloak with Toms > old Twitter account, without first proving she's Tom (which she can't), > would be just plain daft! > > On 29 October 2015 at 06:37, Bill Burke > wrote: > > > > On 10/29/2015 5:42 AM, Vlastimil Elias wrote: > > > > > > On 28.10.2015 21:32, Bill Burke wrote: > >> If a user has loads of social networks and links a bunch of them, if > >> *any one* of them is compromised the entire account is compromised. > >> Most sites using social login, the only reason is there is a login is > >> for the appliation to collect marketing data. So, the default behavior > >> should make things as simple as possible for the user. > >> > >> At a minimum, by default, the user should not be required to link an > >> account if there is a conflicting duplicate email given by the provider. > >> I have founddeveloeprs.redhat.com very difficult > to use. > > > > yep, it is difficult to use because it have to follow company's policy > > with unique emails and Keycloak do not provide necessary support for > > simple and user friendly account linking currently ;-) > > > > Yeah, its not your fault. Its ours. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jm85martins at gmail.com Fri Oct 30 17:47:26 2015 From: jm85martins at gmail.com (Jorge M.) Date: Fri, 30 Oct 2015 21:47:26 +0000 Subject: [keycloak-dev] Help with keycloak evaluation Message-ID: Hi, I'm evaluating the keycloak to use in a multi-module system in production and I need some help in the following topics: - Is it possible to define groups of roles? For example, in a scenario using groups as profiles and the roles as resources. - Single login validation (only allow a single login session per user to avoid account sharing) - Is there any sample federation provider for RDBMS? - Are you planning to develop an adapter to PHP web applications? Any community adapter available? Great Job! Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151030/1c01dada/attachment.html From bburke at redhat.com Fri Oct 30 18:02:25 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 30 Oct 2015 18:02:25 -0400 Subject: [keycloak-dev] Help with keycloak evaluation In-Reply-To: References: Message-ID: <5633E8F1.7030804@redhat.com> On 10/30/2015 5:47 PM, Jorge M. wrote: > > Hi, > > I'm evaluating the keycloak to use in a multi-module system in > production and I need some help in the following topics: > > - Is it possible to define groups of roles? For example, in > a scenario using groups as profiles and the roles as resources. > Not sure what you mean by "profiles" and "resources" could have multiple meanings. Currently, we don't have "groups" but have the concept of a "Composite Role". A composite role can have multiple roles associated with it. I am currently working on the concept of a group and this will be released in 1.7 sometime in December. Groups can have roles associated with them and attributes. Group members will inherit these roles and attributes. Groups can be constructed in a hierarchy. > - Single login validation (only allow a single login session per user to > avoid account sharing) > This is a feature that we don't have out of the box, but is something I believe you would be able to code with our SPIs. Probably something we should provide out of the box. > - Is there any sample federation provider for RDBMS? > There is a very simple non-RDBMS example for federation. You' have to extrapolate how to marry that to a RDMS. > > > - Are you planning to develop an adapter to PHP web applications? Any > community adapter available? > We have 2 options for PHP (and other non-Java languages) at the moment: #1 - Use SAML as the protocol. Front PHP with Apache. Use mod-auth-mellon. #2 - Use Keycloak Security Proxy. Its a small Java based web server based on Undertow that forwards http requests and secures remote web servers. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Oct 30 18:13:23 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 30 Oct 2015 18:13:23 -0400 Subject: [keycloak-dev] redesign of federation Message-ID: <5633EB83.3000806@redhat.com> In doing group model, I was thinking more about federation. Our SPI kinda sucks. I was thinking that local storage (Model API) and UserFederation should be the same exact SPI. Instead of just RealmProvider and UserProvider, we might break it up into: * RealmProvider - holds realms and clients * UserProvider - holds username and attributes about the user * UserRelationshipProvider - holds user role mappings, user group membership * UserCredentialProvider - stores and authenticates credentials * GroupProvider - holds group definitions * RoleProvider - holds role definitions One of the big problems we have is that roles and groups have to be defined within Keycloak DB even though they might live in one or more external stores. Admin console would have to change too. You'd have to pick which database you wanted to manage. i.e. if you wanted to add a role you might want to add it to an LDAP store and not local storage. This is something we'd really have to map out and design. I would love to be able to do it before product, but I don't think we'll have enough time to bake it in community. Maybe something we'll have to wait for Keycloak 2.0. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com