From fabricio.milone at shinetech.com Tue Dec 1 00:18:24 2015 From: fabricio.milone at shinetech.com (Fabricio Milone) Date: Tue, 1 Dec 2015 16:18:24 +1100 Subject: [keycloak-dev] Direct access to forgotten password Message-ID: Hi, I'm doing some research on the project I'm working on and I need some help on your side. We are using keycloak from different client apps and in this particular case, I have to add a forgotten password functionality for the (Native) Android App using a direct access api. I've been reading through the documentation but still I'm not sure which is the best approach to implement this. I know that on the documentation it is encouraged that I should make use of the device's web browser to login/forgot password, but it is a project requirement that has to be met, unfortunately. Another desirable point on this is that we should avoid using form submission for the forgot password functionality, but not sure if that's even possible. Thanks in advance, I'd really appreciate comments regarding this. Regards, Fabricio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151201/27b2d276/attachment.html From sss2174 at columbia.edu Tue Dec 1 01:47:47 2015 From: sss2174 at columbia.edu (sabir) Date: Tue, 1 Dec 2015 01:47:47 -0500 Subject: [keycloak-dev] limiting users to access specific clients only Message-ID: I am building keycloak prototype apps that demonstrate authentication against deployed keycloak server. I have 2 js client apps under the same web-server with 2 different keycloak client JSON. I have: - Created realm -> poc-realm - Created clients for poc apps to authenticate against -> app1 and app2 - Created roles in app1 -> app1-user-role app2 -> app2-user-role - Created users -> app1-user and app2-user - Assigned roles -> app1-user-role to app1-user, app2-user-role to app2-user When I try to get redirected keycloak login for app1, I am able to login with app1-user and app2-user, and similarly I am able to login into app2 with app1-user and app2-user. Am I missing something? How do I ensure that app1-user isn't able to log into app2, and app2-user into app1? Although note that I have the same url patterns for *Valid Redirect URIs *of both clients. My JSON keycloak clients are correct: { "realm": "poc-realm", "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAryTAZE2+d/7uKduayhQlInhnD43jdPyBttVbERLXO7wN9juXIuO5SR5P75aIcy1Fpf5VTrL2Neb4iLeEGgTUHM7b0ycjNgK40CXcwhneSn0EIogDLqXfJ87efwH2UYG//3cWZsB9PjX440Yq4uh/pBs5aTw7hHhvlaF/LRTBibhpcy7N/cKPp2PRkhQbWX79EfIsFLg8IKDryazYkdsVoaVI20aeOyb9mfXSU+h7ZUZIKhY4hhtSK004ToD73HQvJ5U61Zv7UAEtKHOD928SO0/VijFkGCh7fHtOA4kNJhV6D7RehThz/llDE3rfs4wkO24L0j/hAss30OSQNnAD1QIDAQAB", "auth-server-url": "[server URL]/auth", "ssl-required": "external", "resource": "app1", "credentials": { "secret": "e119ccf7-5c5a-4681-b4fa-fcca1b3de3b3" }, "use-resource-role-mappings": true } and { "realm": "poc-realm", "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAryTAZE2+d/7uKduayhQlInhnD43jdPyBttVbERLXO7wN9juXIuO5SR5P75aIcy1Fpf5VTrL2Neb4iLeEGgTUHM7b0ycjNgK40CXcwhneSn0EIogDLqXfJ87efwH2UYG//3cWZsB9PjX440Yq4uh/pBs5aTw7hHhvlaF/LRTBibhpcy7N/cKPp2PRkhQbWX79EfIsFLg8IKDryazYkdsVoaVI20aeOyb9mfXSU+h7ZUZIKhY4hhtSK004ToD73HQvJ5U61Zv7UAEtKHOD928SO0/VijFkGCh7fHtOA4kNJhV6D7RehThz/llDE3rfs4wkO24L0j/hAss30OSQNnAD1QIDAQAB", "auth-server-url": "[server URL]/auth", "ssl-required": "external", "resource": "app2", "credentials": { "secret": "e119ccf7-5c5a-4681-b4fa-fcca1b3de3b3" }, "use-resource-role-mappings": true } Thanks for help. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151201/e49daa8e/attachment.html From sthorger at redhat.com Tue Dec 1 07:46:46 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 1 Dec 2015 13:46:46 +0100 Subject: [keycloak-dev] KEYCLOAK-1900 - Pluggable password hashing algorithm In-Reply-To: References: Message-ID: Hi, Just wondering what is the status on this? We'd like to make sure it makes it into 1.8 release On 18 November 2015 at 15:09, Kunal K wrote: > Hi Stian, > > Could you please review this code - > https://github.com/tsudot/keycloak/commit/ce58d795bfea9e6c19663fa40d7a499d2d78aeab > > I'm having trouble figuring out how to call session.getProvider(PasswordHashProvider.class, > algorithm) to replace Pbkdf2PasswordEncoder. > > I checked > https://github.com/tsudot/keycloak/blob/master/model/jpa/src/main/java/org/keycloak/models/jpa/UserAdapter.java#L399 > but couldn't find any instance of KeycloakSession. Am I missing something? > > On Tue, Nov 17, 2015 at 11:07 PM, Kunal K wrote: > >> Thanks for those notes Stian, I will read up and document my progress on >> this thread. >> >> On Tue, Nov 17, 2015 at 8:50 PM, Stian Thorgersen >> wrote: >> >>> Hi, >>> >>> That would be awesome. >>> >>> First step would be to read >>> http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html >>> to understand how Keycloak provides SPIs. >>> >>> Next thing would be to add: >>> >>> * class PasswordHashSPI >>> * interface PasswordHashProviderFactory >>> * interface PasswordHashProvider >>> >>> These should be added to services module. You would also need to >>> change Pbkdf2PasswordEncoder to be the default implementation. >>> >>> Instead of using Pbkdf2PasswordEncoder directly code should use >>> session.getProvider(PasswordHashProvider.class, algorithm). algorithm >>> should be set to on credential entities >>> (UserCredentialValueModel.algorithm). We also need a mechanism to specify >>> the default algorithm (that would be used when users sets new password and >>> also for existing users in the db). >>> >>> >>> On 17 November 2015 at 16:06, Kunal K wrote: >>> >>>> Hi all, >>>> >>>> I would like to start a discussion on how to implement - >>>> https://issues.jboss.org/browse/KEYCLOAK-1900 >>>> >>>> I have a django web app and all of my users are in a postgres database >>>> with salted passwords hashed using SHA. I have been reading how I can use >>>> UserFederation to implement by own credential validation, but the drawback >>>> here would be that I'll have to keep maintaining my old database. >>>> >>>> For starters, I was thinking of replacing all occurrences of >>>> Pbkdf2PasswordEncoder with an equivalent SHAPasswordEncoder, which is a >>>> very crude approach and I'm not sure if it will even work. After some bit >>>> of reading I saw this ticket - >>>> https://issues.jboss.org/browse/KEYCLOAK-1900 >>>> >>>> I would like to implement a custom hashing SPI and would love to get >>>> some pointers on how to go about it. >>>> >>>> Thanks >>>> >>>> -- >>>> *KUNAL KERKAR *| PRODUCT ENGINEER >>>> Plivo, Inc. 340 Pine St, San Francisco - 94104, USA >>>> Web: www.plivo.com | Twitter: @plivo , >>>> @tsudot >>>> >>>> Free Incoming SMS for All US Short Codes ? Get One Today!? >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> >> >> -- >> *KUNAL KERKAR *| PRODUCT ENGINEER >> Plivo, Inc. 340 Pine St, San Francisco - 94104, USA >> Web: www.plivo.com | Twitter: @plivo , @tsudot >> >> >> Free Incoming SMS for All US Short Codes ? Get One Today!? >> >> > > > > -- > *KUNAL KERKAR *| PRODUCT ENGINEER > Plivo, Inc. 340 Pine St, San Francisco - 94104, USA > Web: www.plivo.com | Twitter: @plivo , @tsudot > > > Free Incoming SMS for All US Short Codes ? Get One Today!? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151201/45e03530/attachment-0001.html From kunal at plivo.com Tue Dec 1 08:05:11 2015 From: kunal at plivo.com (Kunal K) Date: Tue, 1 Dec 2015 18:35:11 +0530 Subject: [keycloak-dev] KEYCLOAK-1900 - Pluggable password hashing algorithm In-Reply-To: References: Message-ID: Hi Stian, I've added password hashing as a SPI with default encoder as Pbkdf2PasswordEncoder. Some code clean up is remaining. I'll send out a PR by Wednesday 3rd Dec. On Tue, Dec 1, 2015 at 6:16 PM, Stian Thorgersen wrote: > Hi, > > Just wondering what is the status on this? We'd like to make sure it makes > it into 1.8 release > > On 18 November 2015 at 15:09, Kunal K wrote: > >> Hi Stian, >> >> Could you please review this code - >> https://github.com/tsudot/keycloak/commit/ce58d795bfea9e6c19663fa40d7a499d2d78aeab >> >> I'm having trouble figuring out how to call session.getProvider(PasswordHashProvider.class, >> algorithm) to replace Pbkdf2PasswordEncoder. >> >> I checked >> https://github.com/tsudot/keycloak/blob/master/model/jpa/src/main/java/org/keycloak/models/jpa/UserAdapter.java#L399 >> but couldn't find any instance of KeycloakSession. Am I missing something? >> >> On Tue, Nov 17, 2015 at 11:07 PM, Kunal K wrote: >> >>> Thanks for those notes Stian, I will read up and document my progress on >>> this thread. >>> >>> On Tue, Nov 17, 2015 at 8:50 PM, Stian Thorgersen >>> wrote: >>> >>>> Hi, >>>> >>>> That would be awesome. >>>> >>>> First step would be to read >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html >>>> to understand how Keycloak provides SPIs. >>>> >>>> Next thing would be to add: >>>> >>>> * class PasswordHashSPI >>>> * interface PasswordHashProviderFactory >>>> * interface PasswordHashProvider >>>> >>>> These should be added to services module. You would also need to >>>> change Pbkdf2PasswordEncoder to be the default implementation. >>>> >>>> Instead of using Pbkdf2PasswordEncoder directly code should use >>>> session.getProvider(PasswordHashProvider.class, algorithm). algorithm >>>> should be set to on credential entities >>>> (UserCredentialValueModel.algorithm). We also need a mechanism to specify >>>> the default algorithm (that would be used when users sets new password and >>>> also for existing users in the db). >>>> >>>> >>>> On 17 November 2015 at 16:06, Kunal K wrote: >>>> >>>>> Hi all, >>>>> >>>>> I would like to start a discussion on how to implement - >>>>> https://issues.jboss.org/browse/KEYCLOAK-1900 >>>>> >>>>> I have a django web app and all of my users are in a postgres database >>>>> with salted passwords hashed using SHA. I have been reading how I can use >>>>> UserFederation to implement by own credential validation, but the drawback >>>>> here would be that I'll have to keep maintaining my old database. >>>>> >>>>> For starters, I was thinking of replacing all occurrences of >>>>> Pbkdf2PasswordEncoder with an equivalent SHAPasswordEncoder, which is a >>>>> very crude approach and I'm not sure if it will even work. After some bit >>>>> of reading I saw this ticket - >>>>> https://issues.jboss.org/browse/KEYCLOAK-1900 >>>>> >>>>> I would like to implement a custom hashing SPI and would love to get >>>>> some pointers on how to go about it. >>>>> >>>>> Thanks >>>>> >>>>> -- >>>>> *KUNAL KERKAR *| PRODUCT ENGINEER >>>>> Plivo, Inc. 340 Pine St, San Francisco - 94104, USA >>>>> Web: www.plivo.com | Twitter: @plivo , >>>>> @tsudot >>>>> >>>>> Free Incoming SMS for All US Short Codes ? Get One Today!? >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>> >>> >>> -- >>> *KUNAL KERKAR *| PRODUCT ENGINEER >>> Plivo, Inc. 340 Pine St, San Francisco - 94104, USA >>> Web: www.plivo.com | Twitter: @plivo , @tsudot >>> >>> >>> Free Incoming SMS for All US Short Codes ? Get One Today!? >>> >>> >> >> >> >> -- >> *KUNAL KERKAR *| PRODUCT ENGINEER >> Plivo, Inc. 340 Pine St, San Francisco - 94104, USA >> Web: www.plivo.com | Twitter: @plivo , @tsudot >> >> >> Free Incoming SMS for All US Short Codes ? Get One Today!? >> >> > > -- *KUNAL KERKAR *| PRODUCT ENGINEER Plivo, Inc. 340 Pine St, San Francisco - 94104, USA Web: www.plivo.com | Twitter: @plivo , @tsudot Free Incoming SMS for All US Short Codes ? Get One Today!? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151201/356e9f1f/attachment.html From bburke at redhat.com Tue Dec 1 10:57:08 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 1 Dec 2015 10:57:08 -0500 Subject: [keycloak-dev] is UserModel.getServiceAccountClientLink() actually used? Message-ID: <565DC354.1030605@redhat.com> I just did a usage in Intellij and I don't see it used by any business logic. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Tue Dec 1 13:55:49 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 1 Dec 2015 19:55:49 +0100 Subject: [keycloak-dev] Master bumped to 1.8 Message-ID: 1.7.x branch created and master bumped to 1.8.0.CR1-SNAPSHOT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151201/25e4e76b/attachment.html From mposolda at redhat.com Tue Dec 1 15:47:57 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 1 Dec 2015 21:47:57 +0100 Subject: [keycloak-dev] is UserModel.getServiceAccountClientLink() actually used? In-Reply-To: <565DC354.1030605@redhat.com> References: <565DC354.1030605@redhat.com> Message-ID: <565E077D.5070708@redhat.com> Yes, the serviceAccountClientLink field on user is needed, so the client can find it's corresponding "service account" user. There is method UserProvider.getUserByServiceAccountClient for that. Both the UserModel.getServiceAccountClientLink and UserModel.setServiceAccountClientLink are not directly used by business logic, but they are needed for export/import . Marek On 01/12/15 16:57, Bill Burke wrote: > I just did a usage in Intellij and I don't see it used by any business > logic. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151201/c655abe0/attachment.html From keycloak-dev at lists.haus42.com Tue Dec 1 23:42:40 2015 From: keycloak-dev at lists.haus42.com (keycloak-dev at lists.haus42.com) Date: Wed, 2 Dec 2015 04:42:40 +0000 (UTC) Subject: [keycloak-dev] class not found In-Reply-To: References: <305bd269-08b0-4549-a5ad-15188867cf85@me.com> Message-ID: Hello, hmmm, I have the same issue w/ version built directly from master yesterday. So I'm not sure if it is only WildFly 10. Sure, I could have done something wrong... Thanks, Dietmar Happend for registration email, using Java 1.7 on Linux... 06:19:20,788 ERROR [io.undertow.request] (default task-19) UT005023: Exception handling request to /auth/realms/publicitas/login-actions/required-action: java.lang.RuntimeException: request path: /auth/realms/publicitas/login-actions/required-action at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:75) 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:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: org.jboss.resteasy.spi.UnhandledException: java.lang.NoClassDefFoundError: javax/mail/Multipart 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:61) ... 29 more Caused by: java.lang.NoClassDefFoundError: javax/mail/Multipart at org.keycloak.email.DefaultEmailSenderProviderFactory.create(DefaultEmailSenderProviderFactory.java:14) at org.keycloak.email.DefaultEmailSenderProviderFactory.create(DefaultEmailSenderProviderFactory.java:10) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) at org.keycloak.email.freemarker.FreeMarkerEmailTemplateProvider.send(FreeMarkerEmailTemplateProvider.java:163) at org.keycloak.email.freemarker.FreeMarkerEmailTemplateProvider.send(FreeMarkerEmailTemplateProvider.java:156) at org.keycloak.email.freemarker.FreeMarkerEmailTemplateProvider.send(FreeMarkerEmailTemplateProvider.java:129) at org.keycloak.email.freemarker.FreeMarkerEmailTemplateProvider.sendVerifyEmail(FreeMarkerEmailTemplateProvider.java:125) at org.keycloak.login.freemarker.FreeMarkerLoginFormsProvider.createResponse(FreeMarkerLoginFormsProvider.java:156) at org.keycloak.authentication.requiredactions.VerifyEmail.requiredActionChallenge(VerifyEmail.java:56) at org.keycloak.services.managers.AuthenticationManager.executionActions(AuthenticationManager.java:521) at org.keycloak.services.managers.AuthenticationManager.actionRequired(AuthenticationManager.java:453) at org.keycloak.services.managers.AuthenticationManager.nextActionAfterAuthentication(AuthenticationManager.java:421) at org.keycloak.services.resources.LoginActionsService.processRequireAction(LoginActionsService.java:781) at org.keycloak.services.resources.LoginActionsService.requiredActionGET(LoginActionsService.java:760) 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:103) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) ... 37 more Caused by: java.lang.ClassNotFoundException: javax.mail.Multipart from [Module "org.keycloak.keycloak-services:main" from local module loader @5537c1f1 (finder: local module finder @3f9de0ec (roots: /home/keycloak/middleware/keycloak-1.7.0.Final-SNAPSHOT/modules,/home/keycloak/middleware/keycloak-1.7.0.Final-SNAPSHOT/modules/system/layers/base))] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130) ... 61 more On Mon, 30 Nov 2015, Stian Thorgersen wrote: > We do not support deploying Keycloak server on WildFly 10 yet. > > On 30 November 2015 at 08:41, Michael Gerber wrote: > Hi all, > > I had to add the javax.mail.api module to the keycloak-services today, otherwise the reset password mail could not be > sent. (Because the class javax.mail.Multipart?could?not be found) > > I am using wildlfy 10 with the newest keycloak version.? > > Is this a known issue? > > Michael > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > From sthorger at redhat.com Wed Dec 2 02:20:31 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 Dec 2015 08:20:31 +0100 Subject: [keycloak-dev] class not found In-Reply-To: References: <305bd269-08b0-4549-a5ad-15188867cf85@me.com> Message-ID: Fixed - https://issues.jboss.org/browse/KEYCLOAK-2174 On 2 December 2015 at 05:42, wrote: > Hello, > > hmmm, I have the same issue w/ version built directly from master > yesterday. So I'm not sure if it is only WildFly 10. Sure, I could have > done something wrong... > > Thanks, > Dietmar > > Happend for registration email, using Java 1.7 on Linux... > > 06:19:20,788 ERROR [io.undertow.request] (default task-19) UT005023: > Exception handling request to > /auth/realms/publicitas/login-actions/required-action: > java.lang.RuntimeException: request path: > /auth/realms/publicitas/login-actions/required-action > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:75) > 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:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > Caused by: org.jboss.resteasy.spi.UnhandledException: > java.lang.NoClassDefFoundError: javax/mail/Multipart > 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:61) > ... 29 more > Caused by: java.lang.NoClassDefFoundError: javax/mail/Multipart > at > org.keycloak.email.DefaultEmailSenderProviderFactory.create(DefaultEmailSenderProviderFactory.java:14) > at > org.keycloak.email.DefaultEmailSenderProviderFactory.create(DefaultEmailSenderProviderFactory.java:10) > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103) > at > org.keycloak.email.freemarker.FreeMarkerEmailTemplateProvider.send(FreeMarkerEmailTemplateProvider.java:163) > at > org.keycloak.email.freemarker.FreeMarkerEmailTemplateProvider.send(FreeMarkerEmailTemplateProvider.java:156) > at > org.keycloak.email.freemarker.FreeMarkerEmailTemplateProvider.send(FreeMarkerEmailTemplateProvider.java:129) > at > org.keycloak.email.freemarker.FreeMarkerEmailTemplateProvider.sendVerifyEmail(FreeMarkerEmailTemplateProvider.java:125) > at > org.keycloak.login.freemarker.FreeMarkerLoginFormsProvider.createResponse(FreeMarkerLoginFormsProvider.java:156) > at > org.keycloak.authentication.requiredactions.VerifyEmail.requiredActionChallenge(VerifyEmail.java:56) > at > org.keycloak.services.managers.AuthenticationManager.executionActions(AuthenticationManager.java:521) > at > org.keycloak.services.managers.AuthenticationManager.actionRequired(AuthenticationManager.java:453) > at > org.keycloak.services.managers.AuthenticationManager.nextActionAfterAuthentication(AuthenticationManager.java:421) > at > org.keycloak.services.resources.LoginActionsService.processRequireAction(LoginActionsService.java:781) > at > org.keycloak.services.resources.LoginActionsService.requiredActionGET(LoginActionsService.java:760) > 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:103) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) > ... 37 more > Caused by: java.lang.ClassNotFoundException: javax.mail.Multipart from > [Module "org.keycloak.keycloak-services:main" from local module loader > @5537c1f1 (finder: local module finder @3f9de0ec (roots: > /home/keycloak/middleware/keycloak-1.7.0.Final-SNAPSHOT/modules,/home/keycloak/middleware/keycloak-1.7.0.Final-SNAPSHOT/modules/system/layers/base))] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404) > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385) > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130) > ... 61 more > > > On Mon, 30 Nov 2015, Stian Thorgersen wrote: > > We do not support deploying Keycloak server on WildFly 10 yet. >> >> On 30 November 2015 at 08:41, Michael Gerber wrote: >> Hi all, >> >> I had to add the javax.mail.api module to the keycloak-services today, >> otherwise the reset password mail could not be >> sent. (Because the class javax.mail.Multipart could not be found) >> >> I am using wildlfy 10 with the newest keycloak version. >> >> Is this a known issue? >> >> 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/20151202/b89f64dc/attachment.html From bburke at redhat.com Wed Dec 2 09:34:35 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 2 Dec 2015 09:34:35 -0500 Subject: [keycloak-dev] sticky sessions Message-ID: <565F017B.2000503@redhat.com> IMO, we need to highlight and document that when using a load balancer in a cluster, sticky sessions should be enabled. We might even want to consider adding support for sticky sessions for the code2token flow. The obvious reason is performance. Login can span multiple HTTP requests. If you have N nodes in the cluster with no clustering you have the possibility of the same user being retrieved from the database N times. One time for each authentication request (username/password, OTP page, required actions) and finally for the code 2 token request. Until I look into fixing it the auth SPI does a few extra redirects right now too. Code 2 token could simply have a callback URI so that the code 2 token request hits the same machine the code was created on. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Wed Dec 2 09:45:23 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 Dec 2015 15:45:23 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F017B.2000503@redhat.com> References: <565F017B.2000503@redhat.com> Message-ID: Not sure what you mean about code 2 token could have a callback uri? On 2 December 2015 at 15:34, Bill Burke wrote: > IMO, we need to highlight and document that when using a load balancer > in a cluster, sticky sessions should be enabled. We might even want to > consider adding support for sticky sessions for the code2token flow. > The obvious reason is performance. Login can span multiple HTTP > requests. If you have N nodes in the cluster with no clustering you > have the possibility of the same user being retrieved from the database > N times. One time for each authentication request (username/password, > OTP page, required actions) and finally for the code 2 token request. > Until I look into fixing it the auth SPI does a few extra redirects > right now too. > > Code 2 token could simply have a callback URI so that the code 2 token > request hits the same machine the code was created on. > > > > -- > 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/20151202/3020fb1e/attachment-0001.html From mposolda at redhat.com Wed Dec 2 09:50:18 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 2 Dec 2015 15:50:18 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F017B.2000503@redhat.com> References: <565F017B.2000503@redhat.com> Message-ID: <565F052A.1020001@redhat.com> Not sure if callback URI will work, because application may be able to see just the loadbalancer node and underlying cluster nodes might be hidden from it. For example if you have callback URI like http://node1:8080/auth/.../token, application may not be able to directly access host "node1" because it's hidden and application can access just http://loadbalancer:8080 . Marek On 02/12/15 15:34, Bill Burke wrote: > IMO, we need to highlight and document that when using a load balancer > in a cluster, sticky sessions should be enabled. We might even want to > consider adding support for sticky sessions for the code2token flow. > The obvious reason is performance. Login can span multiple HTTP > requests. If you have N nodes in the cluster with no clustering you > have the possibility of the same user being retrieved from the database > N times. One time for each authentication request (username/password, > OTP page, required actions) and finally for the code 2 token request. > Until I look into fixing it the auth SPI does a few extra redirects > right now too. > > Code 2 token could simply have a callback URI so that the code 2 token > request hits the same machine the code was created on. > > > From sthorger at redhat.com Wed Dec 2 09:55:38 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 Dec 2015 15:55:38 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F052A.1020001@redhat.com> References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> Message-ID: Adding callback URI to the token would also make it very Keycloak specific. So it would only work for Keycloak adapters. On 2 December 2015 at 15:50, Marek Posolda wrote: > Not sure if callback URI will work, because application may be able to > see just the loadbalancer node and underlying cluster nodes might be > hidden from it. > > For example if you have callback URI like > http://node1:8080/auth/.../token, application may not be able to > directly access host "node1" because it's hidden and application can > access just http://loadbalancer:8080 . > > Marek > > On 02/12/15 15:34, Bill Burke wrote: > > IMO, we need to highlight and document that when using a load balancer > > in a cluster, sticky sessions should be enabled. We might even want to > > consider adding support for sticky sessions for the code2token flow. > > The obvious reason is performance. Login can span multiple HTTP > > requests. If you have N nodes in the cluster with no clustering you > > have the possibility of the same user being retrieved from the database > > N times. One time for each authentication request (username/password, > > OTP page, required actions) and finally for the code 2 token request. > > Until I look into fixing it the auth SPI does a few extra redirects > > right now too. > > > > Code 2 token could simply have a callback URI so that the code 2 token > > request hits the same machine the code was created on. > > > > > > > > _______________________________________________ > 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/20151202/fac3ba97/attachment.html From sthorger at redhat.com Wed Dec 2 09:57:02 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 Dec 2015 15:57:02 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> Message-ID: We did discuss this quite a lot when we did clustering initially, and we never found an elegant solution to doing sticky sessions. On 2 December 2015 at 15:55, Stian Thorgersen wrote: > Adding callback URI to the token would also make it very Keycloak > specific. So it would only work for Keycloak adapters. > > On 2 December 2015 at 15:50, Marek Posolda wrote: > >> Not sure if callback URI will work, because application may be able to >> see just the loadbalancer node and underlying cluster nodes might be >> hidden from it. >> >> For example if you have callback URI like >> http://node1:8080/auth/.../token, application may not be able to >> directly access host "node1" because it's hidden and application can >> access just http://loadbalancer:8080 . >> >> Marek >> >> On 02/12/15 15:34, Bill Burke wrote: >> > IMO, we need to highlight and document that when using a load balancer >> > in a cluster, sticky sessions should be enabled. We might even want to >> > consider adding support for sticky sessions for the code2token flow. >> > The obvious reason is performance. Login can span multiple HTTP >> > requests. If you have N nodes in the cluster with no clustering you >> > have the possibility of the same user being retrieved from the database >> > N times. One time for each authentication request (username/password, >> > OTP page, required actions) and finally for the code 2 token request. >> > Until I look into fixing it the auth SPI does a few extra redirects >> > right now too. >> > >> > Code 2 token could simply have a callback URI so that the code 2 token >> > request hits the same machine the code was created on. >> > >> > >> > >> >> _______________________________________________ >> 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/20151202/19eec8cc/attachment.html From mposolda at redhat.com Wed Dec 2 09:58:30 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 2 Dec 2015 15:58:30 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F052A.1020001@redhat.com> References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> Message-ID: <565F0716.3060505@redhat.com> btv. we actually have some optimization "auth-server-url-for-backend-requests" on adapter side. This is useful if application and Keycloak are both running on same network and using same cluster nodes. In this case, application can send all backend (out-of-bound) requests like code2token, refreshToken, to Keycloak auth-server on same cluster node. For example if there is cluster with nodes "node1" and "node2" and application request is processed on "node1", it will also use "node1" to directly access Keycloak for out-of-bound requests. So as long as there is sticky session on application side, it will defacto result in sticky session for application too. Not sure if we need to optimize too much for login. Isn't refresh token used much more often than login? Marek On 02/12/15 15:50, Marek Posolda wrote: > Not sure if callback URI will work, because application may be able to > see just the loadbalancer node and underlying cluster nodes might be > hidden from it. > > For example if you have callback URI like > http://node1:8080/auth/.../token, application may not be able to > directly access host "node1" because it's hidden and application can > access just http://loadbalancer:8080 . > > Marek > > On 02/12/15 15:34, Bill Burke wrote: >> IMO, we need to highlight and document that when using a load balancer >> in a cluster, sticky sessions should be enabled. We might even want to >> consider adding support for sticky sessions for the code2token flow. >> The obvious reason is performance. Login can span multiple HTTP >> requests. If you have N nodes in the cluster with no clustering you >> have the possibility of the same user being retrieved from the database >> N times. One time for each authentication request (username/password, >> OTP page, required actions) and finally for the code 2 token request. >> Until I look into fixing it the auth SPI does a few extra redirects >> right now too. >> >> Code 2 token could simply have a callback URI so that the code 2 token >> request hits the same machine the code was created on. >> >> >> > _______________________________________________ > 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/20151202/ddd81a2b/attachment.html From mposolda at redhat.com Wed Dec 2 10:00:03 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 2 Dec 2015 16:00:03 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F0716.3060505@redhat.com> References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> Message-ID: <565F0773.1030601@redhat.com> On 02/12/15 15:58, Marek Posolda wrote: > btv. we actually have some optimization > "auth-server-url-for-backend-requests" on adapter side. This is useful > if application and Keycloak are both running on same network and using > same cluster nodes. In this case, application can send all backend > (out-of-bound) requests like code2token, refreshToken, to Keycloak > auth-server on same cluster node. > > For example if there is cluster with nodes "node1" and "node2" and > application request is processed on "node1", it will also use "node1" > to directly access Keycloak for out-of-bound requests. So as long as > there is sticky session on application side, it will defacto result in > sticky session for application too. I meant: it will defacto result in sticky session for *auth-server* too. > > Not sure if we need to optimize too much for login. Isn't refresh > token used much more often than login? > > Marek > > > On 02/12/15 15:50, Marek Posolda wrote: >> Not sure if callback URI will work, because application may be able to >> see just the loadbalancer node and underlying cluster nodes might be >> hidden from it. >> >> For example if you have callback URI like >> http://node1:8080/auth/.../token, application may not be able to >> directly access host "node1" because it's hidden and application can >> access justhttp://loadbalancer:8080 . >> >> Marek >> >> On 02/12/15 15:34, Bill Burke wrote: >>> IMO, we need to highlight and document that when using a load balancer >>> in a cluster, sticky sessions should be enabled. We might even want to >>> consider adding support for sticky sessions for the code2token flow. >>> The obvious reason is performance. Login can span multiple HTTP >>> requests. If you have N nodes in the cluster with no clustering you >>> have the possibility of the same user being retrieved from the database >>> N times. One time for each authentication request (username/password, >>> OTP page, required actions) and finally for the code 2 token request. >>> Until I look into fixing it the auth SPI does a few extra redirects >>> right now too. >>> >>> Code 2 token could simply have a callback URI so that the code 2 token >>> request hits the same machine the code was created on. >>> >>> >>> >> _______________________________________________ >> 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/20151202/5fc611d4/attachment-0001.html From sthorger at redhat.com Wed Dec 2 10:01:32 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 Dec 2015 16:01:32 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F0716.3060505@redhat.com> References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> Message-ID: On 2 December 2015 at 15:58, Marek Posolda wrote: > btv. we actually have some optimization > "auth-server-url-for-backend-requests" on adapter side. This is useful if > application and Keycloak are both running on same network and using same > cluster nodes. In this case, application can send all backend > (out-of-bound) requests like code2token, refreshToken, to Keycloak > auth-server on same cluster node. > > For example if there is cluster with nodes "node1" and "node2" and > application request is processed on "node1", it will also use "node1" to > directly access Keycloak for out-of-bound requests. So as long as there is > sticky session on application side, it will defacto result in sticky > session for application too. > > Not sure if we need to optimize too much for login. Isn't refresh token > used much more often than login? > If login is multiple requests (username + password, then otp) then a round robin load balancer would quite likely send the rquests to different nodes. > > > Marek > > > > On 02/12/15 15:50, Marek Posolda wrote: > > Not sure if callback URI will work, because application may be able to > see just the loadbalancer node and underlying cluster nodes might be > hidden from it. > > For example if you have callback URI like http://node1:8080/auth/.../token, application may not be able to > directly access host "node1" because it's hidden and application can > access just http://loadbalancer:8080 . > > Marek > > On 02/12/15 15:34, Bill Burke wrote: > > IMO, we need to highlight and document that when using a load balancer > in a cluster, sticky sessions should be enabled. We might even want to > consider adding support for sticky sessions for the code2token flow. > The obvious reason is performance. Login can span multiple HTTP > requests. If you have N nodes in the cluster with no clustering you > have the possibility of the same user being retrieved from the database > N times. One time for each authentication request (username/password, > OTP page, required actions) and finally for the code 2 token request. > Until I look into fixing it the auth SPI does a few extra redirects > right now too. > > Code 2 token could simply have a callback URI so that the code 2 token > request hits the same machine the code was created on. > > > > > _______________________________________________ > 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/20151202/2d20e767/attachment.html From mposolda at redhat.com Wed Dec 2 10:05:00 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 2 Dec 2015 16:05:00 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> Message-ID: <565F089C.3090400@redhat.com> On 02/12/15 16:01, Stian Thorgersen wrote: > > > On 2 December 2015 at 15:58, Marek Posolda > wrote: > > btv. we actually have some optimization > "auth-server-url-for-backend-requests" on adapter side. This is > useful if application and Keycloak are both running on same > network and using same cluster nodes. In this case, application > can send all backend (out-of-bound) requests like code2token, > refreshToken, to Keycloak auth-server on same cluster node. > > For example if there is cluster with nodes "node1" and "node2" and > application request is processed on "node1", it will also use > "node1" to directly access Keycloak for out-of-bound requests. So > as long as there is sticky session on application side, it will > defacto result in sticky session for application too. > > Not sure if we need to optimize too much for login. Isn't refresh > token used much more often than login? > > > If login is multiple requests (username + password, then otp) then a > round robin load balancer would quite likely send the rquests to > different nodes. AFAIK most of loadbalancers are able to understand the cookie (like JSESSIONID ). So if we add the cookie with the node, the loadbalancer will always redirect to same cluster node. Marek > > > Marek > > > > On 02/12/15 15:50, Marek Posolda wrote: >> Not sure if callback URI will work, because application may be able to >> see just the loadbalancer node and underlying cluster nodes might be >> hidden from it. >> >> For example if you have callback URI like >> http://node1:8080/auth/.../token, application may not be able to >> directly access host "node1" because it's hidden and application can >> access justhttp://loadbalancer:8080 . >> >> Marek >> >> On 02/12/15 15:34, Bill Burke wrote: >>> IMO, we need to highlight and document that when using a load balancer >>> in a cluster, sticky sessions should be enabled. We might even want to >>> consider adding support for sticky sessions for the code2token flow. >>> The obvious reason is performance. Login can span multiple HTTP >>> requests. If you have N nodes in the cluster with no clustering you >>> have the possibility of the same user being retrieved from the database >>> N times. One time for each authentication request (username/password, >>> OTP page, required actions) and finally for the code 2 token request. >>> Until I look into fixing it the auth SPI does a few extra redirects >>> right now too. >>> >>> Code 2 token could simply have a callback URI so that the code 2 token >>> request hits the same machine the code was created on. >>> >>> >>> >> _______________________________________________ >> 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/20151202/972810b5/attachment.html From sthorger at redhat.com Wed Dec 2 10:14:01 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 Dec 2015 16:14:01 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F089C.3090400@redhat.com> References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> <565F089C.3090400@redhat.com> Message-ID: We already have KEYCLOAK_SESSION, but that's not created until the user is authenticated On 2 December 2015 at 16:05, Marek Posolda wrote: > On 02/12/15 16:01, Stian Thorgersen wrote: > > > > On 2 December 2015 at 15:58, Marek Posolda wrote: > >> btv. we actually have some optimization >> "auth-server-url-for-backend-requests" on adapter side. This is useful if >> application and Keycloak are both running on same network and using same >> cluster nodes. In this case, application can send all backend >> (out-of-bound) requests like code2token, refreshToken, to Keycloak >> auth-server on same cluster node. >> >> For example if there is cluster with nodes "node1" and "node2" and >> application request is processed on "node1", it will also use "node1" to >> directly access Keycloak for out-of-bound requests. So as long as there is >> sticky session on application side, it will defacto result in sticky >> session for application too. >> >> Not sure if we need to optimize too much for login. Isn't refresh token >> used much more often than login? >> > > If login is multiple requests (username + password, then otp) then a round > robin load balancer would quite likely send the rquests to different nodes. > > AFAIK most of loadbalancers are able to understand the cookie (like > JSESSIONID ). So if we add the cookie with the node, the loadbalancer will > always redirect to same cluster node. > > Marek > > > > >> >> >> Marek >> >> >> >> On 02/12/15 15:50, Marek Posolda wrote: >> >> Not sure if callback URI will work, because application may be able to >> see just the loadbalancer node and underlying cluster nodes might be >> hidden from it. >> >> For example if you have callback URI like http://node1:8080/auth/.../token, application may not be able to >> directly access host "node1" because it's hidden and application can >> access just http://loadbalancer:8080 . >> >> Marek >> >> On 02/12/15 15:34, Bill Burke wrote: >> >> IMO, we need to highlight and document that when using a load balancer >> in a cluster, sticky sessions should be enabled. We might even want to >> consider adding support for sticky sessions for the code2token flow. >> The obvious reason is performance. Login can span multiple HTTP >> requests. If you have N nodes in the cluster with no clustering you >> have the possibility of the same user being retrieved from the database >> N times. One time for each authentication request (username/password, >> OTP page, required actions) and finally for the code 2 token request. >> Until I look into fixing it the auth SPI does a few extra redirects >> right now too. >> >> Code 2 token could simply have a callback URI so that the code 2 token >> request hits the same machine the code was created on. >> >> >> >> >> _______________________________________________ >> 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/20151202/641cf985/attachment-0001.html From mposolda at redhat.com Wed Dec 2 10:31:40 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 2 Dec 2015 16:31:40 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> <565F089C.3090400@redhat.com> Message-ID: <565F0EDC.2040500@redhat.com> Yes, so this might be another cookie. Like KEYCLOAK_LB_SESSION or something. It will be created during first browser HTTP request and doesn't need to have any valuable content, the only point is to use it by loadbalancer, so it can redirect to same node. Like this: - User will send request to Loadbalancer and loadbalancer forwards to Keycloak on node1 - Keycloak returns HTTP Response with username+password form and KEYCLOAK_LB_SESSION cookie with any value (ie. "foo" ) - Loadbalancer attaches the ID of node to cookie. So user will receive the response with cookie KEYCLOAK_LB_SESSION with value "foo.node1" - User confirms the form. Loadbalancer will forward to node1 because of cookie and the form is processed on node1. Similarly all other requests ( OTP etc) Just a quick though, hope I am not missing something obvious :) But for code2token, we don't have good way to enforce it on "node1" as it's out-of-bound request and won't see any cookie set by browser. That's what we discussed couple of times as you mentioned. Marek On 02/12/15 16:14, Stian Thorgersen wrote: > We already have KEYCLOAK_SESSION, but that's not created until the > user is authenticated > > On 2 December 2015 at 16:05, Marek Posolda > wrote: > > On 02/12/15 16:01, Stian Thorgersen wrote: >> >> >> On 2 December 2015 at 15:58, Marek Posolda > > wrote: >> >> btv. we actually have some optimization >> "auth-server-url-for-backend-requests" on adapter side. This >> is useful if application and Keycloak are both running on >> same network and using same cluster nodes. In this case, >> application can send all backend (out-of-bound) requests like >> code2token, refreshToken, to Keycloak auth-server on same >> cluster node. >> >> For example if there is cluster with nodes "node1" and >> "node2" and application request is processed on "node1", it >> will also use "node1" to directly access Keycloak for >> out-of-bound requests. So as long as there is sticky session >> on application side, it will defacto result in sticky session >> for application too. >> >> Not sure if we need to optimize too much for login. Isn't >> refresh token used much more often than login? >> >> >> If login is multiple requests (username + password, then otp) >> then a round robin load balancer would quite likely send the >> rquests to different nodes. > AFAIK most of loadbalancers are able to understand the cookie > (like JSESSIONID ). So if we add the cookie with the node, the > loadbalancer will always redirect to same cluster node. > > Marek > > >> >> >> Marek >> >> >> >> On 02/12/15 15:50, Marek Posolda wrote: >>> Not sure if callback URI will work, because application may be able to >>> see just the loadbalancer node and underlying cluster nodes might be >>> hidden from it. >>> >>> For example if you have callback URI like >>> http://node1:8080/auth/.../token, application may not be able to >>> directly access host "node1" because it's hidden and application can >>> access justhttp://loadbalancer:8080 . >>> >>> Marek >>> >>> On 02/12/15 15:34, Bill Burke wrote: >>>> IMO, we need to highlight and document that when using a load balancer >>>> in a cluster, sticky sessions should be enabled. We might even want to >>>> consider adding support for sticky sessions for the code2token flow. >>>> The obvious reason is performance. Login can span multiple HTTP >>>> requests. If you have N nodes in the cluster with no clustering you >>>> have the possibility of the same user being retrieved from the database >>>> N times. One time for each authentication request (username/password, >>>> OTP page, required actions) and finally for the code 2 token request. >>>> Until I look into fixing it the auth SPI does a few extra redirects >>>> right now too. >>>> >>>> Code 2 token could simply have a callback URI so that the code 2 token >>>> request hits the same machine the code was created on. >>>> >>>> >>>> >>> _______________________________________________ >>> 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/20151202/174a3c6a/attachment.html From bburke at redhat.com Wed Dec 2 10:39:22 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 2 Dec 2015 10:39:22 -0500 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F0EDC.2040500@redhat.com> References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> <565F089C.3090400@redhat.com> <565F0EDC.2040500@redhat.com> Message-ID: <565F10AA.2080306@redhat.com> Why would you need this KEYCLOAK_LB_SESSION cookie? The loadbalancer handles all that automatically. On 12/2/2015 10:31 AM, Marek Posolda wrote: > Yes, so this might be another cookie. Like KEYCLOAK_LB_SESSION or > something. It will be created during first browser HTTP request and > doesn't need to have any valuable content, the only point is to use it > by loadbalancer, so it can redirect to same node. > > Like this: > - User will send request to Loadbalancer and loadbalancer forwards to > Keycloak on node1 > - Keycloak returns HTTP Response with username+password form and > KEYCLOAK_LB_SESSION cookie with any value (ie. "foo" ) > - Loadbalancer attaches the ID of node to cookie. So user will receive > the response with cookie KEYCLOAK_LB_SESSION with value "foo.node1" > - User confirms the form. Loadbalancer will forward to node1 because of > cookie and the form is processed on node1. Similarly all other requests > ( OTP etc) > > Just a quick though, hope I am not missing something obvious :) > > But for code2token, we don't have good way to enforce it on "node1" as > it's out-of-bound request and won't see any cookie set by browser. > That's what we discussed couple of times as you mentioned. > > Marek > > On 02/12/15 16:14, Stian Thorgersen wrote: >> We already have KEYCLOAK_SESSION, but that's not created until the >> user is authenticated >> >> On 2 December 2015 at 16:05, Marek Posolda > > wrote: >> >> On 02/12/15 16:01, Stian Thorgersen wrote: >>> >>> >>> On 2 December 2015 at 15:58, Marek Posolda >>> <mposolda at redhat.com> wrote: >>> >>> btv. we actually have some optimization >>> "auth-server-url-for-backend-requests" on adapter side. This >>> is useful if application and Keycloak are both running on >>> same network and using same cluster nodes. In this case, >>> application can send all backend (out-of-bound) requests like >>> code2token, refreshToken, to Keycloak auth-server on same >>> cluster node. >>> >>> For example if there is cluster with nodes "node1" and >>> "node2" and application request is processed on "node1", it >>> will also use "node1" to directly access Keycloak for >>> out-of-bound requests. So as long as there is sticky session >>> on application side, it will defacto result in sticky session >>> for application too. >>> >>> Not sure if we need to optimize too much for login. Isn't >>> refresh token used much more often than login? >>> >>> >>> If login is multiple requests (username + password, then otp) >>> then a round robin load balancer would quite likely send the >>> rquests to different nodes. >> AFAIK most of loadbalancers are able to understand the cookie >> (like JSESSIONID ). So if we add the cookie with the node, the >> loadbalancer will always redirect to same cluster node. >> >> Marek >> >> >>> >>> >>> Marek >>> >>> >>> >>> On 02/12/15 15:50, Marek Posolda wrote: >>>> Not sure if callback URI will work, because application may be able to >>>> see just the loadbalancer node and underlying cluster nodes might be >>>> hidden from it. >>>> >>>> For example if you have callback URI like >>>> http://node1:8080/auth/.../token, application may not be able to >>>> directly access host "node1" because it's hidden and application can >>>> access justhttp://loadbalancer:8080 . >>>> >>>> Marek >>>> >>>> On 02/12/15 15:34, Bill Burke wrote: >>>>> IMO, we need to highlight and document that when using a load balancer >>>>> in a cluster, sticky sessions should be enabled. We might even want to >>>>> consider adding support for sticky sessions for the code2token flow. >>>>> The obvious reason is performance. Login can span multiple HTTP >>>>> requests. If you have N nodes in the cluster with no clustering you >>>>> have the possibility of the same user being retrieved from the database >>>>> N times. One time for each authentication request (username/password, >>>>> OTP page, required actions) and finally for the code 2 token request. >>>>> Until I look into fixing it the auth SPI does a few extra redirects >>>>> right now too. >>>>> >>>>> Code 2 token could simply have a callback URI so that the code 2 token >>>>> request hits the same machine the code was created on. >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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 Wed Dec 2 11:03:53 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 2 Dec 2015 17:03:53 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F10AA.2080306@redhat.com> References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> <565F089C.3090400@redhat.com> <565F0EDC.2040500@redhat.com> <565F10AA.2080306@redhat.com> Message-ID: <565F1669.8030905@redhat.com> Regarding loadbalancers, I have experience just with modJK and modCluster. Both use cookie to track to which cluster node forward the request. Classic servlet applications usually use JSESSIONID cookie. So when node returns JSESSIONID with the HttpSession ID from servlet application like "1234" , the loadbalancer will attach the ID of node to it. So the user's browser will receive the JSESSIONID cookie with value "1234.node1" . Then when user sends another request to loadbalancer, loadbalancer will read the cookie and it knows that it needs to forward request to "node1" . In Keycloak, we don't have HttpSession and JSESSIONID , but we can use any other cookie ( like KEYCLOAK_LB_SESSION ). AFAIK it's configurable on loadbalancer side, what is the name of the cookie to use. For example in modjk it's the property "session_cookie" . See: https://tomcat.apache.org/connectors-doc/reference/workers.html . Or alternatively we can use the cookie name JSESSIONID to not require configuration changes on loadbalancers, just not sure if it's not too confusing as we don't have real HttpSessions... Marek On 02/12/15 16:39, Bill Burke wrote: > Why would you need this KEYCLOAK_LB_SESSION cookie? The loadbalancer > handles all that automatically. > > On 12/2/2015 10:31 AM, Marek Posolda wrote: >> Yes, so this might be another cookie. Like KEYCLOAK_LB_SESSION or >> something. It will be created during first browser HTTP request and >> doesn't need to have any valuable content, the only point is to use it >> by loadbalancer, so it can redirect to same node. >> >> Like this: >> - User will send request to Loadbalancer and loadbalancer forwards to >> Keycloak on node1 >> - Keycloak returns HTTP Response with username+password form and >> KEYCLOAK_LB_SESSION cookie with any value (ie. "foo" ) >> - Loadbalancer attaches the ID of node to cookie. So user will receive >> the response with cookie KEYCLOAK_LB_SESSION with value "foo.node1" >> - User confirms the form. Loadbalancer will forward to node1 because of >> cookie and the form is processed on node1. Similarly all other requests >> ( OTP etc) >> >> Just a quick though, hope I am not missing something obvious :) >> >> But for code2token, we don't have good way to enforce it on "node1" as >> it's out-of-bound request and won't see any cookie set by browser. >> That's what we discussed couple of times as you mentioned. >> >> Marek >> >> On 02/12/15 16:14, Stian Thorgersen wrote: >>> We already have KEYCLOAK_SESSION, but that's not created until the >>> user is authenticated >>> >>> On 2 December 2015 at 16:05, Marek Posolda >> > wrote: >>> >>> On 02/12/15 16:01, Stian Thorgersen wrote: >>>> >>>> >>>> On 2 December 2015 at 15:58, Marek Posolda >>>> <mposolda at redhat.com> wrote: >>>> >>>> btv. we actually have some optimization >>>> "auth-server-url-for-backend-requests" on adapter side. This >>>> is useful if application and Keycloak are both running on >>>> same network and using same cluster nodes. In this case, >>>> application can send all backend (out-of-bound) requests like >>>> code2token, refreshToken, to Keycloak auth-server on same >>>> cluster node. >>>> >>>> For example if there is cluster with nodes "node1" and >>>> "node2" and application request is processed on "node1", it >>>> will also use "node1" to directly access Keycloak for >>>> out-of-bound requests. So as long as there is sticky session >>>> on application side, it will defacto result in sticky session >>>> for application too. >>>> >>>> Not sure if we need to optimize too much for login. Isn't >>>> refresh token used much more often than login? >>>> >>>> >>>> If login is multiple requests (username + password, then otp) >>>> then a round robin load balancer would quite likely send the >>>> rquests to different nodes. >>> AFAIK most of loadbalancers are able to understand the cookie >>> (like JSESSIONID ). So if we add the cookie with the node, the >>> loadbalancer will always redirect to same cluster node. >>> >>> Marek >>> >>> >>>> >>>> >>>> Marek >>>> >>>> >>>> >>>> On 02/12/15 15:50, Marek Posolda wrote: >>>>> Not sure if callback URI will work, because application >>>>> may be able to >>>>> see just the loadbalancer node and underlying cluster >>>>> nodes might be >>>>> hidden from it. >>>>> >>>>> For example if you have callback URI like >>>>> http://node1:8080/auth/.../token, application may not be >>>>> able to >>>>> directly access host "node1" because it's hidden and >>>>> application can >>>>> access justhttp://loadbalancer:8080 . >>>>> >>>>> Marek >>>>> >>>>> On 02/12/15 15:34, Bill Burke wrote: >>>>>> IMO, we need to highlight and document that when using a >>>>>> load balancer >>>>>> in a cluster, sticky sessions should be enabled. We >>>>>> might even want to >>>>>> consider adding support for sticky sessions for the >>>>>> code2token flow. >>>>>> The obvious reason is performance. Login can span >>>>>> multiple HTTP >>>>>> requests. If you have N nodes in the cluster with no >>>>>> clustering you >>>>>> have the possibility of the same user being retrieved >>>>>> from the database >>>>>> N times. One time for each authentication request >>>>>> (username/password, >>>>>> OTP page, required actions) and finally for the code 2 >>>>>> token request. >>>>>> Until I look into fixing it the auth SPI does a few extra >>>>>> redirects >>>>>> right now too. >>>>>> >>>>>> Code 2 token could simply have a callback URI so that the >>>>>> code 2 token >>>>>> request hits the same machine the code was created on. >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 Wed Dec 2 11:48:57 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 2 Dec 2015 11:48:57 -0500 Subject: [keycloak-dev] in-memory only federated users Message-ID: <565F20F9.6050400@redhat.com> I'm looking into in-memory only no-import federated users. What we would want to do is allow the UserFederationProvider to create an in-memory UserModel and allow for that UserModel to be cached via our current architecture. The current design assumes that all federated users are imported. This includes our caching layer too! To add to that, the user isn't cached until the 2nd request i.e.: 1. username/password page would hit the UserFederationProvider and the user would be imported into Keycloak. This imported user is not cached, only imported into the database for this request's KeycloakSession 2. OTP Page or code 2 token would then want to lookup the user by id as that is what is stored in the ClientSession. It would hit the keycloak database as it is not cached yet. This lookup loads the cache for the user. Getting in-memory zero-import to work is even more tricky. The issue is that ClientSession and UserSession need to lookup clients by id. If the user is not in cache, then the cache needs to lookup the user by id within storage. This lookup also needs to happen if a write operation is performed on a cache user (getDelegateForUpdate()). So, Keycloak needs to know that that ID is not in local storage and must be looked up from a fed provider. The ID must be formed so that the provider fed provider can resolve the lookup. I could use a URI for the ID i.e. fed:{providerId}:{login-name} The problem with this is that this id would need to be larger than 36 characters which is the current column size for UserEntity.id and any other table that references users. I could possibly do: fed:{providerAlias}:{login-name} But its quite possible that combination would be larger than 36 characters. We could also just shrink it to: fed:{login-name} But then we would have to iterate over every federation provider to find and load the user. So in summary: * IDs need to expand from 36 characters to something larger. (255 maybe). Don't some DBs have constraints on string primary key size? DB scripts could possibly be * CachedUserProvider and UserFederationManager interfaces would need to be refactored * I don't think UserFederationProvider interface would need to change. But users would have to code for in-memory rather than throwing a switch to just turn it on. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Wed Dec 2 12:27:39 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Wed, 2 Dec 2015 12:27:39 -0500 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <565F20F9.6050400@redhat.com> References: <565F20F9.6050400@redhat.com> Message-ID: What problem does this solve? It seems like an uncommon use case. Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On Dec 2, 2015, at 11:48 AM, Bill Burke wrote: > > I'm looking into in-memory only no-import federated users. What we > would want to do is allow the UserFederationProvider to create an > in-memory UserModel and allow for that UserModel to be cached via our > current architecture. > > The current design assumes that all federated users are imported. This > includes our caching layer too! To add to that, the user isn't cached > until the 2nd request i.e.: > > 1. username/password page would hit the UserFederationProvider and the > user would be imported into Keycloak. This imported user is not cached, > only imported into the database for this request's KeycloakSession > 2. OTP Page or code 2 token would then want to lookup the user by id as > that is what is stored in the ClientSession. It would hit the keycloak > database as it is not cached yet. This lookup loads the cache for the user. > > Getting in-memory zero-import to work is even more tricky. The issue is > that ClientSession and UserSession need to lookup clients by id. If the > user is not in cache, then the cache needs to lookup the user by id > within storage. This lookup also needs to happen if a write operation > is performed on a cache user (getDelegateForUpdate()). So, Keycloak > needs to know that that ID is not in local storage and must be looked up > from a fed provider. The ID must be formed so that the provider fed > provider can resolve the lookup. I could use a URI for the ID i.e. > > fed:{providerId}:{login-name} > > The problem with this is that this id would need to be larger than 36 > characters which is the current column size for UserEntity.id and any > other table that references users. I could possibly do: > > fed:{providerAlias}:{login-name} > > But its quite possible that combination would be larger than 36 > characters. We could also just shrink it to: > > fed:{login-name} > > But then we would have to iterate over every federation provider to find > and load the user. > > So in summary: > * IDs need to expand from 36 characters to something larger. (255 > maybe). Don't some DBs have constraints on string primary key size? DB > scripts could possibly be > * CachedUserProvider and UserFederationManager interfaces would need to > be refactored > * I don't think UserFederationProvider interface would need to change. > But users would have to code for in-memory rather than throwing a switch > to just turn it on. > > > > -- > 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/20151202/beca2d5f/attachment.html From bburke at redhat.com Wed Dec 2 12:33:07 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 2 Dec 2015 12:33:07 -0500 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: References: <565F20F9.6050400@redhat.com> Message-ID: <565F2B53.2070208@redhat.com> Some are balking at importing every user when doing federation with backends like ldap even though only minimal import is needed (i.e. username/providerID). On 12/2/2015 12:27 PM, Scott Rossillo wrote: > What problem does this solve? It seems like an uncommon use case. > > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > > >> On Dec 2, 2015, at 11:48 AM, Bill Burke > > wrote: >> >> I'm looking into in-memory only no-import federated users. What we >> would want to do is allow the UserFederationProvider to create an >> in-memory UserModel and allow for that UserModel to be cached via our >> current architecture. >> >> The current design assumes that all federated users are imported. This >> includes our caching layer too! To add to that, the user isn't cached >> until the 2nd request i.e.: >> >> 1. username/password page would hit the UserFederationProvider and the >> user would be imported into Keycloak. This imported user is not cached, >> only imported into the database for this request's KeycloakSession >> 2. OTP Page or code 2 token would then want to lookup the user by id as >> that is what is stored in the ClientSession. It would hit the keycloak >> database as it is not cached yet. This lookup loads the cache for the >> user. >> >> Getting in-memory zero-import to work is even more tricky. The issue is >> that ClientSession and UserSession need to lookup clients by id. If the >> user is not in cache, then the cache needs to lookup the user by id >> within storage. This lookup also needs to happen if a write operation >> is performed on a cache user (getDelegateForUpdate()). So, Keycloak >> needs to know that that ID is not in local storage and must be looked up >> from a fed provider. The ID must be formed so that the provider fed >> provider can resolve the lookup. I could use a URI for the ID i.e. >> >> fed:{providerId}:{login-name} >> >> The problem with this is that this id would need to be larger than 36 >> characters which is the current column size for UserEntity.id and any >> other table that references users. I could possibly do: >> >> fed:{providerAlias}:{login-name} >> >> But its quite possible that combination would be larger than 36 >> characters. We could also just shrink it to: >> >> fed:{login-name} >> >> But then we would have to iterate over every federation provider to find >> and load the user. >> >> So in summary: >> * IDs need to expand from 36 characters to something larger. (255 >> maybe). Don't some DBs have constraints on string primary key size? DB >> scripts could possibly be >> * CachedUserProvider and UserFederationManager interfaces would need to >> be refactored >> * I don't think UserFederationProvider interface would need to change. >> But users would have to code for in-memory rather than throwing a switch >> to just turn it on. >> >> >> >> -- >> 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 thomas.raehalme at aitiofinland.com Wed Dec 2 12:37:05 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Wed, 2 Dec 2015 19:37:05 +0200 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <565F2B53.2070208@redhat.com> References: <565F20F9.6050400@redhat.com> <565F2B53.2070208@redhat.com> Message-ID: I think it would also help if you could limit which users are imported when synchronizing with LDAP. If only a small number of enterprise users are going to use the application(s) it doesn't make sense to synchronize them all (could be tens of thousands in total). Best regards, Thomas On Dec 2, 2015 7:33 PM, "Bill Burke" wrote: > Some are balking at importing every user when doing federation with > backends like ldap even though only minimal import is needed (i.e. > username/providerID). > > On 12/2/2015 12:27 PM, Scott Rossillo wrote: > > What problem does this solve? It seems like an uncommon use case. > > > > > > Scott Rossillo > > Smartling | Senior Software Engineer > > srossillo at smartling.com > > > > > >> On Dec 2, 2015, at 11:48 AM, Bill Burke >> > wrote: > >> > >> I'm looking into in-memory only no-import federated users. What we > >> would want to do is allow the UserFederationProvider to create an > >> in-memory UserModel and allow for that UserModel to be cached via our > >> current architecture. > >> > >> The current design assumes that all federated users are imported. This > >> includes our caching layer too! To add to that, the user isn't cached > >> until the 2nd request i.e.: > >> > >> 1. username/password page would hit the UserFederationProvider and the > >> user would be imported into Keycloak. This imported user is not cached, > >> only imported into the database for this request's KeycloakSession > >> 2. OTP Page or code 2 token would then want to lookup the user by id as > >> that is what is stored in the ClientSession. It would hit the keycloak > >> database as it is not cached yet. This lookup loads the cache for the > >> user. > >> > >> Getting in-memory zero-import to work is even more tricky. The issue is > >> that ClientSession and UserSession need to lookup clients by id. If the > >> user is not in cache, then the cache needs to lookup the user by id > >> within storage. This lookup also needs to happen if a write operation > >> is performed on a cache user (getDelegateForUpdate()). So, Keycloak > >> needs to know that that ID is not in local storage and must be looked up > >> from a fed provider. The ID must be formed so that the provider fed > >> provider can resolve the lookup. I could use a URI for the ID i.e. > >> > >> fed:{providerId}:{login-name} > >> > >> The problem with this is that this id would need to be larger than 36 > >> characters which is the current column size for UserEntity.id and any > >> other table that references users. I could possibly do: > >> > >> fed:{providerAlias}:{login-name} > >> > >> But its quite possible that combination would be larger than 36 > >> characters. We could also just shrink it to: > >> > >> fed:{login-name} > >> > >> But then we would have to iterate over every federation provider to find > >> and load the user. > >> > >> So in summary: > >> * IDs need to expand from 36 characters to something larger. (255 > >> maybe). Don't some DBs have constraints on string primary key size? DB > >> scripts could possibly be > >> * CachedUserProvider and UserFederationManager interfaces would need to > >> be refactored > >> * I don't think UserFederationProvider interface would need to change. > >> But users would have to code for in-memory rather than throwing a switch > >> to just turn it on. > >> > >> > >> > >> -- > >> 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/20151202/b65a10ab/attachment-0001.html From sthorger at redhat.com Wed Dec 2 12:46:47 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 Dec 2015 18:46:47 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F1669.8030905@redhat.com> References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> <565F089C.3090400@redhat.com> <565F0EDC.2040500@redhat.com> <565F10AA.2080306@redhat.com> <565F1669.8030905@redhat.com> Message-ID: Wonder if we could do something similar with code 2 token. Could we not set a cookie there as well? Then at most there would be two nodes for one user. Alternative is to update code 2 token so it doesn't require the user model. That would be more elegant. We could do that by making sure user sessions are updated when required if user model changes. On 2 Dec 2015 17:03, "Marek Posolda" wrote: > Regarding loadbalancers, I have experience just with modJK and modCluster. > Both use cookie to track to which cluster node forward the request. > > Classic servlet applications usually use JSESSIONID cookie. So when node > returns JSESSIONID with the HttpSession ID from servlet application like > "1234" , the loadbalancer will attach the ID of node to it. > So the user's browser will receive the JSESSIONID cookie with value > "1234.node1" . Then when user sends another request to loadbalancer, > loadbalancer will read the cookie and it knows that it needs to forward > request to "node1" . > > In Keycloak, we don't have HttpSession and JSESSIONID , but we can use any > other cookie ( like KEYCLOAK_LB_SESSION ). AFAIK it's configurable on > loadbalancer side, what is the name of the cookie to use. For example in > modjk it's the property "session_cookie" . See: > https://tomcat.apache.org/connectors-doc/reference/workers.html . > > Or alternatively we can use the cookie name JSESSIONID to not require > configuration changes on loadbalancers, just not sure if it's not too > confusing as we don't have real HttpSessions... > > Marek > > On 02/12/15 16:39, Bill Burke wrote: > >> Why would you need this KEYCLOAK_LB_SESSION cookie? The loadbalancer >> handles all that automatically. >> >> On 12/2/2015 10:31 AM, Marek Posolda wrote: >> >>> Yes, so this might be another cookie. Like KEYCLOAK_LB_SESSION or >>> something. It will be created during first browser HTTP request and >>> doesn't need to have any valuable content, the only point is to use it >>> by loadbalancer, so it can redirect to same node. >>> >>> Like this: >>> - User will send request to Loadbalancer and loadbalancer forwards to >>> Keycloak on node1 >>> - Keycloak returns HTTP Response with username+password form and >>> KEYCLOAK_LB_SESSION cookie with any value (ie. "foo" ) >>> - Loadbalancer attaches the ID of node to cookie. So user will receive >>> the response with cookie KEYCLOAK_LB_SESSION with value "foo.node1" >>> - User confirms the form. Loadbalancer will forward to node1 because of >>> cookie and the form is processed on node1. Similarly all other requests >>> ( OTP etc) >>> >>> Just a quick though, hope I am not missing something obvious :) >>> >>> But for code2token, we don't have good way to enforce it on "node1" as >>> it's out-of-bound request and won't see any cookie set by browser. >>> That's what we discussed couple of times as you mentioned. >>> >>> Marek >>> >>> On 02/12/15 16:14, Stian Thorgersen wrote: >>> >>>> We already have KEYCLOAK_SESSION, but that's not created until the >>>> user is authenticated >>>> >>>> On 2 December 2015 at 16:05, Marek Posolda >>> > wrote: >>>> >>>> On 02/12/15 16:01, Stian Thorgersen wrote: >>>> >>>>> >>>>> >>>>> On 2 December 2015 at 15:58, Marek Posolda >>>>> <mposolda at redhat.com> wrote: >>>>> >>>>> btv. we actually have some optimization >>>>> "auth-server-url-for-backend-requests" on adapter side. This >>>>> is useful if application and Keycloak are both running on >>>>> same network and using same cluster nodes. In this case, >>>>> application can send all backend (out-of-bound) requests like >>>>> code2token, refreshToken, to Keycloak auth-server on same >>>>> cluster node. >>>>> >>>>> For example if there is cluster with nodes "node1" and >>>>> "node2" and application request is processed on "node1", it >>>>> will also use "node1" to directly access Keycloak for >>>>> out-of-bound requests. So as long as there is sticky session >>>>> on application side, it will defacto result in sticky session >>>>> for application too. >>>>> >>>>> Not sure if we need to optimize too much for login. Isn't >>>>> refresh token used much more often than login? >>>>> >>>>> >>>>> If login is multiple requests (username + password, then otp) >>>>> then a round robin load balancer would quite likely send the >>>>> rquests to different nodes. >>>>> >>>> AFAIK most of loadbalancers are able to understand the cookie >>>> (like JSESSIONID ). So if we add the cookie with the node, the >>>> loadbalancer will always redirect to same cluster node. >>>> >>>> Marek >>>> >>>> >>>> >>>>> >>>>> Marek >>>>> >>>>> >>>>> >>>>> On 02/12/15 15:50, Marek Posolda wrote: >>>>> >>>>>> Not sure if callback URI will work, because application may >>>>>> be able to >>>>>> see just the loadbalancer node and underlying cluster nodes >>>>>> might be >>>>>> hidden from it. >>>>>> >>>>>> For example if you have callback URI like >>>>>> http://node1:8080/auth/.../token, application may not be >>>>>> able to >>>>>> directly access host "node1" because it's hidden and >>>>>> application can >>>>>> access justhttp://loadbalancer:8080 . >>>>>> >>>>>> Marek >>>>>> >>>>>> On 02/12/15 15:34, Bill Burke wrote: >>>>>> >>>>>>> IMO, we need to highlight and document that when using a >>>>>>> load balancer >>>>>>> in a cluster, sticky sessions should be enabled. We might >>>>>>> even want to >>>>>>> consider adding support for sticky sessions for the >>>>>>> code2token flow. >>>>>>> The obvious reason is performance. Login can span multiple >>>>>>> HTTP >>>>>>> requests. If you have N nodes in the cluster with no >>>>>>> clustering you >>>>>>> have the possibility of the same user being retrieved from >>>>>>> the database >>>>>>> N times. One time for each authentication request >>>>>>> (username/password, >>>>>>> OTP page, required actions) and finally for the code 2 token >>>>>>> request. >>>>>>> Until I look into fixing it the auth SPI does a few extra >>>>>>> redirects >>>>>>> right now too. >>>>>>> >>>>>>> Code 2 token could simply have a callback URI so that the >>>>>>> code 2 token >>>>>>> request hits the same machine the code was created on. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>> 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/20151202/b12889c8/attachment.html From bburke at redhat.com Wed Dec 2 12:54:27 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 2 Dec 2015 12:54:27 -0500 Subject: [keycloak-dev] sticky sessions In-Reply-To: References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> <565F089C.3090400@redhat.com> <565F0EDC.2040500@redhat.com> <565F10AA.2080306@redhat.com> <565F1669.8030905@redhat.com> Message-ID: <565F3053.6050208@redhat.com> On 12/2/2015 12:46 PM, Stian Thorgersen wrote: > Wonder if we could do something similar with code 2 token. Could we not > set a cookie there as well? Then at most there would be two nodes for > one user. > > Alternative is to update code 2 token so it doesn't require the user > model. That would be more elegant. We could do that by making sure user > sessions are updated when required if user model changes. > You could optimistically create the token and store it within the client session. But then your overhead is in replication? Then again is replicating a few kilobytes that big of a deal? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Dec 2 12:58:33 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 2 Dec 2015 12:58:33 -0500 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F3053.6050208@redhat.com> References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> <565F089C.3090400@redhat.com> <565F0EDC.2040500@redhat.com> <565F10AA.2080306@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> Message-ID: <565F3149.3030401@redhat.com> On 12/2/2015 12:54 PM, Bill Burke wrote: > > > On 12/2/2015 12:46 PM, Stian Thorgersen wrote: >> Wonder if we could do something similar with code 2 token. Could we not >> set a cookie there as well? Then at most there would be two nodes for >> one user. >> >> Alternative is to update code 2 token so it doesn't require the user >> model. That would be more elegant. We could do that by making sure user >> sessions are updated when required if user model changes. >> > > You could optimistically create the token and store it within the client > session. But then your overhead is in replication? Then again is > replicating a few kilobytes that big of a deal? > Answering my own question...It probabbly isn't a big deal as you are already replicating the client session anyways. Doesn't help refresh token though. Refresh token needs to verify the user is still enabled. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Wed Dec 2 13:25:40 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 Dec 2015 19:25:40 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: <565F3149.3030401@redhat.com> References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> <565F089C.3090400@redhat.com> <565F0EDC.2040500@redhat.com> <565F10AA.2080306@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> Message-ID: We don't replicate the session. It's a distributed cache so it's fetched internally from the correct node. For refresh token maybe we could update the user session for a user that they need to be checked against the user changes? On 2 December 2015 at 18:58, Bill Burke wrote: > > > On 12/2/2015 12:54 PM, Bill Burke wrote: > > > > > > On 12/2/2015 12:46 PM, Stian Thorgersen wrote: > >> Wonder if we could do something similar with code 2 token. Could we not > >> set a cookie there as well? Then at most there would be two nodes for > >> one user. > >> > >> Alternative is to update code 2 token so it doesn't require the user > >> model. That would be more elegant. We could do that by making sure user > >> sessions are updated when required if user model changes. > >> > > > > You could optimistically create the token and store it within the client > > session. But then your overhead is in replication? Then again is > > replicating a few kilobytes that big of a deal? > > > > Answering my own question...It probabbly isn't a big deal as you are > already replicating the client session anyways. > > Doesn't help refresh token though. Refresh token needs to verify the > user is still enabled. > > > -- > 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/20151202/6d736a09/attachment-0001.html From sthorger at redhat.com Wed Dec 2 15:11:42 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 Dec 2015 21:11:42 +0100 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: References: <565F20F9.6050400@redhat.com> <565F2B53.2070208@redhat.com> Message-ID: On 2 December 2015 at 18:37, Thomas Raehalme < thomas.raehalme at aitiofinland.com> wrote: > I think it would also help if you could limit which users are imported > when synchronizing with LDAP. > > If only a small number of enterprise users are going to use the > application(s) it doesn't make sense to synchronize them all (could be tens > of thousands in total). > I think you can already do that, just don't setup the sync and it will pull in users only when they login > Best regards, > Thomas > On Dec 2, 2015 7:33 PM, "Bill Burke" wrote: > >> Some are balking at importing every user when doing federation with >> backends like ldap even though only minimal import is needed (i.e. >> username/providerID). >> >> On 12/2/2015 12:27 PM, Scott Rossillo wrote: >> > What problem does this solve? It seems like an uncommon use case. >> > >> > >> > Scott Rossillo >> > Smartling | Senior Software Engineer >> > srossillo at smartling.com >> > >> > >> >> On Dec 2, 2015, at 11:48 AM, Bill Burke > >> > wrote: >> >> >> >> I'm looking into in-memory only no-import federated users. What we >> >> would want to do is allow the UserFederationProvider to create an >> >> in-memory UserModel and allow for that UserModel to be cached via our >> >> current architecture. >> >> >> >> The current design assumes that all federated users are imported. This >> >> includes our caching layer too! To add to that, the user isn't cached >> >> until the 2nd request i.e.: >> >> >> >> 1. username/password page would hit the UserFederationProvider and the >> >> user would be imported into Keycloak. This imported user is not >> cached, >> >> only imported into the database for this request's KeycloakSession >> >> 2. OTP Page or code 2 token would then want to lookup the user by id as >> >> that is what is stored in the ClientSession. It would hit the keycloak >> >> database as it is not cached yet. This lookup loads the cache for the >> >> user. >> >> >> >> Getting in-memory zero-import to work is even more tricky. The issue >> is >> >> that ClientSession and UserSession need to lookup clients by id. If >> the >> >> user is not in cache, then the cache needs to lookup the user by id >> >> within storage. This lookup also needs to happen if a write operation >> >> is performed on a cache user (getDelegateForUpdate()). So, Keycloak >> >> needs to know that that ID is not in local storage and must be looked >> up >> >> from a fed provider. The ID must be formed so that the provider fed >> >> provider can resolve the lookup. I could use a URI for the ID i.e. >> >> >> >> fed:{providerId}:{login-name} >> >> >> >> The problem with this is that this id would need to be larger than 36 >> >> characters which is the current column size for UserEntity.id and any >> >> other table that references users. I could possibly do: >> >> >> >> fed:{providerAlias}:{login-name} >> >> >> >> But its quite possible that combination would be larger than 36 >> >> characters. We could also just shrink it to: >> >> >> >> fed:{login-name} >> >> >> >> But then we would have to iterate over every federation provider to >> find >> >> and load the user. >> >> >> >> So in summary: >> >> * IDs need to expand from 36 characters to something larger. (255 >> >> maybe). Don't some DBs have constraints on string primary key size? >> DB >> >> scripts could possibly be >> >> * CachedUserProvider and UserFederationManager interfaces would need to >> >> be refactored >> >> * I don't think UserFederationProvider interface would need to change. >> >> But users would have to code for in-memory rather than throwing a >> switch >> >> to just turn it on. >> >> >> >> >> >> >> >> -- >> >> 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 >> > > _______________________________________________ > 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/20151202/28167607/attachment.html From sthorger at redhat.com Wed Dec 2 15:13:59 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 2 Dec 2015 21:13:59 +0100 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <565F20F9.6050400@redhat.com> References: <565F20F9.6050400@redhat.com> Message-ID: IMO this should wait, we have more important things to do right now On 2 December 2015 at 17:48, Bill Burke wrote: > I'm looking into in-memory only no-import federated users. What we > would want to do is allow the UserFederationProvider to create an > in-memory UserModel and allow for that UserModel to be cached via our > current architecture. > > The current design assumes that all federated users are imported. This > includes our caching layer too! To add to that, the user isn't cached > until the 2nd request i.e.: > > 1. username/password page would hit the UserFederationProvider and the > user would be imported into Keycloak. This imported user is not cached, > only imported into the database for this request's KeycloakSession > 2. OTP Page or code 2 token would then want to lookup the user by id as > that is what is stored in the ClientSession. It would hit the keycloak > database as it is not cached yet. This lookup loads the cache for the > user. > > Getting in-memory zero-import to work is even more tricky. The issue is > that ClientSession and UserSession need to lookup clients by id. If the > user is not in cache, then the cache needs to lookup the user by id > within storage. This lookup also needs to happen if a write operation > is performed on a cache user (getDelegateForUpdate()). So, Keycloak > needs to know that that ID is not in local storage and must be looked up > from a fed provider. The ID must be formed so that the provider fed > provider can resolve the lookup. I could use a URI for the ID i.e. > > fed:{providerId}:{login-name} > > The problem with this is that this id would need to be larger than 36 > characters which is the current column size for UserEntity.id and any > other table that references users. I could possibly do: > > fed:{providerAlias}:{login-name} > > But its quite possible that combination would be larger than 36 > characters. We could also just shrink it to: > > fed:{login-name} > > But then we would have to iterate over every federation provider to find > and load the user. > > So in summary: > * IDs need to expand from 36 characters to something larger. (255 > maybe). Don't some DBs have constraints on string primary key size? DB > scripts could possibly be > * CachedUserProvider and UserFederationManager interfaces would need to > be refactored > * I don't think UserFederationProvider interface would need to change. > But users would have to code for in-memory rather than throwing a switch > to just turn it on. > > > > -- > 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/20151202/178c6bf4/attachment.html From ayoung at redhat.com Wed Dec 2 22:53:52 2015 From: ayoung at redhat.com (Adam Young) Date: Wed, 2 Dec 2015 22:53:52 -0500 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <565F20F9.6050400@redhat.com> References: <565F20F9.6050400@redhat.com> Message-ID: <565FBCD0.8010104@redhat.com> On 12/02/2015 11:48 AM, Bill Burke wrote: > I'm looking into in-memory only no-import federated users. What we > would want to do is allow the UserFederationProvider to create an > in-memory UserModel and allow for that UserModel to be cached via our > current architecture. > > The current design assumes that all federated users are imported. This > includes our caching layer too! To add to that, the user isn't cached > until the 2nd request i.e.: > > 1. username/password page would hit the UserFederationProvider and the > user would be imported into Keycloak. This imported user is not cached, > only imported into the database for this request's KeycloakSession > 2. OTP Page or code 2 token would then want to lookup the user by id as > that is what is stored in the ClientSession. It would hit the keycloak > database as it is not cached yet. This lookup loads the cache for the user. > > Getting in-memory zero-import to work is even more tricky. The issue is > that ClientSession and UserSession need to lookup clients by id. If the > user is not in cache, then the cache needs to lookup the user by id > within storage. This lookup also needs to happen if a write operation > is performed on a cache user (getDelegateForUpdate()). So, Keycloak > needs to know that that ID is not in local storage and must be looked up > from a fed provider. The ID must be formed so that the provider fed > provider can resolve the lookup. I could use a URI for the ID i.e. > > fed:{providerId}:{login-name} I'd recommend this, and increasing the size of the Database column. Keystoen did this, but then SHA256 hashed it, makuing it a 64 character string. We found we were OK so long as we stayed under 255, as that was the limit mysql imposed for the string columns. > > The problem with this is that this id would need to be larger than 36 > characters which is the current column size for UserEntity.id and any > other table that references users. I could possibly do: > > fed:{providerAlias}:{login-name} > > But its quite possible that combination would be larger than 36 > characters. We could also just shrink it to: > > fed:{login-name} > > But then we would have to iterate over every federation provider to find > and load the user. It gets trickier: you don;'t want one federation provider to step on the login from an other: ayoung at coke is a different user from ayoung at pepsi. Having the Id be something issued by Keycloak + something that comes from the Federated IdP is necessary. > > So in summary: > * IDs need to expand from 36 characters to something larger. (255 > maybe). Don't some DBs have constraints on string primary key size? DB > scripts could possibly be 255 is your limit. > * CachedUserProvider and UserFederationManager interfaces would need to > be refactored > * I don't think UserFederationProvider interface would need to change. > But users would have to code for in-memory rather than throwing a switch > to just turn it on. I like in memory, but there are many questions to answer, when a user comes back a second time, what happens with their Id. I pushed for ephemeral for Keystone, and we couldn't make it work. > > > From sthorger at redhat.com Thu Dec 3 07:50:49 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 3 Dec 2015 13:50:49 +0100 Subject: [keycloak-dev] Realm cache Message-ID: There's still some outstanding issues with the realm cache. It works, but can and should be improved for 1.8. One issue was that once the realm is updated any methods on clients, roles or groups returns the underlying adapter instead of the cache adapters. As a work around in 1.7 it now ejects all clients for a realm when it sees any changes. We have a few potential ways to solve this: a) try to always return cache adapters - I went down this road attacking it from a few different approaches, but was never successful as there was always something that didn't work b) only cache realms and have everything else hang off it - this is my preferred option for now. As long as updating clients requires invalidating the realm it seems a bit over the top to have separate caches for everything c) make the cache smarter - instead of invalidating a realm, make sure we add/remove the clients, etc.. We also need more automated testing around clustering. Late in 1.7 release process I identified that caches where invalidated when other nodes loaded things to it, so effectively the cache wasn't working at all in a cluster. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151203/9428f2b1/attachment-0001.html From mstrukel at redhat.com Thu Dec 3 08:22:49 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 3 Dec 2015 14:22:49 +0100 Subject: [keycloak-dev] Realm cache In-Reply-To: References: Message-ID: +1 for testing the clustering, but it will take some time to develop that unless someone already started on it. Maybe by using Arquillian Cube in combination with keycloak-ha-postgres ... On Thu, Dec 3, 2015 at 1:50 PM, Stian Thorgersen wrote: > There's still some outstanding issues with the realm cache. It works, but > can and should be improved for 1.8. > > One issue was that once the realm is updated any methods on clients, roles > or groups returns the underlying adapter instead of the cache adapters. As > a work around in 1.7 it now ejects all clients for a realm when it sees any > changes. > > We have a few potential ways to solve this: > > a) try to always return cache adapters - I went down this road attacking > it from a few different approaches, but was never successful as there was > always something that didn't work > b) only cache realms and have everything else hang off it - this is my > preferred option for now. As long as updating clients requires invalidating > the realm it seems a bit over the top to have separate caches for everything > c) make the cache smarter - instead of invalidating a realm, make sure we > add/remove the clients, etc.. > > We also need more automated testing around clustering. Late in 1.7 release > process I identified that caches where invalidated when other nodes loaded > things to it, so effectively the cache wasn't working at all in a cluster. > > Thoughts? > > _______________________________________________ > 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/20151203/ffc06ab2/attachment.html From sthorger at redhat.com Thu Dec 3 08:29:17 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 3 Dec 2015 14:29:17 +0100 Subject: [keycloak-dev] Realm cache In-Reply-To: References: Message-ID: One main issue with testing the cluster is identifying when something is loaded from cache instead of db. On 3 December 2015 at 14:22, Marko Strukelj wrote: > +1 for testing the clustering, but it will take some time to develop that > unless someone already started on it. > > Maybe by using Arquillian Cube in combination with keycloak-ha-postgres ... > > On Thu, Dec 3, 2015 at 1:50 PM, Stian Thorgersen > wrote: > >> There's still some outstanding issues with the realm cache. It works, but >> can and should be improved for 1.8. >> >> One issue was that once the realm is updated any methods on clients, >> roles or groups returns the underlying adapter instead of the cache >> adapters. As a work around in 1.7 it now ejects all clients for a realm >> when it sees any changes. >> >> We have a few potential ways to solve this: >> >> a) try to always return cache adapters - I went down this road attacking >> it from a few different approaches, but was never successful as there was >> always something that didn't work >> b) only cache realms and have everything else hang off it - this is my >> preferred option for now. As long as updating clients requires invalidating >> the realm it seems a bit over the top to have separate caches for everything >> c) make the cache smarter - instead of invalidating a realm, make sure we >> add/remove the clients, etc.. >> >> We also need more automated testing around clustering. Late in 1.7 >> release process I identified that caches where invalidated when other nodes >> loaded things to it, so effectively the cache wasn't working at all in a >> cluster. >> >> Thoughts? >> >> _______________________________________________ >> 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/20151203/7055b914/attachment.html From bburke at redhat.com Thu Dec 3 10:10:07 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 3 Dec 2015 10:10:07 -0500 Subject: [keycloak-dev] Realm cache In-Reply-To: References: Message-ID: <56605B4F.4060403@redhat.com> On 12/3/2015 7:50 AM, Stian Thorgersen wrote: > There's still some outstanding issues with the realm cache. It works, > but can and should be improved for 1.8. > > One issue was that once the realm is updated any methods on clients, > roles or groups returns the underlying adapter instead of the cache > adapters. As a work around in 1.7 it now ejects all clients for a realm > when it sees any changes. > Why is that a bad thing? Usually, roles groups, and clients are not accessed in the same session as a realm update. Realms are usually not updated. Client registration/unregistration is rare too for most apps. The vast majority (90%+?) of access is read-only for realms and clients. > We have a few potential ways to solve this: > > a) try to always return cache adapters - I went down this road attacking > it from a few different approaches, but was never successful as there > was always something that didn't work See above, I don't think this is an issue. What we should do is identify if any updates are performed on realms/clients per login/token refresh and remove or isolate them so that the realm/client caches aren't invalidated. > b) only cache realms and have everything else hang off it - this is my > preferred option for now. As long as updating clients requires > invalidating the realm it seems a bit over the top to have separate > caches for everything Why can't you keep it as it is? RealmAdapter.getDelegateForUpdate() always registers a realm invalidation. add/remove client are methods on RealmModel so the realm cache was always invalidated. The only time you need to invalidate the realm is when clientId is changed. > c) make the cache smarter - instead of invalidating a realm, make sure > we add/remove the clients, etc.. > Its an invalidation cache, so "C" won't work unless you have a separate cache for the client list. So you'd need a realm cache, client list cache, and client cache. > We also need more automated testing around clustering. Late in 1.7 > release process I identified that caches where invalidated when other > nodes loaded things to it, so effectively the cache wasn't working at > all in a cluster. > > Thoughts? > I think this is a bit of effort for little gain. users will only see a difference if there is a lot of realm adminstration happening. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Thu Dec 3 10:29:22 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 3 Dec 2015 10:29:22 -0500 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <565FBCD0.8010104@redhat.com> References: <565F20F9.6050400@redhat.com> <565FBCD0.8010104@redhat.com> Message-ID: <56605FD2.8090607@redhat.com> On 12/2/2015 10:53 PM, Adam Young wrote: >> Getting in-memory zero-import to work is even more tricky. The issue is >> that ClientSession and UserSession need to lookup clients by id. If the >> user is not in cache, then the cache needs to lookup the user by id >> within storage. This lookup also needs to happen if a write operation >> is performed on a cache user (getDelegateForUpdate()). So, Keycloak >> needs to know that that ID is not in local storage and must be looked up >> from a fed provider. The ID must be formed so that the provider fed >> provider can resolve the lookup. I could use a URI for the ID i.e. >> >> fed:{providerId}:{login-name} > > I'd recommend this, and increasing the size of the Database column. > We have many deployments already and some have quite large user databases. Was really concerned that expanding the column size would piss a lot of people off because of the DB migration required. We were talking a few weeks ago about ALL of our IDs becoming URIs. roles, groups, realms, clients, etc. It would give us the flexibility of federating anything we wanted going further. For example, currently admins have to define roles and groups in keycloak. This sucks if they are already defined and controlled someplace else. > Keystoen did this, but then SHA256 hashed it, makuing it a 64 character > string. We found we were OK so long as we stayed under 255, as that was > the limit mysql imposed for the string columns. > >> >> The problem with this is that this id would need to be larger than 36 >> characters which is the current column size for UserEntity.id and any >> other table that references users. I could possibly do: >> >> fed:{providerAlias}:{login-name} >> >> But its quite possible that combination would be larger than 36 >> characters. We could also just shrink it to: >> >> fed:{login-name} >> >> But then we would have to iterate over every federation provider to find >> and load the user. > > It gets trickier: you don;'t want one federation provider to step on > the login from an other: ayoung at coke is a different user from > ayoung at pepsi. Having the Id be something issued by Keycloak + something > that comes from the Federated IdP is necessary. > Not really. This is no different than a user logging into the user/password screen. Keycloak allows you to specify the order of federation providers, but doesn't handle conflicts, i.e. one LDAP server has the same username as another. > > I like in memory, but there are many questions to answer, when a user > comes back a second time, what happens with their Id. I pushed for > ephemeral for Keystone, and we couldn't make it work. > We track sessions, have offline sessions, and track consents. So an ID cannot be temporary. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Thu Dec 3 10:32:22 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 3 Dec 2015 16:32:22 +0100 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <565F20F9.6050400@redhat.com> References: <565F20F9.6050400@redhat.com> Message-ID: <56606086.6010908@redhat.com> IMO the more important use-case that in-memory federated users is the caching of federated users. Currently if you call: session.users().getUserById() and the user with ID "123" is LDAP (or other federationProvider) user, there is always call to UserFederationProvider.validateAndProxy , which results in LDAP query. If we introduce the chaining of UserProvider (something I already proposed earlier), you can switch UserFederationProvider with cache, so you will have: cache => userFederationManager => JPA instead of current: userFederationManager => cache => JPA With that in mind, we can easily implement in-memory as another implementation of UserProvider, which will hold users purely in-memory. Our current DefaultCacheUserProvider always require delegate to call write operations. But this in-memory provider would be something different. It won't use any delegate as it will be in the end of the chain. So for in-memory federation you will just configure: userFederationManager => inMemoryProvider and you're done. No needs for special ID handling or something like that. With chaining of UserProvider we have biggest flexibility for various needs IMO. That's why I would rather go this way TBH. Marek On 02/12/15 17:48, Bill Burke wrote: > I'm looking into in-memory only no-import federated users. What we > would want to do is allow the UserFederationProvider to create an > in-memory UserModel and allow for that UserModel to be cached via our > current architecture. > > The current design assumes that all federated users are imported. This > includes our caching layer too! To add to that, the user isn't cached > until the 2nd request i.e.: > > 1. username/password page would hit the UserFederationProvider and the > user would be imported into Keycloak. This imported user is not cached, > only imported into the database for this request's KeycloakSession > 2. OTP Page or code 2 token would then want to lookup the user by id as > that is what is stored in the ClientSession. It would hit the keycloak > database as it is not cached yet. This lookup loads the cache for the user. > > Getting in-memory zero-import to work is even more tricky. The issue is > that ClientSession and UserSession need to lookup clients by id. If the > user is not in cache, then the cache needs to lookup the user by id > within storage. This lookup also needs to happen if a write operation > is performed on a cache user (getDelegateForUpdate()). So, Keycloak > needs to know that that ID is not in local storage and must be looked up > from a fed provider. The ID must be formed so that the provider fed > provider can resolve the lookup. I could use a URI for the ID i.e. > > fed:{providerId}:{login-name} > > The problem with this is that this id would need to be larger than 36 > characters which is the current column size for UserEntity.id and any > other table that references users. I could possibly do: > > fed:{providerAlias}:{login-name} > > But its quite possible that combination would be larger than 36 > characters. We could also just shrink it to: > > fed:{login-name} > > But then we would have to iterate over every federation provider to find > and load the user. > > So in summary: > * IDs need to expand from 36 characters to something larger. (255 > maybe). Don't some DBs have constraints on string primary key size? DB > scripts could possibly be > * CachedUserProvider and UserFederationManager interfaces would need to > be refactored > * I don't think UserFederationProvider interface would need to change. > But users would have to code for in-memory rather than throwing a switch > to just turn it on. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151203/69eb17d9/attachment-0001.html From sthorger at redhat.com Thu Dec 3 10:56:01 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 3 Dec 2015 16:56:01 +0100 Subject: [keycloak-dev] Keycloak 1.7.0.CR1 Released Message-ID: I'm pleased to announce the release of Keycloak 1.7.0.CR1. Recently we've gone straight to Final, but we'd like to give everyone a chance to try a release out first. Unless there are major issues reported we will release Final next week. As usual we've been far from idle and have a number of highlights in this release, including: - *Groups* - users can belong to one or more groups and inherit role mappings and attributes from the group. - *First Broker Login Flow* - we've introduced a number of improvements to first login with identity brokers as well as the ability to customize the flow used. - *Client Registration* - clients can now dynamically register themselves with a Keycloak server. This supports Keycloak client representations, OpenID Connect Dynamic Client Registration and SAML Entity Descriptors. Client registration are simple REST endpoints, there's also a Java library and a CLI is coming soon. - *OpenID Connect Implicit and Hybrid flows* - we've added support for the Implicit and Hybrid flows. It's also possible to select what flows are available for a specific client. - *Add User script* - as a first step to not having a default admin user we've added a script that allows creating an initial admin account. - *Cache fixes* - there's a number of fixes related to caching, which should improve performance especially in clusters. - *Email Sender SPI* - previously we had one SPI that created email content from FreeMarker and also sent emails. We've now split this into two separate SPIs. - *SAML SP WildFly subsystem* - there's now a WildFly subsystem for the SAML SP adapter, which makes it easier to use the SAML SP adapter on WildFly. - *WildFly 10 adapter support* - the WildFly adapter, including adapter subsystem, now supports WildFly 10. 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/20151203/29ae818e/attachment.html From bburke at redhat.com Thu Dec 3 10:57:39 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 3 Dec 2015 10:57:39 -0500 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <56606086.6010908@redhat.com> References: <565F20F9.6050400@redhat.com> <56606086.6010908@redhat.com> Message-ID: <56606673.9070502@redhat.com> Either we redo the federation SPI or work with the current one. It is just not as simple as you state. You can't just chain in a generic InMemoryProvider. Federation needs to be able to proxy the UserModel so that it can handle write methods if it wants to. Or delegate lookup of certain things to LDAP. Also, UserFederationManager has to be first in the chain so that if something is found in cache, it can let the federation provider proxy the cache if it wants to. What we need is a special interface for the cache: cache.cacheUser(UserModel user); The cache would also work with UserFederationManager rather than a generic UserProvider. UserFederationManager would gain methods like: UserFederationManager.getUncachedUserById() which the cache would invoke. UserFederationManager would break down the user id and either know it was local storage or something that would have to be delegated to a UserProvider. On 12/3/2015 10:32 AM, Marek Posolda wrote: > IMO the more important use-case that in-memory federated users is the > caching of federated users. > > Currently if you call: session.users().getUserById() and the user with > ID "123" is LDAP (or other federationProvider) user, there is always > call to UserFederationProvider.validateAndProxy , which results in LDAP > query. > > If we introduce the chaining of UserProvider (something I already > proposed earlier), you can switch UserFederationProvider with cache, so > you will have: > cache => userFederationManager => JPA > > instead of current: > > userFederationManager => cache => JPA > > > With that in mind, we can easily implement in-memory as another > implementation of UserProvider, which will hold users purely in-memory. > Our current DefaultCacheUserProvider always require delegate to call > write operations. But this in-memory provider would be something > different. It won't use any delegate as it will be in the end of the > chain. So for in-memory federation you will just configure: > > userFederationManager => inMemoryProvider > > and you're done. No needs for special ID handling or something like that. > > With chaining of UserProvider we have biggest flexibility for various > needs IMO. That's why I would rather go this way TBH. > Marek > > On 02/12/15 17:48, Bill Burke wrote: >> I'm looking into in-memory only no-import federated users. What we >> would want to do is allow the UserFederationProvider to create an >> in-memory UserModel and allow for that UserModel to be cached via our >> current architecture. >> >> The current design assumes that all federated users are imported. This >> includes our caching layer too! To add to that, the user isn't cached >> until the 2nd request i.e.: >> >> 1. username/password page would hit the UserFederationProvider and the >> user would be imported into Keycloak. This imported user is not cached, >> only imported into the database for this request's KeycloakSession >> 2. OTP Page or code 2 token would then want to lookup the user by id as >> that is what is stored in the ClientSession. It would hit the keycloak >> database as it is not cached yet. This lookup loads the cache for the user. >> >> Getting in-memory zero-import to work is even more tricky. The issue is >> that ClientSession and UserSession need to lookup clients by id. If the >> user is not in cache, then the cache needs to lookup the user by id >> within storage. This lookup also needs to happen if a write operation >> is performed on a cache user (getDelegateForUpdate()). So, Keycloak >> needs to know that that ID is not in local storage and must be looked up >> from a fed provider. The ID must be formed so that the provider fed >> provider can resolve the lookup. I could use a URI for the ID i.e. >> >> fed:{providerId}:{login-name} >> >> The problem with this is that this id would need to be larger than 36 >> characters which is the current column size for UserEntity.id and any >> other table that references users. I could possibly do: >> >> fed:{providerAlias}:{login-name} >> >> But its quite possible that combination would be larger than 36 >> characters. We could also just shrink it to: >> >> fed:{login-name} >> >> But then we would have to iterate over every federation provider to find >> and load the user. >> >> So in summary: >> * IDs need to expand from 36 characters to something larger. (255 >> maybe). Don't some DBs have constraints on string primary key size? DB >> scripts could possibly be >> * CachedUserProvider and UserFederationManager interfaces would need to >> be refactored >> * I don't think UserFederationProvider interface would need to change. >> But users would have to code for in-memory rather than throwing a switch >> to just turn it on. >> >> >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Thu Dec 3 11:59:22 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 3 Dec 2015 17:59:22 +0100 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <56606673.9070502@redhat.com> References: <565F20F9.6050400@redhat.com> <56606086.6010908@redhat.com> <56606673.9070502@redhat.com> Message-ID: <566074EA.3060408@redhat.com> On 03/12/15 16:57, Bill Burke wrote: > Either we redo the federation SPI or work with the current one. > > It is just not as simple as you state. You can't just chain in a > generic InMemoryProvider. Federation needs to be able to proxy the > UserModel so that it can handle write methods if it wants to. Or > delegate lookup of certain things to LDAP. I am not seeing why it's an issue? The InMemory will be kind of same thing like currently JPA. It just won't store the things into database, but into memory. That's the only difference. It will just be the provider at the end of the chain. UserFederationManager can proxy users exactly like now and doesn't require any code changes. So when admin configure: userFederationMAnager => inMemory The call of "session.userStorage()" from UserFederationManager will return underlying InMemory instead of current JPA. > Also, UserFederationManager has to be first in the chain so that if > something is found in cache, it can let the federation provider proxy > the cache if it wants to. That's not a problem as well. What I mean is the flexibility to configure things exactly how you want for various cases. 3 basic setups: 1. userFederation => cache => JPA This is what we have now and it will be the default setup. It 's useful for deployments when admins are often doing changes directly in their LDAP and they want the change imediatelly visible in Keycloak. So the UserFederationProvider proxy is always the top and when you call: user.getFirstName() you will retrieve the firstName from LDAP. The disadvantage of this setup is performance (each HTTP request needs to query LDAP like it's now) 2. cache => userFederation => JPA This will be useful for deployments when amins are not doing changes directly in their LDAP. So once you retrieve the user from LDAP+KeycloakDB, you will save him to cache and call to: user.getFirstName() will always return the value from cache. Hence when admin changes directly in LDAP, it won't be immediately visible in Keycloak. But on the other hand update from Keycloak to LDAP is not an issue. When you call: user.setFirstName("foo") the cache will call getDelegateForUpdate (exactly like now) and it will return proxy object, so the saving of firstName is propagated to LDAP (if it's writable) and to Keycloak JPA DB as well. 3. userFederation => inMemory The federation backed by pure in-memory storage. The federation proxy is on top, writing and reading to/from LDAP is not a problem and has preference over the content from memory. The only difference from (1) is that underlying backend is pure memory (infinispan) instead of JPA DB There is also alternative to use combination of 2 and 3: cache => userFederation => inMemory etc etc. I can see this as most flexible approach without dependencies of various providers on each other. Marek > > What we need is a special interface for the cache: > > cache.cacheUser(UserModel user); > > The cache would also work with UserFederationManager rather than a > generic UserProvider. UserFederationManager would gain methods like: > UserFederationManager.getUncachedUserById() which the cache would > invoke. UserFederationManager would break down the user id and either > know it was local storage or something that would have to be delegated > to a UserProvider. > > > > > > On 12/3/2015 10:32 AM, Marek Posolda wrote: >> IMO the more important use-case that in-memory federated users is the >> caching of federated users. >> >> Currently if you call: session.users().getUserById() and the user with >> ID "123" is LDAP (or other federationProvider) user, there is always >> call to UserFederationProvider.validateAndProxy , which results in LDAP >> query. >> >> If we introduce the chaining of UserProvider (something I already >> proposed earlier), you can switch UserFederationProvider with cache, so >> you will have: >> cache => userFederationManager => JPA >> >> instead of current: >> >> userFederationManager => cache => JPA >> >> >> With that in mind, we can easily implement in-memory as another >> implementation of UserProvider, which will hold users purely in-memory. >> Our current DefaultCacheUserProvider always require delegate to call >> write operations. But this in-memory provider would be something >> different. It won't use any delegate as it will be in the end of the >> chain. So for in-memory federation you will just configure: >> >> userFederationManager => inMemoryProvider >> >> and you're done. No needs for special ID handling or something like >> that. >> >> With chaining of UserProvider we have biggest flexibility for various >> needs IMO. That's why I would rather go this way TBH. >> Marek >> >> On 02/12/15 17:48, Bill Burke wrote: >>> I'm looking into in-memory only no-import federated users. What we >>> would want to do is allow the UserFederationProvider to create an >>> in-memory UserModel and allow for that UserModel to be cached via our >>> current architecture. >>> >>> The current design assumes that all federated users are imported. This >>> includes our caching layer too! To add to that, the user isn't cached >>> until the 2nd request i.e.: >>> >>> 1. username/password page would hit the UserFederationProvider and the >>> user would be imported into Keycloak. This imported user is not >>> cached, >>> only imported into the database for this request's KeycloakSession >>> 2. OTP Page or code 2 token would then want to lookup the user by id as >>> that is what is stored in the ClientSession. It would hit the keycloak >>> database as it is not cached yet. This lookup loads the cache for >>> the user. >>> >>> Getting in-memory zero-import to work is even more tricky. The issue is >>> that ClientSession and UserSession need to lookup clients by id. If >>> the >>> user is not in cache, then the cache needs to lookup the user by id >>> within storage. This lookup also needs to happen if a write operation >>> is performed on a cache user (getDelegateForUpdate()). So, Keycloak >>> needs to know that that ID is not in local storage and must be >>> looked up >>> from a fed provider. The ID must be formed so that the provider fed >>> provider can resolve the lookup. I could use a URI for the ID i.e. >>> >>> fed:{providerId}:{login-name} >>> >>> The problem with this is that this id would need to be larger than 36 >>> characters which is the current column size for UserEntity.id and any >>> other table that references users. I could possibly do: >>> >>> fed:{providerAlias}:{login-name} >>> >>> But its quite possible that combination would be larger than 36 >>> characters. We could also just shrink it to: >>> >>> fed:{login-name} >>> >>> But then we would have to iterate over every federation provider to >>> find >>> and load the user. >>> >>> So in summary: >>> * IDs need to expand from 36 characters to something larger. (255 >>> maybe). Don't some DBs have constraints on string primary key >>> size? DB >>> scripts could possibly be >>> * CachedUserProvider and UserFederationManager interfaces would need to >>> be refactored >>> * I don't think UserFederationProvider interface would need to change. >>> But users would have to code for in-memory rather than throwing a >>> switch >>> to just turn it on. >>> >>> >>> >> > From mposolda at redhat.com Thu Dec 3 12:08:17 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 3 Dec 2015 18:08:17 +0100 Subject: [keycloak-dev] sticky sessions In-Reply-To: References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> <565F089C.3090400@redhat.com> <565F0EDC.2040500@redhat.com> <565F10AA.2080306@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> Message-ID: <56607701.7050900@redhat.com> How about protocolMappers? If there were no changes to user, the refreshToken endpoint won't call protocolMappers but just use user data from previously saved cached token from userSession? Marek On 02/12/15 19:25, Stian Thorgersen wrote: > We don't replicate the session. It's a distributed cache so it's > fetched internally from the correct node. > > For refresh token maybe we could update the user session for a user > that they need to be checked against the user changes? > > On 2 December 2015 at 18:58, Bill Burke > wrote: > > > > On 12/2/2015 12:54 PM, Bill Burke wrote: > > > > > > On 12/2/2015 12:46 PM, Stian Thorgersen wrote: > >> Wonder if we could do something similar with code 2 token. > Could we not > >> set a cookie there as well? Then at most there would be two > nodes for > >> one user. > >> > >> Alternative is to update code 2 token so it doesn't require the > user > >> model. That would be more elegant. We could do that by making > sure user > >> sessions are updated when required if user model changes. > >> > > > > You could optimistically create the token and store it within > the client > > session. But then your overhead is in replication? Then again is > > replicating a few kilobytes that big of a deal? > > > > Answering my own question...It probabbly isn't a big deal as you are > already replicating the client session anyways. > > Doesn't help refresh token though. Refresh token needs to verify the > user is still enabled. > > > -- > 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/20151203/41c64364/attachment-0001.html From bburke at redhat.com Thu Dec 3 12:58:03 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 3 Dec 2015 12:58:03 -0500 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <566074EA.3060408@redhat.com> References: <565F20F9.6050400@redhat.com> <56606086.6010908@redhat.com> <56606673.9070502@redhat.com> <566074EA.3060408@redhat.com> Message-ID: <566082AB.7070902@redhat.com> Still don't think it is as simple as you state. We don't need an "in memory" provider. We want UserFederationProvider to create a temporary request/only in-memory UserModel for federation providers that don't want to import. This UserModel may be proxied for any write operations. My current thinking is that we change the flow from: UserFederationManager=>CacheProvider=>UserProvider to CacheProvider->UserFederationManager->UserProvider/UserFederationProvider KeycloakSession changes: * users() returns the CacheUserProvider instead of UserFederationManager * userStorage() is not changed * federationManager() returns UserFederationManager UserCacheProvider changes: * Gets a new method cache(UserModel user); * References UserFederationManager instead of the DB provider directly UserFederationManager changes: * Instead of calling userStorage(), it gets the DB provider directly UserFederationProvider: * Imports using userStorage() or, allocates a new class InMemoryUserModel (or extension of that class). This class is just an in memory implementation of UserModel * Returns the imported UserModel or the InMemoryUserModel So session.users().getUserByXXXX() does the folloing: 1. UserCacheProvider.getUserByXXX is invoked 2. It looks looks in cache, if found return 3. invoke UserFederationManager.getUserByXXX 4. If UserFederationManager finds it return UserModel 5. Look in UserFederationProvider 6. UserFederationProvider imports or returns InMemoryUserModel 7. UserCacheProvider.getUserByXXX caches the user. cache.UserAdapter.getDelegateForUpdate() does the following: 1. invokes UserFederationManager.getUserById() 2. ID is parsed to see if it is a federated ID or not (see original post) Alternatively, we could just invoke userFederationManager.getUserByusername() since username can't be null. On 12/3/2015 11:59 AM, Marek Posolda wrote: > On 03/12/15 16:57, Bill Burke wrote: >> Either we redo the federation SPI or work with the current one. >> >> It is just not as simple as you state. You can't just chain in a >> generic InMemoryProvider. Federation needs to be able to proxy the >> UserModel so that it can handle write methods if it wants to. Or >> delegate lookup of certain things to LDAP. > I am not seeing why it's an issue? The InMemory will be kind of same > thing like currently JPA. It just won't store the things into database, > but into memory. That's the only difference. It will just be the > provider at the end of the chain. UserFederationManager can proxy users > exactly like now and doesn't require any code changes. > > So when admin configure: > > userFederationMAnager => inMemory > > The call of "session.userStorage()" from UserFederationManager will > return underlying InMemory instead of current JPA. > >> Also, UserFederationManager has to be first in the chain so that if >> something is found in cache, it can let the federation provider proxy >> the cache if it wants to. > That's not a problem as well. > > What I mean is the flexibility to configure things exactly how you want > for various cases. > > 3 basic setups: > > 1. userFederation => cache => JPA > > This is what we have now and it will be the default setup. It 's useful > for deployments when admins are often doing changes directly in their > LDAP and they want the change imediatelly visible in Keycloak. So the > UserFederationProvider proxy is always the top and when you call: > > user.getFirstName() > > you will retrieve the firstName from LDAP. The disadvantage of this > setup is performance (each HTTP request needs to query LDAP like it's now) > > > 2. cache => userFederation => JPA > > This will be useful for deployments when amins are not doing changes > directly in their LDAP. So once you retrieve the user from > LDAP+KeycloakDB, you will save him to cache and call to: > > user.getFirstName() > > will always return the value from cache. Hence when admin changes > directly in LDAP, it won't be immediately visible in Keycloak. > > But on the other hand update from Keycloak to LDAP is not an issue. When > you call: > > user.setFirstName("foo") > > the cache will call getDelegateForUpdate (exactly like now) and it will > return proxy object, so the saving of firstName is propagated to LDAP > (if it's writable) and to Keycloak JPA DB as well. > > > 3. userFederation => inMemory > > The federation backed by pure in-memory storage. The federation proxy is > on top, writing and reading to/from LDAP is not a problem and has > preference over the content from memory. The only difference from (1) is > that underlying backend is pure memory (infinispan) instead of JPA DB > > There is also alternative to use combination of 2 and 3: > cache => userFederation => inMemory > > etc etc. > > > I can see this as most flexible approach without dependencies of various > providers on each other. > > Marek >> >> What we need is a special interface for the cache: >> >> cache.cacheUser(UserModel user); >> >> The cache would also work with UserFederationManager rather than a >> generic UserProvider. UserFederationManager would gain methods like: >> UserFederationManager.getUncachedUserById() which the cache would >> invoke. UserFederationManager would break down the user id and either >> know it was local storage or something that would have to be delegated >> to a UserProvider. >> >> >> >> >> >> On 12/3/2015 10:32 AM, Marek Posolda wrote: >>> IMO the more important use-case that in-memory federated users is the >>> caching of federated users. >>> >>> Currently if you call: session.users().getUserById() and the user with >>> ID "123" is LDAP (or other federationProvider) user, there is always >>> call to UserFederationProvider.validateAndProxy , which results in LDAP >>> query. >>> >>> If we introduce the chaining of UserProvider (something I already >>> proposed earlier), you can switch UserFederationProvider with cache, so >>> you will have: >>> cache => userFederationManager => JPA >>> >>> instead of current: >>> >>> userFederationManager => cache => JPA >>> >>> >>> With that in mind, we can easily implement in-memory as another >>> implementation of UserProvider, which will hold users purely in-memory. >>> Our current DefaultCacheUserProvider always require delegate to call >>> write operations. But this in-memory provider would be something >>> different. It won't use any delegate as it will be in the end of the >>> chain. So for in-memory federation you will just configure: >>> >>> userFederationManager => inMemoryProvider >>> >>> and you're done. No needs for special ID handling or something like >>> that. >>> >>> With chaining of UserProvider we have biggest flexibility for various >>> needs IMO. That's why I would rather go this way TBH. >>> Marek >>> >>> On 02/12/15 17:48, Bill Burke wrote: >>>> I'm looking into in-memory only no-import federated users. What we >>>> would want to do is allow the UserFederationProvider to create an >>>> in-memory UserModel and allow for that UserModel to be cached via our >>>> current architecture. >>>> >>>> The current design assumes that all federated users are imported. This >>>> includes our caching layer too! To add to that, the user isn't cached >>>> until the 2nd request i.e.: >>>> >>>> 1. username/password page would hit the UserFederationProvider and the >>>> user would be imported into Keycloak. This imported user is not >>>> cached, >>>> only imported into the database for this request's KeycloakSession >>>> 2. OTP Page or code 2 token would then want to lookup the user by id as >>>> that is what is stored in the ClientSession. It would hit the keycloak >>>> database as it is not cached yet. This lookup loads the cache for >>>> the user. >>>> >>>> Getting in-memory zero-import to work is even more tricky. The issue is >>>> that ClientSession and UserSession need to lookup clients by id. If >>>> the >>>> user is not in cache, then the cache needs to lookup the user by id >>>> within storage. This lookup also needs to happen if a write operation >>>> is performed on a cache user (getDelegateForUpdate()). So, Keycloak >>>> needs to know that that ID is not in local storage and must be >>>> looked up >>>> from a fed provider. The ID must be formed so that the provider fed >>>> provider can resolve the lookup. I could use a URI for the ID i.e. >>>> >>>> fed:{providerId}:{login-name} >>>> >>>> The problem with this is that this id would need to be larger than 36 >>>> characters which is the current column size for UserEntity.id and any >>>> other table that references users. I could possibly do: >>>> >>>> fed:{providerAlias}:{login-name} >>>> >>>> But its quite possible that combination would be larger than 36 >>>> characters. We could also just shrink it to: >>>> >>>> fed:{login-name} >>>> >>>> But then we would have to iterate over every federation provider to >>>> find >>>> and load the user. >>>> >>>> So in summary: >>>> * IDs need to expand from 36 characters to something larger. (255 >>>> maybe). Don't some DBs have constraints on string primary key >>>> size? DB >>>> scripts could possibly be >>>> * CachedUserProvider and UserFederationManager interfaces would need to >>>> be refactored >>>> * I don't think UserFederationProvider interface would need to change. >>>> But users would have to code for in-memory rather than throwing a >>>> switch >>>> to just turn it on. >>>> >>>> >>>> >>> >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Thu Dec 3 14:06:29 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 3 Dec 2015 14:06:29 -0500 Subject: [keycloak-dev] getting rid of master realm Message-ID: <566092B5.8080208@redhat.com> I'm thinking that getting rid of the master realm would allow us to clean up some things we've wanted to clean up for some time. Here's what I have in mind. * There is no master realm * Realm admins can create other realms * You can set up trust from one realm to another. Just realms that are stored in that keycloak deployment. No remote stuff. * To keep it simple, the admin console in the realm would just have a "Trust" tab somewhere with a list of realms you trust or want to trust. When you trust a realm, any users that have admin roles in that trusted realm will have the same roles within the current realm. * When users log into the admin console, the list of realms that trust the logged into realm will be listed as realms the user can manage. * When a new realm is created, the new realm automatically trust the realm that created it. * If there is a trust relationship impersonation will work no matter what realm it is * We can remove the realm-management client in each realm and just merge the roles into security-admin-console. * For migration, we just import the master realm and set up trust between the master realm and every other realm. Once we do all this we can now look at satisfying the cannot-have-a-default-password requirement passed down by the security audit team. We can have a welcome page that just asks "To create your first realm, click here". -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Thu Dec 3 14:19:56 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 3 Dec 2015 20:19:56 +0100 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: <566092B5.8080208@redhat.com> References: <566092B5.8080208@redhat.com> Message-ID: +1000 This would simplify a lot of things. Currently, even though I know the code pretty well, I still get confused when it comes to admin roles, master admin clients and all that jazz. It would also simplify the admin endpoints and we can drop "realms" from urls. We could also drop "auth" from urls on the standalone Keycloak server. That would make URLs nicer. So it would be: //protocol/openid-connect/ //admin Instead of what we have atm: /auth/realms//protocol/openid-connect/ /auth/realms//admin I think we should have a dedicated create-realm role, rather than allow admin to do it. We should make it possible to enable/disable realm creation from within a specific realm. One question with regards to trust users from one realm to another, how would you manage role permissions? I think all permissions from one realm should be managed within the realm. We should also hide the security-admin-console from the clients list. We also need to figure out how to prevent the admin escalation problem we have. It should be possible to configure what roles a specific admin is allowed to grant to users. One question though. Instead of having many changes in 1.8 would it make more sense to just say enough is enough. Let's get started on 2.x and be a bit more free with breaking backwards compatibility. Then in 2.x we could: * Improve SPIs - especially model SPIs and user federation SPIs * Remove master realm * Add role namespaces * Clean-up URLs * Clean-up admin endpoints * Etc... On 3 December 2015 at 20:06, Bill Burke wrote: > I'm thinking that getting rid of the master realm would allow us to > clean up some things we've wanted to clean up for some time. Here's what > I have in mind. > > * There is no master realm > * Realm admins can create other realms > * You can set up trust from one realm to another. Just realms that are > stored in that keycloak deployment. No remote stuff. > * To keep it simple, the admin console in the realm would just have a > "Trust" tab somewhere with a list of realms you trust or want to trust. > When you trust a realm, any users that have admin roles in that > trusted realm will have the same roles within the current realm. > * When users log into the admin console, the list of realms that trust > the logged into realm will be listed as realms the user can manage. > * When a new realm is created, the new realm automatically trust the > realm that created it. > * If there is a trust relationship impersonation will work no matter > what realm it is > * We can remove the realm-management client in each realm and just merge > the roles into security-admin-console. > * For migration, we just import the master realm and set up trust > between the master realm and every other realm. > > > Once we do all this we can now look at satisfying the > cannot-have-a-default-password requirement passed down by the security > audit team. We can have a welcome page that just asks "To create your > first realm, click here". > -- > 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/20151203/c0985b25/attachment.html From bburke at redhat.com Thu Dec 3 15:33:02 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 3 Dec 2015 15:33:02 -0500 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: References: <566092B5.8080208@redhat.com> Message-ID: <5660A6FE.9080903@redhat.com> On 12/3/2015 2:19 PM, Stian Thorgersen wrote: > +1000 > > This would simplify a lot of things. Currently, even though I know the > code pretty well, I still get confused when it comes to admin roles, > master admin clients and all that jazz. > > It would also simplify the admin endpoints and we can drop "realms" from > urls. We could also drop "auth" from urls on the standalone Keycloak > server. That would make URLs nicer. So it would be: > > //protocol/openid-connect/ > //admin > > Instead of what we have atm: > > /auth/realms//protocol/openid-connect/ > /auth/realms//admin > > I think we should have a dedicated create-realm role, rather than allow > admin to do it. We should make it possible to enable/disable realm > creation from within a specific realm. > We do have a create-realm role. > One question with regards to trust users from one realm to another, how > would you manage role permissions? What do you mean? I was thinking of something *REALLY* simple. If Realm A trusts Realm B and User X in Realm B has "manage-clients" role in Realm B, then he can manage clients in Realm A. That way you don't have to deal with actual users, just roles. Does that make sense? I think all permissions from one > realm should be managed within the realm. We should also hide the > security-admin-console from the clients list. > > We also need to figure out how to prevent the admin escalation problem > we have. It should be possible to configure what roles a specific admin > is allowed to grant to users. > This is a different feature. This would not be what roles a specific admin is allowed to grant, but rather what roles a specific role can grant. Take the user out of the equation. > One question though. Instead of having many changes in 1.8 would it make > more sense to just say enough is enough. Let's get started on 2.x and be > a bit more free with breaking backwards compatibility. Then in 2.x we could: > I don't know what the best thing is to do. I'm worried about having enough time to bake stuff in community, but also don't want ugly shit sitting in product for the next 10 years. See what we can get in by end of December then release 1.8 mid January and stabilize until March? Encourage people to upgrade to 1.8 at least to test drive? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From thomas.darimont at googlemail.com Thu Dec 3 20:07:09 2015 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 4 Dec 2015 02:07:09 +0100 Subject: [keycloak-dev] Keycloak Client Provisioning Notifications. Message-ID: Hello there, are there any plans to provide a way to let client applications know of new users before they actually try to login? This could be used for triggering on-boarding mechanisms like e.g. preparing a user environment (e.g. a tenant) for a particular user. I was thinking of a mechanism like web-hooks, as github and many other services use in similar scenarios, where you could send a HTTP POST requests to the client application in case of a new user was registered in keycloak that was granted access to that particular application and potentially others as well. The POST request could contain some user data like: login, email, userid, client roles, perhaps for multiple clients etc. This would help client applications to associate a prepared environment with the actual user from keycloak. The intention is to keep an on-boarding experience fast as possible for the user by doing some preprocessing as early as possible. There is already a similar functionality to propagate logout events to client admin URL. Perhaps this could also be used for this - just send user created / user update / user deleted events to this endpoints as well. Perhaps with keeping track whether the clients acknowledged the updated via a HTTP 200 response-status with a retry with some back-off strategy otherwise. One often uses JMS topics for those scenarious but I think web-hooks would be a bit easier here. Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151204/e11c529b/attachment-0001.html From ayoung at redhat.com Thu Dec 3 21:17:36 2015 From: ayoung at redhat.com (Adam Young) Date: Thu, 3 Dec 2015 21:17:36 -0500 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <56605FD2.8090607@redhat.com> References: <565F20F9.6050400@redhat.com> <565FBCD0.8010104@redhat.com> <56605FD2.8090607@redhat.com> Message-ID: <5660F7C0.5040202@redhat.com> On 12/03/2015 10:29 AM, Bill Burke wrote: > > On 12/2/2015 10:53 PM, Adam Young wrote: >>> Getting in-memory zero-import to work is even more tricky. The issue is >>> that ClientSession and UserSession need to lookup clients by id. If the >>> user is not in cache, then the cache needs to lookup the user by id >>> within storage. This lookup also needs to happen if a write operation >>> is performed on a cache user (getDelegateForUpdate()). So, Keycloak >>> needs to know that that ID is not in local storage and must be looked up >>> from a fed provider. The ID must be formed so that the provider fed >>> provider can resolve the lookup. I could use a URI for the ID i.e. >>> >>> fed:{providerId}:{login-name} >> I'd recommend this, and increasing the size of the Database column. >> > We have many deployments already and some have quite large user > databases. Was really concerned that expanding the column size would > piss a lot of people off because of the DB migration required. Migrations are a fact of life. SQL ALchemy has decent support for it, and I've written it at least once in support of JBoss (back in 2000 IIRC). The trick is to leave the old columns around, but only use the new ones for one iteration, so that old scripts don't fall apart horribly. Its not perfect.... > > > We were talking a few weeks ago about ALL of our IDs becoming URIs. > roles, groups, realms, clients, etc. It would give us the flexibility > of federating anything we wanted going further. This is awesome, but does not need to be stored in the DB as an URL so long as you can compose it. > For example, > currently admins have to define roles and groups in keycloak. This > sucks if they are already defined and controlled someplace else. > >> Keystoen did this, but then SHA256 hashed it, makuing it a 64 character >> string. We found we were OK so long as we stayed under 255, as that was >> the limit mysql imposed for the string columns. >> >>> The problem with this is that this id would need to be larger than 36 >>> characters which is the current column size for UserEntity.id and any >>> other table that references users. I could possibly do: >>> >>> fed:{providerAlias}:{login-name} >>> >>> But its quite possible that combination would be larger than 36 >>> characters. We could also just shrink it to: >>> >>> fed:{login-name} >>> >>> But then we would have to iterate over every federation provider to find >>> and load the user. >> It gets trickier: you don;'t want one federation provider to step on >> the login from an other: ayoung at coke is a different user from >> ayoung at pepsi. Having the Id be something issued by Keycloak + something >> that comes from the Federated IdP is necessary. >> > Not really. This is no different than a user logging into the > user/password screen. Keycloak allows you to specify the order of > federation providers, but doesn't handle conflicts, i.e. one LDAP server > has the same username as another. You need to deal with this. The rules have changed with Federation, and you will have to deconflict. Two LDAP server in one organization are still under the management of a single user. KeyCloaks biggest potential for new deployments is Multi IDP, where they are managed by different services. If you don't make the IdPs safe to share the same table space, you end up building the logic in to the code, and not being able to enforce it in the DB. Still, it can be done by adding a column and making it a composite key (domain id, local user id) without changing the existing values, and the whole thing is a lot more readable, but existing constraints won't be sufficient; you'll have t join on multiple columns and use both everywhere. I kind of prefer that approach, but then, I tend toward heavily using RDBMS concepts. > >> I like in memory, but there are many questions to answer, when a user >> comes back a second time, what happens with their Id. I pushed for >> ephemeral for Keystone, and we couldn't make it work. >> > We track sessions, have offline sessions, and track consents. So an ID > cannot be temporary. Temporary and ephemeral are two different things. If you can always calculate the ID, and you always get the same ID for a user, you don't necessarily need to write it down. From mposolda at redhat.com Fri Dec 4 05:36:49 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 4 Dec 2015 11:36:49 +0100 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <566082AB.7070902@redhat.com> References: <565F20F9.6050400@redhat.com> <56606086.6010908@redhat.com> <56606673.9070502@redhat.com> <566074EA.3060408@redhat.com> <566082AB.7070902@redhat.com> Message-ID: <56616CC1.8070306@redhat.com> Why it's bad to do simpler things? :-) AFAIK filter pattern (or interceptor/chain whatever you call it) is proven to work in many places. The provider at level X can always decide if it delegates call to method "getUserByXXX" to next provider (and then proxy/cache or do whatever according to his logic) or return something by itself. If I understand correctly your proposal, it requires UserFederationProvider to decide, if it wants to import or just return InMemoryUserModel . So if we want to support in-memory for LDAP, we will need to have 2 versions of LDAPFederationProvider (current which imports into userStorage() and another, which will return InMemoryUserModel instances ). That's not ideal IMO. As I mentioned before, there are also 2 additional usecases, which are important to support IMO: 1) Case when admin changes some user attributes directly in LDAP and he wants the LDAP data to be immediately visible in Keycloak. This is what we currently support (see FederationProvidersIntegrationTest.testDirectLDAPUpdate() ). Maybe I am missing something with your proposal, but if we hardcode CacheProvider to be always first, we lost this. 2) Case when admin doesn't change user attributes in LDAP directly, but rather prefer to save performance and read data from cache. In this case, admin configures the chain like you proposed: CacheProvider => UserFederationManager => UserProvider IMO it will be cool to have single implementation of LDAPFederationProvider (and others), which works for both those cases and also for in-memory at the same time. Just let admin to decide how he want to configure chain of UserProviders, but not require UserFederationProvider itself to care about it. For my proposal, I assume that UserProvider will have just 2 new methods: UserProvider getNext(); void setNext(UserProvider next); Only change in current UserFederationManager and DefaultCacheUserProvider is, that they will call "getNext()" when they need delegate. They don't care about what the delegate actually is, that's not their responsibility. For the "in-memory" provider, it might be the per-request in-memory provider (users stored just per-request). So if you have chain like: userFederationManager => inMemory Then assume the session.users().getUserByUsername is called: 1) First delegate is UserFederationManager, so calling UserFederationManager.getUserByUsername 2) This line https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/UserFederationManager.java#L180 will call getNext().getUserByUsername() and returns null as the user was not yet looked for this request. 3) Going to federationProviders and call LDAPFederationProvider.getUserByUsername 4) LDAPFederationProvider query user in LDAP and calls importUserFromLDAP . This calls session.userStorage().addUser, which will put user into in-memory provider (I assume that session.userStorage() will be kept and will always point to the next delegate after UserFederationManager ). The LDAPFederationProvider will then return LDAP proxy of UserModel. The in-memory provider will also work with searching ( searchUser ) as federationLoad will first pre-load users into in-memory and then calls "query" and proxy users. The only limitation I can see now is calling of session.users().getUsers() as this doesn't preload users from federation. But if people add cache and use chain like: cache => federationManager => inMemory it will work fine and find all users retrieved from LDAP in any previous requests. In summary: UserProvider chaining is: 1) Very flexible 2) Supports in-memory, but also other use-cases too. It's all up to admin preference how to configure chain 3) No dependencies of providers on each other 4) Minimal changes to UserFederationManager and DefaultCacheUserProvider . Just need to call "getNext()" to retrieve next provider 5) Current UserFederationProvider will work fine for all cases and automatically gains "in-memory" support without need to change anything in their code. Assuming that for backwards compatibility, we will keep "session.userStorage()" to always point to next delegate of UserFederationManager . If it's JPA, then imports user like now. If it will be "in-memory" it will just return cache user for this request and return per-request inMemory user. Marek On 03/12/15 18:58, Bill Burke wrote: > Still don't think it is as simple as you state. We don't need an "in > memory" provider. We want UserFederationProvider to create a > temporary request/only in-memory UserModel for federation providers > that don't want to import. This UserModel may be proxied for any > write operations. > > My current thinking is that we change the flow from: > > UserFederationManager=>CacheProvider=>UserProvider > > to > > CacheProvider->UserFederationManager->UserProvider/UserFederationProvider > > KeycloakSession changes: > > * users() returns the CacheUserProvider instead of UserFederationManager > * userStorage() is not changed > * federationManager() returns UserFederationManager > > UserCacheProvider changes: > > * Gets a new method cache(UserModel user); > * References UserFederationManager instead of the DB provider directly > > UserFederationManager changes: > * Instead of calling userStorage(), it gets the DB provider directly > > UserFederationProvider: > * Imports using userStorage() or, allocates a new class > InMemoryUserModel (or extension of that class). This class is just an > in memory implementation of UserModel > * Returns the imported UserModel or the InMemoryUserModel > > So > > session.users().getUserByXXXX() does the folloing: > > 1. UserCacheProvider.getUserByXXX is invoked > 2. It looks looks in cache, if found return > 3. invoke UserFederationManager.getUserByXXX > 4. If UserFederationManager finds it return UserModel > 5. Look in UserFederationProvider > 6. UserFederationProvider imports or returns InMemoryUserModel > 7. UserCacheProvider.getUserByXXX caches the user. > > cache.UserAdapter.getDelegateForUpdate() does the following: > 1. invokes UserFederationManager.getUserById() > 2. ID is parsed to see if it is a federated ID or not (see original post) > > Alternatively, we could just invoke > userFederationManager.getUserByusername() since username can't be null. > > > > On 12/3/2015 11:59 AM, Marek Posolda wrote: >> On 03/12/15 16:57, Bill Burke wrote: >>> Either we redo the federation SPI or work with the current one. >>> >>> It is just not as simple as you state. You can't just chain in a >>> generic InMemoryProvider. Federation needs to be able to proxy the >>> UserModel so that it can handle write methods if it wants to. Or >>> delegate lookup of certain things to LDAP. >> I am not seeing why it's an issue? The InMemory will be kind of same >> thing like currently JPA. It just won't store the things into database, >> but into memory. That's the only difference. It will just be the >> provider at the end of the chain. UserFederationManager can proxy users >> exactly like now and doesn't require any code changes. >> >> So when admin configure: >> >> userFederationMAnager => inMemory >> >> The call of "session.userStorage()" from UserFederationManager will >> return underlying InMemory instead of current JPA. >> >>> Also, UserFederationManager has to be first in the chain so that if >>> something is found in cache, it can let the federation provider proxy >>> the cache if it wants to. >> That's not a problem as well. >> >> What I mean is the flexibility to configure things exactly how you want >> for various cases. >> >> 3 basic setups: >> >> 1. userFederation => cache => JPA >> >> This is what we have now and it will be the default setup. It 's useful >> for deployments when admins are often doing changes directly in their >> LDAP and they want the change imediatelly visible in Keycloak. So the >> UserFederationProvider proxy is always the top and when you call: >> >> user.getFirstName() >> >> you will retrieve the firstName from LDAP. The disadvantage of this >> setup is performance (each HTTP request needs to query LDAP like it's >> now) >> >> >> 2. cache => userFederation => JPA >> >> This will be useful for deployments when amins are not doing changes >> directly in their LDAP. So once you retrieve the user from >> LDAP+KeycloakDB, you will save him to cache and call to: >> >> user.getFirstName() >> >> will always return the value from cache. Hence when admin changes >> directly in LDAP, it won't be immediately visible in Keycloak. >> >> But on the other hand update from Keycloak to LDAP is not an issue. When >> you call: >> >> user.setFirstName("foo") >> >> the cache will call getDelegateForUpdate (exactly like now) and it will >> return proxy object, so the saving of firstName is propagated to LDAP >> (if it's writable) and to Keycloak JPA DB as well. >> >> >> 3. userFederation => inMemory >> >> The federation backed by pure in-memory storage. The federation proxy is >> on top, writing and reading to/from LDAP is not a problem and has >> preference over the content from memory. The only difference from (1) is >> that underlying backend is pure memory (infinispan) instead of JPA DB >> >> There is also alternative to use combination of 2 and 3: >> cache => userFederation => inMemory >> >> etc etc. >> >> >> I can see this as most flexible approach without dependencies of various >> providers on each other. >> >> Marek >>> >>> What we need is a special interface for the cache: >>> >>> cache.cacheUser(UserModel user); >>> >>> The cache would also work with UserFederationManager rather than a >>> generic UserProvider. UserFederationManager would gain methods like: >>> UserFederationManager.getUncachedUserById() which the cache would >>> invoke. UserFederationManager would break down the user id and either >>> know it was local storage or something that would have to be delegated >>> to a UserProvider. >>> >>> >>> >>> >>> >>> On 12/3/2015 10:32 AM, Marek Posolda wrote: >>>> IMO the more important use-case that in-memory federated users is the >>>> caching of federated users. >>>> >>>> Currently if you call: session.users().getUserById() and the user with >>>> ID "123" is LDAP (or other federationProvider) user, there is always >>>> call to UserFederationProvider.validateAndProxy , which results in >>>> LDAP >>>> query. >>>> >>>> If we introduce the chaining of UserProvider (something I already >>>> proposed earlier), you can switch UserFederationProvider with >>>> cache, so >>>> you will have: >>>> cache => userFederationManager => JPA >>>> >>>> instead of current: >>>> >>>> userFederationManager => cache => JPA >>>> >>>> >>>> With that in mind, we can easily implement in-memory as another >>>> implementation of UserProvider, which will hold users purely >>>> in-memory. >>>> Our current DefaultCacheUserProvider always require delegate to call >>>> write operations. But this in-memory provider would be something >>>> different. It won't use any delegate as it will be in the end of the >>>> chain. So for in-memory federation you will just configure: >>>> >>>> userFederationManager => inMemoryProvider >>>> >>>> and you're done. No needs for special ID handling or something like >>>> that. >>>> >>>> With chaining of UserProvider we have biggest flexibility for various >>>> needs IMO. That's why I would rather go this way TBH. >>>> Marek >>>> >>>> On 02/12/15 17:48, Bill Burke wrote: >>>>> I'm looking into in-memory only no-import federated users. What we >>>>> would want to do is allow the UserFederationProvider to create an >>>>> in-memory UserModel and allow for that UserModel to be cached via our >>>>> current architecture. >>>>> >>>>> The current design assumes that all federated users are imported. >>>>> This >>>>> includes our caching layer too! To add to that, the user isn't >>>>> cached >>>>> until the 2nd request i.e.: >>>>> >>>>> 1. username/password page would hit the UserFederationProvider and >>>>> the >>>>> user would be imported into Keycloak. This imported user is not >>>>> cached, >>>>> only imported into the database for this request's KeycloakSession >>>>> 2. OTP Page or code 2 token would then want to lookup the user by >>>>> id as >>>>> that is what is stored in the ClientSession. It would hit the >>>>> keycloak >>>>> database as it is not cached yet. This lookup loads the cache for >>>>> the user. >>>>> >>>>> Getting in-memory zero-import to work is even more tricky. The >>>>> issue is >>>>> that ClientSession and UserSession need to lookup clients by id. If >>>>> the >>>>> user is not in cache, then the cache needs to lookup the user by id >>>>> within storage. This lookup also needs to happen if a write >>>>> operation >>>>> is performed on a cache user (getDelegateForUpdate()). So, Keycloak >>>>> needs to know that that ID is not in local storage and must be >>>>> looked up >>>>> from a fed provider. The ID must be formed so that the provider fed >>>>> provider can resolve the lookup. I could use a URI for the ID i.e. >>>>> >>>>> fed:{providerId}:{login-name} >>>>> >>>>> The problem with this is that this id would need to be larger than 36 >>>>> characters which is the current column size for UserEntity.id and any >>>>> other table that references users. I could possibly do: >>>>> >>>>> fed:{providerAlias}:{login-name} >>>>> >>>>> But its quite possible that combination would be larger than 36 >>>>> characters. We could also just shrink it to: >>>>> >>>>> fed:{login-name} >>>>> >>>>> But then we would have to iterate over every federation provider to >>>>> find >>>>> and load the user. >>>>> >>>>> So in summary: >>>>> * IDs need to expand from 36 characters to something larger. (255 >>>>> maybe). Don't some DBs have constraints on string primary key >>>>> size? DB >>>>> scripts could possibly be >>>>> * CachedUserProvider and UserFederationManager interfaces would >>>>> need to >>>>> be refactored >>>>> * I don't think UserFederationProvider interface would need to >>>>> change. >>>>> But users would have to code for in-memory rather than throwing a >>>>> switch >>>>> to just turn it on. >>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151204/68a21405/attachment-0001.html From mposolda at redhat.com Fri Dec 4 05:41:15 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 4 Dec 2015 11:41:15 +0100 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <56616CC1.8070306@redhat.com> References: <565F20F9.6050400@redhat.com> <56606086.6010908@redhat.com> <56606673.9070502@redhat.com> <566074EA.3060408@redhat.com> <566082AB.7070902@redhat.com> <56616CC1.8070306@redhat.com> Message-ID: <56616DCB.3030609@redhat.com> On 04/12/15 11:36, Marek Posolda wrote: > Why it's bad to do simpler things? :-) > > AFAIK filter pattern (or interceptor/chain whatever you call it) is > proven to work in many places. The provider at level X can always > decide if it delegates call to method "getUserByXXX" to next provider > (and then proxy/cache or do whatever according to his logic) or return > something by itself. > > If I understand correctly your proposal, it requires > UserFederationProvider to decide, if it wants to import or just return > InMemoryUserModel . So if we want to support in-memory for LDAP, we > will need to have 2 versions of LDAPFederationProvider (current which > imports into userStorage() and another, which will return > InMemoryUserModel instances ). That's not ideal IMO. > > > As I mentioned before, there are also 2 additional usecases, which are > important to support IMO: > > 1) Case when admin changes some user attributes directly in LDAP and > he wants the LDAP data to be immediately visible in Keycloak. This is > what we currently support (see > FederationProvidersIntegrationTest.testDirectLDAPUpdate() ). Maybe I > am missing something with your proposal, but if we hardcode > CacheProvider to be always first, we lost this. > > 2) Case when admin doesn't change user attributes in LDAP directly, > but rather prefer to save performance and read data from cache. In > this case, admin configures the chain like you proposed: CacheProvider > => UserFederationManager => UserProvider > > > IMO it will be cool to have single implementation of > LDAPFederationProvider (and others), which works for both those cases > and also for in-memory at the same time. Just let admin to decide how > he want to configure chain of UserProviders, but not require > UserFederationProvider itself to care about it. > > > For my proposal, I assume that UserProvider will have just 2 new methods: > > UserProvider getNext(); > void setNext(UserProvider next); > > > Only change in current UserFederationManager and > DefaultCacheUserProvider is, that they will call "getNext()" when they > need delegate. They don't care about what the delegate actually is, > that's not their responsibility. > > For the "in-memory" provider, it might be the per-request in-memory > provider (users stored just per-request). So if you have chain like: > userFederationManager => inMemory > > Then assume the session.users().getUserByUsername is called: > 1) First delegate is UserFederationManager, so calling > UserFederationManager.getUserByUsername > 2) This line > https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/UserFederationManager.java#L180 > will call getNext().getUserByUsername() and returns null as the user > was not yet looked for this request. > 3) Going to federationProviders and call > LDAPFederationProvider.getUserByUsername > 4) LDAPFederationProvider query user in LDAP and calls > importUserFromLDAP . This calls session.userStorage().addUser, which > will put user into in-memory provider (I assume that > session.userStorage() will be kept and will always point to the next > delegate after UserFederationManager ). The LDAPFederationProvider > will then return LDAP proxy of UserModel. > > The in-memory provider will also work with searching ( searchUser ) as > federationLoad will first pre-load users into in-memory and then calls > "query" and proxy users. > > The only limitation I can see now is calling of > session.users().getUsers() as this doesn't preload users from > federation. But if people add cache and use chain like: > cache => federationManager => inMemory > > it will work fine and find all users retrieved from LDAP in any > previous requests. > > > In summary: UserProvider chaining is: > > 1) Very flexible > > 2) Supports in-memory, but also other use-cases too. It's all up to > admin preference how to configure chain > > 3) No dependencies of providers on each other > > 4) Minimal changes to UserFederationManager and > DefaultCacheUserProvider . Just need to call "getNext()" to retrieve > next provider > > 5) Current UserFederationProvider will work fine for all cases and > automatically gains "in-memory" support without need to change > anything in their code. Assuming that for backwards compatibility, we > will keep "session.userStorage()" to always point to next delegate of > UserFederationManager . If it's JPA, then imports user like now. If it > will be "in-memory" it will just return cache user for this request > and return per-request inMemory user. 6) No need to increase the size of ID column for user table :-) > > Marek > > > On 03/12/15 18:58, Bill Burke wrote: >> Still don't think it is as simple as you state. We don't need an "in >> memory" provider. We want UserFederationProvider to create a >> temporary request/only in-memory UserModel for federation providers >> that don't want to import. This UserModel may be proxied for any >> write operations. >> >> My current thinking is that we change the flow from: >> >> UserFederationManager=>CacheProvider=>UserProvider >> >> to >> >> CacheProvider->UserFederationManager->UserProvider/UserFederationProvider >> >> >> KeycloakSession changes: >> >> * users() returns the CacheUserProvider instead of UserFederationManager >> * userStorage() is not changed >> * federationManager() returns UserFederationManager >> >> UserCacheProvider changes: >> >> * Gets a new method cache(UserModel user); >> * References UserFederationManager instead of the DB provider directly >> >> UserFederationManager changes: >> * Instead of calling userStorage(), it gets the DB provider directly >> >> UserFederationProvider: >> * Imports using userStorage() or, allocates a new class >> InMemoryUserModel (or extension of that class). This class is just >> an in memory implementation of UserModel >> * Returns the imported UserModel or the InMemoryUserModel >> >> So >> >> session.users().getUserByXXXX() does the folloing: >> >> 1. UserCacheProvider.getUserByXXX is invoked >> 2. It looks looks in cache, if found return >> 3. invoke UserFederationManager.getUserByXXX >> 4. If UserFederationManager finds it return UserModel >> 5. Look in UserFederationProvider >> 6. UserFederationProvider imports or returns InMemoryUserModel >> 7. UserCacheProvider.getUserByXXX caches the user. >> >> cache.UserAdapter.getDelegateForUpdate() does the following: >> 1. invokes UserFederationManager.getUserById() >> 2. ID is parsed to see if it is a federated ID or not (see original >> post) >> >> Alternatively, we could just invoke >> userFederationManager.getUserByusername() since username can't be null. >> >> >> >> On 12/3/2015 11:59 AM, Marek Posolda wrote: >>> On 03/12/15 16:57, Bill Burke wrote: >>>> Either we redo the federation SPI or work with the current one. >>>> >>>> It is just not as simple as you state. You can't just chain in a >>>> generic InMemoryProvider. Federation needs to be able to proxy the >>>> UserModel so that it can handle write methods if it wants to. Or >>>> delegate lookup of certain things to LDAP. >>> I am not seeing why it's an issue? The InMemory will be kind of same >>> thing like currently JPA. It just won't store the things into database, >>> but into memory. That's the only difference. It will just be the >>> provider at the end of the chain. UserFederationManager can proxy users >>> exactly like now and doesn't require any code changes. >>> >>> So when admin configure: >>> >>> userFederationMAnager => inMemory >>> >>> The call of "session.userStorage()" from UserFederationManager will >>> return underlying InMemory instead of current JPA. >>> >>>> Also, UserFederationManager has to be first in the chain so that if >>>> something is found in cache, it can let the federation provider proxy >>>> the cache if it wants to. >>> That's not a problem as well. >>> >>> What I mean is the flexibility to configure things exactly how you want >>> for various cases. >>> >>> 3 basic setups: >>> >>> 1. userFederation => cache => JPA >>> >>> This is what we have now and it will be the default setup. It 's >>> useful >>> for deployments when admins are often doing changes directly in their >>> LDAP and they want the change imediatelly visible in Keycloak. So the >>> UserFederationProvider proxy is always the top and when you call: >>> >>> user.getFirstName() >>> >>> you will retrieve the firstName from LDAP. The disadvantage of this >>> setup is performance (each HTTP request needs to query LDAP like >>> it's now) >>> >>> >>> 2. cache => userFederation => JPA >>> >>> This will be useful for deployments when amins are not doing changes >>> directly in their LDAP. So once you retrieve the user from >>> LDAP+KeycloakDB, you will save him to cache and call to: >>> >>> user.getFirstName() >>> >>> will always return the value from cache. Hence when admin changes >>> directly in LDAP, it won't be immediately visible in Keycloak. >>> >>> But on the other hand update from Keycloak to LDAP is not an issue. >>> When >>> you call: >>> >>> user.setFirstName("foo") >>> >>> the cache will call getDelegateForUpdate (exactly like now) and it will >>> return proxy object, so the saving of firstName is propagated to LDAP >>> (if it's writable) and to Keycloak JPA DB as well. >>> >>> >>> 3. userFederation => inMemory >>> >>> The federation backed by pure in-memory storage. The federation >>> proxy is >>> on top, writing and reading to/from LDAP is not a problem and has >>> preference over the content from memory. The only difference from >>> (1) is >>> that underlying backend is pure memory (infinispan) instead of JPA DB >>> >>> There is also alternative to use combination of 2 and 3: >>> cache => userFederation => inMemory >>> >>> etc etc. >>> >>> >>> I can see this as most flexible approach without dependencies of >>> various >>> providers on each other. >>> >>> Marek >>>> >>>> What we need is a special interface for the cache: >>>> >>>> cache.cacheUser(UserModel user); >>>> >>>> The cache would also work with UserFederationManager rather than a >>>> generic UserProvider. UserFederationManager would gain methods like: >>>> UserFederationManager.getUncachedUserById() which the cache would >>>> invoke. UserFederationManager would break down the user id and either >>>> know it was local storage or something that would have to be delegated >>>> to a UserProvider. >>>> >>>> >>>> >>>> >>>> >>>> On 12/3/2015 10:32 AM, Marek Posolda wrote: >>>>> IMO the more important use-case that in-memory federated users is the >>>>> caching of federated users. >>>>> >>>>> Currently if you call: session.users().getUserById() and the user >>>>> with >>>>> ID "123" is LDAP (or other federationProvider) user, there is always >>>>> call to UserFederationProvider.validateAndProxy , which results in >>>>> LDAP >>>>> query. >>>>> >>>>> If we introduce the chaining of UserProvider (something I already >>>>> proposed earlier), you can switch UserFederationProvider with >>>>> cache, so >>>>> you will have: >>>>> cache => userFederationManager => JPA >>>>> >>>>> instead of current: >>>>> >>>>> userFederationManager => cache => JPA >>>>> >>>>> >>>>> With that in mind, we can easily implement in-memory as another >>>>> implementation of UserProvider, which will hold users purely >>>>> in-memory. >>>>> Our current DefaultCacheUserProvider always require delegate to call >>>>> write operations. But this in-memory provider would be something >>>>> different. It won't use any delegate as it will be in the end of the >>>>> chain. So for in-memory federation you will just configure: >>>>> >>>>> userFederationManager => inMemoryProvider >>>>> >>>>> and you're done. No needs for special ID handling or something like >>>>> that. >>>>> >>>>> With chaining of UserProvider we have biggest flexibility for various >>>>> needs IMO. That's why I would rather go this way TBH. >>>>> Marek >>>>> >>>>> On 02/12/15 17:48, Bill Burke wrote: >>>>>> I'm looking into in-memory only no-import federated users. What we >>>>>> would want to do is allow the UserFederationProvider to create an >>>>>> in-memory UserModel and allow for that UserModel to be cached via >>>>>> our >>>>>> current architecture. >>>>>> >>>>>> The current design assumes that all federated users are >>>>>> imported. This >>>>>> includes our caching layer too! To add to that, the user isn't >>>>>> cached >>>>>> until the 2nd request i.e.: >>>>>> >>>>>> 1. username/password page would hit the UserFederationProvider >>>>>> and the >>>>>> user would be imported into Keycloak. This imported user is not >>>>>> cached, >>>>>> only imported into the database for this request's KeycloakSession >>>>>> 2. OTP Page or code 2 token would then want to lookup the user by >>>>>> id as >>>>>> that is what is stored in the ClientSession. It would hit the >>>>>> keycloak >>>>>> database as it is not cached yet. This lookup loads the cache for >>>>>> the user. >>>>>> >>>>>> Getting in-memory zero-import to work is even more tricky. The >>>>>> issue is >>>>>> that ClientSession and UserSession need to lookup clients by id. If >>>>>> the >>>>>> user is not in cache, then the cache needs to lookup the user by id >>>>>> within storage. This lookup also needs to happen if a write >>>>>> operation >>>>>> is performed on a cache user (getDelegateForUpdate()). So, Keycloak >>>>>> needs to know that that ID is not in local storage and must be >>>>>> looked up >>>>>> from a fed provider. The ID must be formed so that the provider fed >>>>>> provider can resolve the lookup. I could use a URI for the ID i.e. >>>>>> >>>>>> fed:{providerId}:{login-name} >>>>>> >>>>>> The problem with this is that this id would need to be larger >>>>>> than 36 >>>>>> characters which is the current column size for UserEntity.id and >>>>>> any >>>>>> other table that references users. I could possibly do: >>>>>> >>>>>> fed:{providerAlias}:{login-name} >>>>>> >>>>>> But its quite possible that combination would be larger than 36 >>>>>> characters. We could also just shrink it to: >>>>>> >>>>>> fed:{login-name} >>>>>> >>>>>> But then we would have to iterate over every federation provider to >>>>>> find >>>>>> and load the user. >>>>>> >>>>>> So in summary: >>>>>> * IDs need to expand from 36 characters to something larger. (255 >>>>>> maybe). Don't some DBs have constraints on string primary key >>>>>> size? DB >>>>>> scripts could possibly be >>>>>> * CachedUserProvider and UserFederationManager interfaces would >>>>>> need to >>>>>> be refactored >>>>>> * I don't think UserFederationProvider interface would need to >>>>>> change. >>>>>> But users would have to code for in-memory rather than throwing a >>>>>> switch >>>>>> to just turn it on. >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > > > > _______________________________________________ > 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/20151204/783d73ae/attachment-0001.html From mposolda at redhat.com Fri Dec 4 07:03:42 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 4 Dec 2015 13:03:42 +0100 Subject: [keycloak-dev] Keycloak Client Provisioning Notifications. In-Reply-To: References: Message-ID: <5661811E.3080200@redhat.com> We have events SPI. You can implement your own Events listener and listen for events when: - user register by himself (This is classic REGISTER event) - admin creates new user in admin console (There is some admin event) You can do EventListener provider, which will notify your application. See some docs: http://keycloak.github.io/docs/userguide/keycloak-server/html/events.html http://keycloak.github.io/docs/userguide/keycloak-server/html/providers.html Also take a look at providers/event-listener-.. in examples download Marek On 04/12/15 02:07, Thomas Darimont wrote: > Hello there, > > are there any plans to provide a way to let client applications > know of new users before they actually try to login? > > This could be used for triggering on-boarding mechanisms like e.g. > preparing a user environment (e.g. a tenant) for a particular > user. > > I was thinking of a mechanism like web-hooks, as github and many other > services use in similar scenarios, where you could send a HTTP POST > requests to the client application in case of > a new user was registered in keycloak that was granted access to that > particular application and potentially others as well. > > The POST request could contain some user data like: > login, email, userid, client roles, perhaps for multiple clients etc. > This would help client applications to associate a prepared > environment with the actual user from keycloak. > > The intention is to keep an on-boarding experience fast as possible > for the user by doing some preprocessing as early as possible. > > There is already a similar functionality to propagate logout events to > client admin URL. > Perhaps this could also be used for this - just send user created / > user update / user deleted > events to this endpoints as well. > Perhaps with keeping track whether the clients acknowledged the > updated via a HTTP 200 response-status with a retry with some back-off > strategy otherwise. > > One often uses JMS topics for those scenarious but I think web-hooks > would be a bit easier here. > > Cheers, > 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/20151204/e15ee35c/attachment.html From sthorger at redhat.com Fri Dec 4 07:35:07 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 4 Dec 2015 13:35:07 +0100 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <56616DCB.3030609@redhat.com> References: <565F20F9.6050400@redhat.com> <56606086.6010908@redhat.com> <56606673.9070502@redhat.com> <566074EA.3060408@redhat.com> <566082AB.7070902@redhat.com> <56616CC1.8070306@redhat.com> <56616DCB.3030609@redhat.com> Message-ID: What about splitting the federation logic from the store logic? We'd have multiple user store implementations: * JPA * Mongo * LDAP * Maybe something similar to PL IDM to allow people to easily use their own schema for users We could have store mappers as well in a mapping layer. This would allow users to configure the user store for a specific realm. So they can store everything about users in LDAP and not have to worry about federation. Then we'd have separate federation providers which could be re-used for different store types. So it would look something like: cache -> federation -> mappers -> store In theory you could even use that to share users between multiple realms. Have multiple separate sets of users in different dbs, ldap, etc.. I think it's an idea worth considering? On 4 December 2015 at 11:41, Marek Posolda wrote: > On 04/12/15 11:36, Marek Posolda wrote: > > Why it's bad to do simpler things? :-) > > AFAIK filter pattern (or interceptor/chain whatever you call it) is proven > to work in many places. The provider at level X can always decide if it > delegates call to method "getUserByXXX" to next provider (and then > proxy/cache or do whatever according to his logic) or return something by > itself. > > If I understand correctly your proposal, it requires > UserFederationProvider to decide, if it wants to import or just return > InMemoryUserModel . So if we want to support in-memory for LDAP, we will > need to have 2 versions of LDAPFederationProvider (current which imports > into userStorage() and another, which will return InMemoryUserModel > instances ). That's not ideal IMO. > > > As I mentioned before, there are also 2 additional usecases, which are > important to support IMO: > > 1) Case when admin changes some user attributes directly in LDAP and he > wants the LDAP data to be immediately visible in Keycloak. This is what we > currently support (see > FederationProvidersIntegrationTest.testDirectLDAPUpdate() ). Maybe I am > missing something with your proposal, but if we hardcode CacheProvider to > be always first, we lost this. > > 2) Case when admin doesn't change user attributes in LDAP directly, but > rather prefer to save performance and read data from cache. In this case, > admin configures the chain like you proposed: CacheProvider => > UserFederationManager => UserProvider > > > IMO it will be cool to have single implementation of > LDAPFederationProvider (and others), which works for both those cases and > also for in-memory at the same time. Just let admin to decide how he want > to configure chain of UserProviders, but not require UserFederationProvider > itself to care about it. > > > For my proposal, I assume that UserProvider will have just 2 new methods: > > UserProvider getNext(); > void setNext(UserProvider next); > > > Only change in current UserFederationManager and DefaultCacheUserProvider > is, that they will call "getNext()" when they need delegate. They don't > care about what the delegate actually is, that's not their responsibility. > > For the "in-memory" provider, it might be the per-request in-memory > provider (users stored just per-request). So if you have chain like: > userFederationManager => inMemory > > Then assume the session.users().getUserByUsername is called: > 1) First delegate is UserFederationManager, so calling > UserFederationManager.getUserByUsername > 2) This line > https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/UserFederationManager.java#L180 > will call getNext().getUserByUsername() and returns null as the user was > not yet looked for this request. > 3) Going to federationProviders and call > LDAPFederationProvider.getUserByUsername > 4) LDAPFederationProvider query user in LDAP and calls importUserFromLDAP > . This calls session.userStorage().addUser, which will put user into > in-memory provider (I assume that session.userStorage() will be kept and > will always point to the next delegate after UserFederationManager ). The > LDAPFederationProvider will then return LDAP proxy of UserModel. > > The in-memory provider will also work with searching ( searchUser ) as > federationLoad will first pre-load users into in-memory and then calls > "query" and proxy users. > > The only limitation I can see now is calling of session.users().getUsers() > as this doesn't preload users from federation. But if people add cache and > use chain like: > cache => federationManager => inMemory > > it will work fine and find all users retrieved from LDAP in any previous > requests. > > > In summary: UserProvider chaining is: > > 1) Very flexible > > 2) Supports in-memory, but also other use-cases too. It's all up to admin > preference how to configure chain > > 3) No dependencies of providers on each other > > 4) Minimal changes to UserFederationManager and DefaultCacheUserProvider . > Just need to call "getNext()" to retrieve next provider > > 5) Current UserFederationProvider will work fine for all cases and > automatically gains "in-memory" support without need to change anything in > their code. Assuming that for backwards compatibility, we will keep > "session.userStorage()" to always point to next delegate of > UserFederationManager . If it's JPA, then imports user like now. If it will > be "in-memory" it will just return cache user for this request and return > per-request inMemory user. > > 6) No need to increase the size of ID column for user table :-) > > > > Marek > > > On 03/12/15 18:58, Bill Burke wrote: > > Still don't think it is as simple as you state. We don't need an "in > memory" provider. We want UserFederationProvider to create a temporary > request/only in-memory UserModel for federation providers that don't want > to import. This UserModel may be proxied for any write operations. > > My current thinking is that we change the flow from: > > UserFederationManager=>CacheProvider=>UserProvider > > to > > CacheProvider->UserFederationManager->UserProvider/UserFederationProvider > > KeycloakSession changes: > > * users() returns the CacheUserProvider instead of UserFederationManager > * userStorage() is not changed > * federationManager() returns UserFederationManager > > UserCacheProvider changes: > > * Gets a new method cache(UserModel user); > * References UserFederationManager instead of the DB provider directly > > UserFederationManager changes: > * Instead of calling userStorage(), it gets the DB provider directly > > UserFederationProvider: > * Imports using userStorage() or, allocates a new class InMemoryUserModel > (or extension of that class). This class is just an in memory > implementation of UserModel > * Returns the imported UserModel or the InMemoryUserModel > > So > > session.users().getUserByXXXX() does the folloing: > > 1. UserCacheProvider.getUserByXXX is invoked > 2. It looks looks in cache, if found return > 3. invoke UserFederationManager.getUserByXXX > 4. If UserFederationManager finds it return UserModel > 5. Look in UserFederationProvider > 6. UserFederationProvider imports or returns InMemoryUserModel > 7. UserCacheProvider.getUserByXXX caches the user. > > cache.UserAdapter.getDelegateForUpdate() does the following: > 1. invokes UserFederationManager.getUserById() > 2. ID is parsed to see if it is a federated ID or not (see original post) > > Alternatively, we could just invoke > userFederationManager.getUserByusername() since username can't be null. > > > > On 12/3/2015 11:59 AM, Marek Posolda wrote: > > On 03/12/15 16:57, Bill Burke wrote: > > Either we redo the federation SPI or work with the current one. > > It is just not as simple as you state. You can't just chain in a > generic InMemoryProvider. Federation needs to be able to proxy the > UserModel so that it can handle write methods if it wants to. Or > delegate lookup of certain things to LDAP. > > I am not seeing why it's an issue? The InMemory will be kind of same > thing like currently JPA. It just won't store the things into database, > but into memory. That's the only difference. It will just be the > provider at the end of the chain. UserFederationManager can proxy users > exactly like now and doesn't require any code changes. > > So when admin configure: > > userFederationMAnager => inMemory > > The call of "session.userStorage()" from UserFederationManager will > return underlying InMemory instead of current JPA. > > Also, UserFederationManager has to be first in the chain so that if > something is found in cache, it can let the federation provider proxy > the cache if it wants to. > > That's not a problem as well. > > What I mean is the flexibility to configure things exactly how you want > for various cases. > > 3 basic setups: > > 1. userFederation => cache => JPA > > This is what we have now and it will be the default setup. It 's useful > for deployments when admins are often doing changes directly in their > LDAP and they want the change imediatelly visible in Keycloak. So the > UserFederationProvider proxy is always the top and when you call: > > user.getFirstName() > > you will retrieve the firstName from LDAP. The disadvantage of this > setup is performance (each HTTP request needs to query LDAP like it's now) > > > 2. cache => userFederation => JPA > > This will be useful for deployments when amins are not doing changes > directly in their LDAP. So once you retrieve the user from > LDAP+KeycloakDB, you will save him to cache and call to: > > user.getFirstName() > > will always return the value from cache. Hence when admin changes > directly in LDAP, it won't be immediately visible in Keycloak. > > But on the other hand update from Keycloak to LDAP is not an issue. When > you call: > > user.setFirstName("foo") > > the cache will call getDelegateForUpdate (exactly like now) and it will > return proxy object, so the saving of firstName is propagated to LDAP > (if it's writable) and to Keycloak JPA DB as well. > > > 3. userFederation => inMemory > > The federation backed by pure in-memory storage. The federation proxy is > on top, writing and reading to/from LDAP is not a problem and has > preference over the content from memory. The only difference from (1) is > that underlying backend is pure memory (infinispan) instead of JPA DB > > There is also alternative to use combination of 2 and 3: > cache => userFederation => inMemory > > etc etc. > > > I can see this as most flexible approach without dependencies of various > providers on each other. > > Marek > > > What we need is a special interface for the cache: > > cache.cacheUser(UserModel user); > > The cache would also work with UserFederationManager rather than a > generic UserProvider. UserFederationManager would gain methods like: > UserFederationManager.getUncachedUserById() which the cache would > invoke. UserFederationManager would break down the user id and either > know it was local storage or something that would have to be delegated > to a UserProvider. > > > > > > On 12/3/2015 10:32 AM, Marek Posolda wrote: > > IMO the more important use-case that in-memory federated users is the > caching of federated users. > > Currently if you call: session.users().getUserById() and the user with > ID "123" is LDAP (or other federationProvider) user, there is always > call to UserFederationProvider.validateAndProxy , which results in LDAP > query. > > If we introduce the chaining of UserProvider (something I already > proposed earlier), you can switch UserFederationProvider with cache, so > you will have: > cache => userFederationManager => JPA > > instead of current: > > userFederationManager => cache => JPA > > > With that in mind, we can easily implement in-memory as another > implementation of UserProvider, which will hold users purely in-memory. > Our current DefaultCacheUserProvider always require delegate to call > write operations. But this in-memory provider would be something > different. It won't use any delegate as it will be in the end of the > chain. So for in-memory federation you will just configure: > > userFederationManager => inMemoryProvider > > and you're done. No needs for special ID handling or something like > that. > > With chaining of UserProvider we have biggest flexibility for various > needs IMO. That's why I would rather go this way TBH. > Marek > > On 02/12/15 17:48, Bill Burke wrote: > > I'm looking into in-memory only no-import federated users. What we > would want to do is allow the UserFederationProvider to create an > in-memory UserModel and allow for that UserModel to be cached via our > current architecture. > > The current design assumes that all federated users are imported. This > includes our caching layer too! To add to that, the user isn't cached > until the 2nd request i.e.: > > 1. username/password page would hit the UserFederationProvider and the > user would be imported into Keycloak. This imported user is not > cached, > only imported into the database for this request's KeycloakSession > 2. OTP Page or code 2 token would then want to lookup the user by id as > that is what is stored in the ClientSession. It would hit the keycloak > database as it is not cached yet. This lookup loads the cache for > the user. > > Getting in-memory zero-import to work is even more tricky. The issue is > that ClientSession and UserSession need to lookup clients by id. If > the > user is not in cache, then the cache needs to lookup the user by id > within storage. This lookup also needs to happen if a write operation > is performed on a cache user (getDelegateForUpdate()). So, Keycloak > needs to know that that ID is not in local storage and must be > looked up > from a fed provider. The ID must be formed so that the provider fed > provider can resolve the lookup. I could use a URI for the ID i.e. > > fed:{providerId}:{login-name} > > The problem with this is that this id would need to be larger than 36 > characters which is the current column size for UserEntity.id and any > other table that references users. I could possibly do: > > fed:{providerAlias}:{login-name} > > But its quite possible that combination would be larger than 36 > characters. We could also just shrink it to: > > fed:{login-name} > > But then we would have to iterate over every federation provider to > find > and load the user. > > So in summary: > * IDs need to expand from 36 characters to something larger. (255 > maybe). Don't some DBs have constraints on string primary key > size? DB > scripts could possibly be > * CachedUserProvider and UserFederationManager interfaces would need to > be refactored > * I don't think UserFederationProvider interface would need to change. > But users would have to code for in-memory rather than throwing a > switch > to just turn it on. > > > > > > > > > > > _______________________________________________ > 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/20151204/38c1a4ef/attachment-0001.html From bburke at redhat.com Fri Dec 4 09:37:19 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 4 Dec 2015 09:37:19 -0500 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <5660F7C0.5040202@redhat.com> References: <565F20F9.6050400@redhat.com> <565FBCD0.8010104@redhat.com> <56605FD2.8090607@redhat.com> <5660F7C0.5040202@redhat.com> Message-ID: <5661A51F.2070507@redhat.com> On 12/3/2015 9:17 PM, Adam Young wrote: > On 12/03/2015 10:29 AM, Bill Burke wrote: >> >> On 12/2/2015 10:53 PM, Adam Young wrote: >>>> Getting in-memory zero-import to work is even more tricky. The issue is >>>> that ClientSession and UserSession need to lookup clients by id. If the >>>> user is not in cache, then the cache needs to lookup the user by id >>>> within storage. This lookup also needs to happen if a write operation >>>> is performed on a cache user (getDelegateForUpdate()). So, Keycloak >>>> needs to know that that ID is not in local storage and must be looked up >>>> from a fed provider. The ID must be formed so that the provider fed >>>> provider can resolve the lookup. I could use a URI for the ID i.e. >>>> >>>> fed:{providerId}:{login-name} >>> I'd recommend this, and increasing the size of the Database column. >>> >> We have many deployments already and some have quite large user >> databases. Was really concerned that expanding the column size would >> piss a lot of people off because of the DB migration required. > > Migrations are a fact of life. SQL ALchemy has decent support for it, > and I've written it at least once in support of JBoss (back in 2000 IIRC). > > The trick is to leave the old columns around, but only use the new ones > for one iteration, so that old scripts don't fall apart horribly. Its > not perfect.... > We use liquibase. Its not the actual migration code that is a problem for us, it is the fact that these guys may have millions of users and personally I don't have a lot of experience in data migration scripts and how much pain there is take to expand the column and update indexes when a column size is changed for millions of records. You also need to understand that implementation is not what we need feedback on. We're all veterans here. What we need feedback on is use cases and how people are going to use this stuff. This whole thread started because I'm trying to get feedback on whether we shold just wait for Keycloak 2.0 to rework the entire user storage SPI or if we can do it now with minimal impact to the SPI and existing deployments. >> >> >> We were talking a few weeks ago about ALL of our IDs becoming URIs. >> roles, groups, realms, clients, etc. It would give us the flexibility >> of federating anything we wanted going further. > This is awesome, but does not need to be stored in the DB as an URL so > long as you can compose it. > URI not URL fed:{providerId}:{meaningful-user-id} is a URI. > >> For example, >> currently admins have to define roles and groups in keycloak. This >> sucks if they are already defined and controlled someplace else. >> >>> Keystoen did this, but then SHA256 hashed it, makuing it a 64 character >>> string. We found we were OK so long as we stayed under 255, as that was >>> the limit mysql imposed for the string columns. >>> >>>> The problem with this is that this id would need to be larger than 36 >>>> characters which is the current column size for UserEntity.id and any >>>> other table that references users. I could possibly do: >>>> >>>> fed:{providerAlias}:{login-name} >>>> >>>> But its quite possible that combination would be larger than 36 >>>> characters. We could also just shrink it to: >>>> >>>> fed:{login-name} >>>> >>>> But then we would have to iterate over every federation provider to find >>>> and load the user. >>> It gets trickier: you don;'t want one federation provider to step on >>> the login from an other: ayoung at coke is a different user from >>> ayoung at pepsi. Having the Id be something issued by Keycloak + something >>> that comes from the Federated IdP is necessary. >>> >> Not really. This is no different than a user logging into the >> user/password screen. Keycloak allows you to specify the order of >> federation providers, but doesn't handle conflicts, i.e. one LDAP server >> has the same username as another. > > You need to deal with this. The rules have changed with Federation, and > you will have to deconflict. Two LDAP server in one organization are > still under the management of a single user. KeyCloaks biggest potential > for new deployments is Multi IDP, where they are managed by different > services. If you don't make the IdPs safe to share the same table > space, you end up building the logic in to the code, and not being able > to enforce it in the DB. > I think we're talking about two different things. User Federation for us is User Storage Federation. One logical view of one or more identity stores. One login screen where user enters in their username and credentials and some logic behind the scenes to locate and discover and authenticate that user based on input from Keycloak login screens. Can even be a hybrid store where most metadata is stored in something like LDAP and additional data stored in Keycloak. Then we have brokering which is federating external IDPs. Here, the user picks which IDP they want to log into and Keycloak delegates authentication to that external IDP. An example of this is social login. Picking an IDP can even be done by hooking into Keycloak's authentication flow SPI, so a user could enter in a email address, and keycloak knows to route to an external IDP based on the domain name of the email address. You also need to understand that keycloak isn't just a SAML or OpenID Connect bridge. From the beginning we have strived to be a turnkey solution that provides all necessary login screens, forgot password, registration, account service management. >> >>> I like in memory, but there are many questions to answer, when a user >>> comes back a second time, what happens with their Id. I pushed for >>> ephemeral for Keystone, and we couldn't make it work. >>> >> We track sessions, have offline sessions, and track consents. So an ID >> cannot be temporary. > Temporary and ephemeral are two different things. If you can always > calculate the ID, and you always get the same ID for a user, you don't > necessarily need to write it down. > See above URI talk... Maybe you don't understand what we mean by "in-memory". Currently we import some aspects of each user into local storage even if the user lives in LDAP. We did this so that deployments of Keycloak can still use LDAP, but get the full features of Keycloak. There is a small but significant set of users that only want to use us as a SAML or OIDC bridge so in that case, it doesn't make sense to import anything. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 4 09:53:23 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 4 Dec 2015 09:53:23 -0500 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <56616CC1.8070306@redhat.com> References: <565F20F9.6050400@redhat.com> <56606086.6010908@redhat.com> <56606673.9070502@redhat.com> <566074EA.3060408@redhat.com> <566082AB.7070902@redhat.com> <56616CC1.8070306@redhat.com> Message-ID: <5661A8E3.6000906@redhat.com> On 12/4/2015 5:36 AM, Marek Posolda wrote: > Why it's bad to do simpler things? :-) > > AFAIK filter pattern (or interceptor/chain whatever you call it) is > proven to work in many places. The provider at level X can always decide > if it delegates call to method "getUserByXXX" to next provider (and then > proxy/cache or do whatever according to his logic) or return something > by itself. > I'm also trying to figure out something that is backward compatible with the current federation SPI > If I understand correctly your proposal, it requires > UserFederationProvider to decide, if it wants to import or just return > InMemoryUserModel . So if we want to support in-memory for LDAP, we will > need to have 2 versions of LDAPFederationProvider (current which imports > into userStorage() and another, which will return InMemoryUserModel > instances ). That's not ideal IMO. > > > As I mentioned before, there are also 2 additional usecases, which are > important to support IMO: > > 1) Case when admin changes some user attributes directly in LDAP and he > wants the LDAP data to be immediately visible in Keycloak. This is what > we currently support (see > FederationProvidersIntegrationTest.testDirectLDAPUpdate() ). Maybe I am > missing something with your proposal, but if we hardcode CacheProvider > to be always first, we lost this. > That's what I was afraid of with my proposal. You need to have a proxy in front of the cached UserModel to load certain attrbutes on-demand. You would need type of proxy callbacks to the Federation Provider. One proxy for a cached object and one for writes. Following me? Currently thats how we do it. If a user has been imported and cached, we proxy it after it is pulled from cache. > > Then assume the session.users().getUserByUsername is called: > 1) First delegate is UserFederationManager, so calling > UserFederationManager.getUserByUsername > 2) This line > https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/UserFederationManager.java#L180 > will call getNext().getUserByUsername() and returns null as the user was > not yet looked for this request. > 3) Going to federationProviders and call > LDAPFederationProvider.getUserByUsername > 4) LDAPFederationProvider query user in LDAP and calls > importUserFromLDAP . This calls session.userStorage().addUser, which > will put user into in-memory provider (I assume that > session.userStorage() will be kept and will always point to the next > delegate after UserFederationManager ). The LDAPFederationProvider will > then return LDAP proxy of UserModel. > I don't see how your proposal can work. As each chain is potentially different per user and you don't know what the chain is until you locate the user. Local keycloak would be cache=>JPA-UserModel. One fed provider might be cache=>In-Memory=>LDAP -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 4 11:14:09 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 4 Dec 2015 11:14:09 -0500 Subject: [keycloak-dev] in-memory only federated users In-Reply-To: <5661A8E3.6000906@redhat.com> References: <565F20F9.6050400@redhat.com> <56606086.6010908@redhat.com> <56606673.9070502@redhat.com> <566074EA.3060408@redhat.com> <566082AB.7070902@redhat.com> <56616CC1.8070306@redhat.com> <5661A8E3.6000906@redhat.com> Message-ID: <5661BBD1.5020408@redhat.com> On 12/4/2015 9:53 AM, Bill Burke wrote: > > > On 12/4/2015 5:36 AM, Marek Posolda wrote: >> Why it's bad to do simpler things? :-) >> >> AFAIK filter pattern (or interceptor/chain whatever you call it) is >> proven to work in many places. The provider at level X can always decide >> if it delegates call to method "getUserByXXX" to next provider (and then >> proxy/cache or do whatever according to his logic) or return something >> by itself. >> > > I'm also trying to figure out something that is backward compatible with > the current federation SPI > After a private chat on Google Hangout, Stian, Marek, and I decided to defer this feature until Keycloak 2.0. We are all a bit worried about instabilities that might incur if we hack this into the current SPI. We have a lot of ideas for 2.0 for improving the fedreation SPI and even merging it with the DB provider apis. We've been talking about it on mail list and on our weekly hangouts off and on for months, so I'm confident we know the direction we need to go, its just that since product is so close, we're gonna wait for in-memory until then. BIll -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 4 11:17:08 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 4 Dec 2015 11:17:08 -0500 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: <5660A6FE.9080903@redhat.com> References: <566092B5.8080208@redhat.com> <5660A6FE.9080903@redhat.com> Message-ID: <5661BC84.8090202@redhat.com> I would do this in 2 phases: Phase 1 keeps the master realm, but makes all the other changes we've talked about. Phase 2 ditches the master realm if we decide to do that. This might be problematic as I'm worried that our testsuite depends heavily on the master realm existing. On 12/3/2015 3:33 PM, Bill Burke wrote: > > > On 12/3/2015 2:19 PM, Stian Thorgersen wrote: >> +1000 >> >> This would simplify a lot of things. Currently, even though I know the >> code pretty well, I still get confused when it comes to admin roles, >> master admin clients and all that jazz. >> >> It would also simplify the admin endpoints and we can drop "realms" from >> urls. We could also drop "auth" from urls on the standalone Keycloak >> server. That would make URLs nicer. So it would be: >> >> //protocol/openid-connect/ >> //admin >> >> Instead of what we have atm: >> >> /auth/realms//protocol/openid-connect/ >> /auth/realms//admin >> >> I think we should have a dedicated create-realm role, rather than allow >> admin to do it. We should make it possible to enable/disable realm >> creation from within a specific realm. >> > > We do have a create-realm role. > >> One question with regards to trust users from one realm to another, how >> would you manage role permissions? > > What do you mean? I was thinking of something *REALLY* simple. If > Realm A trusts Realm B and User X in Realm B has "manage-clients" role > in Realm B, then he can manage clients in Realm A. That way you don't > have to deal with actual users, just roles. Does that make sense? > > > I think all permissions from one >> realm should be managed within the realm. We should also hide the >> security-admin-console from the clients list. >> > > > > >> We also need to figure out how to prevent the admin escalation problem >> we have. It should be possible to configure what roles a specific admin >> is allowed to grant to users. >> > > This is a different feature. This would not be what roles a specific > admin is allowed to grant, but rather what roles a specific role can > grant. Take the user out of the equation. > >> One question though. Instead of having many changes in 1.8 would it make >> more sense to just say enough is enough. Let's get started on 2.x and be >> a bit more free with breaking backwards compatibility. Then in 2.x we could: >> > > I don't know what the best thing is to do. I'm worried about having > enough time to bake stuff in community, but also don't want ugly shit > sitting in product for the next 10 years. See what we can get in by end > of December then release 1.8 mid January and stabilize until March? > Encourage people to upgrade to 1.8 at least to test drive? > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 4 11:23:16 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 4 Dec 2015 11:23:16 -0500 Subject: [keycloak-dev] inter-realm trust model Message-ID: <5661BDF4.5040508@redhat.com> To establish trust between realms I was thinking about a simple table: realm|trusted-realm|role Here's some example records: test-realm|master|manage-clients test-realm|master|view-users means "test-realm" trusts the "master" realm, but they can only "manage-clients" and "view-users" The "role" column would just be the name of the realm, not an id and would reference the "realm-management" client roles (which will be moved to security-admin-console client). -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Mon Dec 7 02:40:52 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 7 Dec 2015 08:40:52 +0100 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: <5661BC84.8090202@redhat.com> References: <566092B5.8080208@redhat.com> <5660A6FE.9080903@redhat.com> <5661BC84.8090202@redhat.com> Message-ID: I was thinking a bit more about trust between realms and I think that should be limited to authentication only. An admin with certain roles in one realm shouldn't necessarily have the same roles in another realm. So I think we need either a user that can exist in multiple realms or utilize identity brokering to get "linked" users. I'm worried if we allow roles from one realm to give admin permissions in another it will be hard to get a full picture of who has access to the realm. It may also give unintentional permissions. Also, if we introduce admins that can only manage a "group" of users or roles that specify what roles an admin can grant that would require users in the specific realm to manage. On 4 December 2015 at 17:17, Bill Burke wrote: > I would do this in 2 phases: > > Phase 1 keeps the master realm, but makes all the other changes we've > talked about. > > Phase 2 ditches the master realm if we decide to do that. This might be > problematic as I'm worried that our testsuite depends heavily on the > master realm existing. > > On 12/3/2015 3:33 PM, Bill Burke wrote: > > > > > > On 12/3/2015 2:19 PM, Stian Thorgersen wrote: > >> +1000 > >> > >> This would simplify a lot of things. Currently, even though I know the > >> code pretty well, I still get confused when it comes to admin roles, > >> master admin clients and all that jazz. > >> > >> It would also simplify the admin endpoints and we can drop "realms" from > >> urls. We could also drop "auth" from urls on the standalone Keycloak > >> server. That would make URLs nicer. So it would be: > >> > >> //protocol/openid-connect/ > >> //admin > >> > >> Instead of what we have atm: > >> > >> /auth/realms//protocol/openid-connect/ > >> /auth/realms//admin > >> > >> I think we should have a dedicated create-realm role, rather than allow > >> admin to do it. We should make it possible to enable/disable realm > >> creation from within a specific realm. > >> > > > > We do have a create-realm role. > > > >> One question with regards to trust users from one realm to another, how > >> would you manage role permissions? > > > > What do you mean? I was thinking of something *REALLY* simple. If > > Realm A trusts Realm B and User X in Realm B has "manage-clients" role > > in Realm B, then he can manage clients in Realm A. That way you don't > > have to deal with actual users, just roles. Does that make sense? > > > > > > I think all permissions from one > >> realm should be managed within the realm. We should also hide the > >> security-admin-console from the clients list. > >> > > > > > > > > > >> We also need to figure out how to prevent the admin escalation problem > >> we have. It should be possible to configure what roles a specific admin > >> is allowed to grant to users. > >> > > > > This is a different feature. This would not be what roles a specific > > admin is allowed to grant, but rather what roles a specific role can > > grant. Take the user out of the equation. > > > >> One question though. Instead of having many changes in 1.8 would it make > >> more sense to just say enough is enough. Let's get started on 2.x and be > >> a bit more free with breaking backwards compatibility. Then in 2.x we > could: > >> > > > > I don't know what the best thing is to do. I'm worried about having > > enough time to bake stuff in community, but also don't want ugly shit > > sitting in product for the next 10 years. See what we can get in by end > > of December then release 1.8 mid January and stabilize until March? > > Encourage people to upgrade to 1.8 at least to test drive? > > > > > > -- > 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/20151207/54b64e98/attachment-0001.html From sthorger at redhat.com Mon Dec 7 02:42:06 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 7 Dec 2015 08:42:06 +0100 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: References: <566092B5.8080208@redhat.com> <5660A6FE.9080903@redhat.com> <5661BC84.8090202@redhat.com> Message-ID: I don't think the testsuite will be to hard. The old integration testsuite relies mostly on "demo" realm. The new have limited places that rely on the admin realm, but there's one abstract class everything inherits from so we can create the equivalent realm there. On 7 December 2015 at 08:40, Stian Thorgersen wrote: > I was thinking a bit more about trust between realms and I think that > should be limited to authentication only. An admin with certain roles in > one realm shouldn't necessarily have the same roles in another realm. So I > think we need either a user that can exist in multiple realms or utilize > identity brokering to get "linked" users. I'm worried if we allow roles > from one realm to give admin permissions in another it will be hard to get > a full picture of who has access to the realm. It may also give > unintentional permissions. Also, if we introduce admins that can only > manage a "group" of users or roles that specify what roles an admin can > grant that would require users in the specific realm to manage. > > On 4 December 2015 at 17:17, Bill Burke wrote: > >> I would do this in 2 phases: >> >> Phase 1 keeps the master realm, but makes all the other changes we've >> talked about. >> >> Phase 2 ditches the master realm if we decide to do that. This might be >> problematic as I'm worried that our testsuite depends heavily on the >> master realm existing. >> >> On 12/3/2015 3:33 PM, Bill Burke wrote: >> > >> > >> > On 12/3/2015 2:19 PM, Stian Thorgersen wrote: >> >> +1000 >> >> >> >> This would simplify a lot of things. Currently, even though I know the >> >> code pretty well, I still get confused when it comes to admin roles, >> >> master admin clients and all that jazz. >> >> >> >> It would also simplify the admin endpoints and we can drop "realms" >> from >> >> urls. We could also drop "auth" from urls on the standalone Keycloak >> >> server. That would make URLs nicer. So it would be: >> >> >> >> //protocol/openid-connect/ >> >> //admin >> >> >> >> Instead of what we have atm: >> >> >> >> /auth/realms//protocol/openid-connect/ >> >> /auth/realms//admin >> >> >> >> I think we should have a dedicated create-realm role, rather than allow >> >> admin to do it. We should make it possible to enable/disable realm >> >> creation from within a specific realm. >> >> >> > >> > We do have a create-realm role. >> > >> >> One question with regards to trust users from one realm to another, how >> >> would you manage role permissions? >> > >> > What do you mean? I was thinking of something *REALLY* simple. If >> > Realm A trusts Realm B and User X in Realm B has "manage-clients" role >> > in Realm B, then he can manage clients in Realm A. That way you don't >> > have to deal with actual users, just roles. Does that make sense? >> > >> > >> > I think all permissions from one >> >> realm should be managed within the realm. We should also hide the >> >> security-admin-console from the clients list. >> >> >> > >> > >> > >> > >> >> We also need to figure out how to prevent the admin escalation problem >> >> we have. It should be possible to configure what roles a specific admin >> >> is allowed to grant to users. >> >> >> > >> > This is a different feature. This would not be what roles a specific >> > admin is allowed to grant, but rather what roles a specific role can >> > grant. Take the user out of the equation. >> > >> >> One question though. Instead of having many changes in 1.8 would it >> make >> >> more sense to just say enough is enough. Let's get started on 2.x and >> be >> >> a bit more free with breaking backwards compatibility. Then in 2.x we >> could: >> >> >> > >> > I don't know what the best thing is to do. I'm worried about having >> > enough time to bake stuff in community, but also don't want ugly shit >> > sitting in product for the next 10 years. See what we can get in by end >> > of December then release 1.8 mid January and stabilize until March? >> > Encourage people to upgrade to 1.8 at least to test drive? >> > >> > >> >> -- >> 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/20151207/68f9de51/attachment.html From sthorger at redhat.com Mon Dec 7 02:43:02 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 7 Dec 2015 08:43:02 +0100 Subject: [keycloak-dev] inter-realm trust model In-Reply-To: <5661BDF4.5040508@redhat.com> References: <5661BDF4.5040508@redhat.com> Message-ID: Added this comment to the previous thread, but copy/pasting here: I was thinking a bit more about trust between realms and I think that should be limited to authentication only. An admin with certain roles in one realm shouldn't necessarily have the same roles in another realm. So I think we need either a user that can exist in multiple realms or utilize identity brokering to get "linked" users. I'm worried if we allow roles from one realm to give admin permissions in another it will be hard to get a full picture of who has access to the realm. It may also give unintentional permissions. Also, if we introduce admins that can only manage a "group" of users or roles that specify what roles an admin can grant that would require users in the specific realm to manage. On 4 December 2015 at 17:23, Bill Burke wrote: > To establish trust between realms I was thinking about a simple table: > > realm|trusted-realm|role > > Here's some example records: > > test-realm|master|manage-clients > test-realm|master|view-users > > means > > "test-realm" trusts the "master" realm, but they can only > "manage-clients" and "view-users" > > The "role" column would just be the name of the realm, not an id and > would reference the "realm-management" client roles (which will be moved > to security-admin-console client). > > -- > 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/20151207/39608165/attachment.html From mposolda at redhat.com Mon Dec 7 03:34:12 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 7 Dec 2015 09:34:12 +0100 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: <566092B5.8080208@redhat.com> References: <566092B5.8080208@redhat.com> Message-ID: <56654484.2080104@redhat.com> On 03/12/15 20:06, Bill Burke wrote: > * We can remove the realm-management client in each realm and just merge > the roles into security-admin-console. Not sure about this one TBH. Also in 1.7 we introduced the "admin-cli" client, which is used for direct-grants and has scope to realm-management similarly like security-admin-console. The security-admin-console is used for UI of admin console (javascript client) when admin-cli is used for direct access to admin REST endpoints for example from admin-client. Marek From sthorger at redhat.com Mon Dec 7 03:36:57 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 7 Dec 2015 09:36:57 +0100 Subject: [keycloak-dev] Realm cache In-Reply-To: <56605B4F.4060403@redhat.com> References: <56605B4F.4060403@redhat.com> Message-ID: On 3 December 2015 at 16:10, Bill Burke wrote: > On 12/3/2015 7:50 AM, Stian Thorgersen wrote: > > There's still some outstanding issues with the realm cache. It works, > > but can and should be improved for 1.8. > > > > One issue was that once the realm is updated any methods on clients, > > roles or groups returns the underlying adapter instead of the cache > > adapters. As a work around in 1.7 it now ejects all clients for a realm > > when it sees any changes. > > > > Why is that a bad thing? Usually, roles groups, and clients are not > accessed in the same session as a realm update. Realms are usually not > updated. Client registration/unregistration is rare too for most apps. > The vast majority (90%+?) of access is read-only for realms and clients. > The problem is that once you return the jpa client adapter instead of the cache client adapter the cache no longer knows it should be invalidated. So if you do: realm.set... client = realm.getClientById("") client.set... The realm is invalidated, but not the client. That's why I had to add a work-around that invalidates all clients of a realm when the realm is changed. I agree writes are rare. If we end up invalidating everything for a realm for every update that's not a good thing either though. Also, we need to consider the way things are invalidated. Sending a single message to the cluster that a realm is invalidated is ok. However, if we send a message for each realm, client and role for each update that would be terrible. > > > We have a few potential ways to solve this: > > > > a) try to always return cache adapters - I went down this road attacking > > it from a few different approaches, but was never successful as there > > was always something that didn't work > > See above, I don't think this is an issue. What we should do is > identify if any updates are performed on realms/clients per login/token > refresh and remove or isolate them so that the realm/client caches > aren't invalidated. > +1 At least for 1.x that would be the target. After 1.x I'd like to have a separate store for clients like we do for users. I think in some scenarios there may be 1K+ clients. > > > b) only cache realms and have everything else hang off it - this is my > > preferred option for now. As long as updating clients requires > > invalidating the realm it seems a bit over the top to have separate > > caches for everything > > Why can't you keep it as it is? > > RealmAdapter.getDelegateForUpdate() always registers a realm > invalidation. add/remove client are methods on RealmModel so the realm > cache was always invalidated. The only time you need to invalidate the > realm is when clientId is changed. > As I said above if realm returns jpa adapter for clients when you retrieve clients then updates to clients are not visible to the cache after the realm has been updated. > > > c) make the cache smarter - instead of invalidating a realm, make sure > > we add/remove the clients, etc.. > > > > Its an invalidation cache, so "C" won't work unless you have a separate > cache for the client list. So you'd need a realm cache, client list > cache, and client cache. > > > We also need more automated testing around clustering. Late in 1.7 > > release process I identified that caches where invalidated when other > > nodes loaded things to it, so effectively the cache wasn't working at > > all in a cluster. > > > > Thoughts? > > > > I think this is a bit of effort for little gain. users will only see a > difference if there is a lot of realm adminstration happening. > For small/medium installations there's probably little realm admin going on. However, on big installations where performance is crucial I imagine that some admin is going to be relatively frequent so it's worth limiting what is invalidated. > > > -- > 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/20151207/1422af42/attachment-0001.html From sthorger at redhat.com Mon Dec 7 03:38:28 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 7 Dec 2015 09:38:28 +0100 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: <56654484.2080104@redhat.com> References: <566092B5.8080208@redhat.com> <56654484.2080104@redhat.com> Message-ID: Should we not have one client for the roles that represents the services (bearer-only), then have a separate clients for admin GUI and CLI? On 7 December 2015 at 09:34, Marek Posolda wrote: > On 03/12/15 20:06, Bill Burke wrote: > > * We can remove the realm-management client in each realm and just merge > > the roles into security-admin-console. > Not sure about this one TBH. Also in 1.7 we introduced the "admin-cli" > client, which is used for direct-grants and has scope to > realm-management similarly like security-admin-console. The > security-admin-console is used for UI of admin console (javascript > client) when admin-cli is used for direct access to admin REST endpoints > for example from admin-client. > > 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/20151207/1aec7203/attachment.html From mposolda at redhat.com Mon Dec 7 03:45:47 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 7 Dec 2015 09:45:47 +0100 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: References: <566092B5.8080208@redhat.com> Message-ID: <5665473B.4040909@redhat.com> On 03/12/15 20:19, Stian Thorgersen wrote: > +1000 > > This would simplify a lot of things. Currently, even though I know the > code pretty well, I still get confused when it comes to admin roles, > master admin clients and all that jazz. > > It would also simplify the admin endpoints and we can drop "realms" > from urls. We could also drop "auth" from urls on the standalone > Keycloak server. That would make URLs nicer. So it would be: > > //protocol/openid-connect/ > //admin > > Instead of what we have atm: > > /auth/realms//protocol/openid-connect/ > /auth/realms//admin > > I think we should have a dedicated create-realm role, rather than > allow admin to do it. We should make it possible to enable/disable > realm creation from within a specific realm. > > One question with regards to trust users from one realm to another, > how would you manage role permissions? I think all permissions from > one realm should be managed within the realm. We should also hide the > security-admin-console from the clients list. Generally I am not sure if we should hide things from users. Isn't it better to add some "system" flag, so people can see that this is special builtin client? Personally I don't like systems, which hide things from users. It usually adds confusions. Especially when you are newbie and you try to understand things (for example: How is possible that I am seeing security-admin-client roles here, when I am not seeing security-admin-console in client list? How is possible I am seeing client_id=security-admin-console in the URI, but there is not any client called security-admin-console in the list? etc. ). IMO Keycloak admins are usually technical users and want to understand things. Also IMO admin console should allow everything which is possible through direct DB updating. Marek > > We also need to figure out how to prevent the admin escalation problem > we have. It should be possible to configure what roles a specific > admin is allowed to grant to users. > > One question though. Instead of having many changes in 1.8 would it > make more sense to just say enough is enough. Let's get started on 2.x > and be a bit more free with breaking backwards compatibility. Then in > 2.x we could: > > * Improve SPIs - especially model SPIs and user federation SPIs > * Remove master realm > * Add role namespaces > * Clean-up URLs > * Clean-up admin endpoints > * Etc... > > On 3 December 2015 at 20:06, Bill Burke > wrote: > > I'm thinking that getting rid of the master realm would allow us to > clean up some things we've wanted to clean up for some time. > Here's what > I have in mind. > > * There is no master realm > * Realm admins can create other realms > * You can set up trust from one realm to another. Just realms > that are > stored in that keycloak deployment. No remote stuff. > * To keep it simple, the admin console in the realm would just have a > "Trust" tab somewhere with a list of realms you trust or want to > trust. > When you trust a realm, any users that have admin roles in that > trusted realm will have the same roles within the current realm. > * When users log into the admin console, the list of realms that trust > the logged into realm will be listed as realms the user can manage. > * When a new realm is created, the new realm automatically trust the > realm that created it. > * If there is a trust relationship impersonation will work no matter > what realm it is > * We can remove the realm-management client in each realm and just > merge > the roles into security-admin-console. > * For migration, we just import the master realm and set up trust > between the master realm and every other realm. > > > Once we do all this we can now look at satisfying the > cannot-have-a-default-password requirement passed down by the security > audit team. We can have a welcome page that just asks "To create your > first realm, click here". > -- > 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/20151207/c9f8ac0d/attachment.html From mposolda at redhat.com Mon Dec 7 03:48:35 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 7 Dec 2015 09:48:35 +0100 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: References: <566092B5.8080208@redhat.com> <56654484.2080104@redhat.com> Message-ID: <566547E3.4090108@redhat.com> +1. That's what we have now and it's good pattern IMO. Marek On 07/12/15 09:38, Stian Thorgersen wrote: > Should we not have one client for the roles that represents the > services (bearer-only), then have a separate clients for admin GUI and > CLI? > > On 7 December 2015 at 09:34, Marek Posolda > wrote: > > On 03/12/15 20:06, Bill Burke wrote: > > * We can remove the realm-management client in each realm and > just merge > > the roles into security-admin-console. > Not sure about this one TBH. Also in 1.7 we introduced the "admin-cli" > client, which is used for direct-grants and has scope to > realm-management similarly like security-admin-console. The > security-admin-console is used for UI of admin console (javascript > client) when admin-cli is used for direct access to admin REST > endpoints > for example from admin-client. > > 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/20151207/b6c5a4f5/attachment.html From mposolda at redhat.com Mon Dec 7 03:56:26 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 7 Dec 2015 09:56:26 +0100 Subject: [keycloak-dev] Realm cache In-Reply-To: References: <56605B4F.4060403@redhat.com> Message-ID: <566549BA.3060403@redhat.com> On 07/12/15 09:36, Stian Thorgersen wrote: > > > On 3 December 2015 at 16:10, Bill Burke > wrote: > > On 12/3/2015 7:50 AM, Stian Thorgersen wrote: > > There's still some outstanding issues with the realm cache. It > works, > > but can and should be improved for 1.8. > > > > One issue was that once the realm is updated any methods on clients, > > roles or groups returns the underlying adapter instead of the cache > > adapters. As a work around in 1.7 it now ejects all clients for > a realm > > when it sees any changes. > > > > Why is that a bad thing? Usually, roles groups, and clients are not > accessed in the same session as a realm update. Realms are > usually not > updated. Client registration/unregistration is rare too for most > apps. > The vast majority (90%+?) of access is read-only for realms and > clients. > > > The problem is that once you return the jpa client adapter instead of > the cache client adapter the cache no longer knows it should be > invalidated. So if you do: > > realm.set... > client = realm.getClientById("") > client.set... > > The realm is invalidated, but not the client. That's why I had to add > a work-around that invalidates all clients of a realm when the realm > is changed. > > I agree writes are rare. If we end up invalidating everything for a > realm for every update that's not a good thing either though. Depends. It seems that update realm settings is so rare operation, that it's likely not a problem to be rather defensive and invalidate everything (unless we figure out easy and safe way to not do it). On the other hand add/remove role is possibly more common, so here we should be likely more smart in invalidating stuff. Marek > > Also, we need to consider the way things are invalidated. Sending a > single message to the cluster that a realm is invalidated is ok. > However, if we send a message for each realm, client and role for each > update that would be terrible. > > > > We have a few potential ways to solve this: > > > > a) try to always return cache adapters - I went down this road > attacking > > it from a few different approaches, but was never successful as > there > > was always something that didn't work > > See above, I don't think this is an issue. What we should do is > identify if any updates are performed on realms/clients per > login/token > refresh and remove or isolate them so that the realm/client caches > aren't invalidated. > > > +1 At least for 1.x that would be the target. After 1.x I'd like to > have a separate store for clients like we do for users. I think in > some scenarios there may be 1K+ clients. > > > > b) only cache realms and have everything else hang off it - this > is my > > preferred option for now. As long as updating clients requires > > invalidating the realm it seems a bit over the top to have separate > > caches for everything > > Why can't you keep it as it is? > > RealmAdapter.getDelegateForUpdate() always registers a realm > invalidation. add/remove client are methods on RealmModel so the > realm > cache was always invalidated. The only time you need to > invalidate the > realm is when clientId is changed. > > > As I said above if realm returns jpa adapter for clients when you > retrieve clients then updates to clients are not visible to the cache > after the realm has been updated. > > > > c) make the cache smarter - instead of invalidating a realm, > make sure > > we add/remove the clients, etc.. > > > > Its an invalidation cache, so "C" won't work unless you have a > separate > cache for the client list. So you'd need a realm cache, client list > cache, and client cache. > > > We also need more automated testing around clustering. Late in 1.7 > > release process I identified that caches where invalidated when > other > > nodes loaded things to it, so effectively the cache wasn't > working at > > all in a cluster. > > > > Thoughts? > > > > I think this is a bit of effort for little gain. users will only see a > difference if there is a lot of realm adminstration happening. > > > For small/medium installations there's probably little realm admin > going on. However, on big installations where performance is crucial I > imagine that some admin is going to be relatively frequent so it's > worth limiting what is invalidated. > > > > -- > 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/20151207/2e6b691e/attachment-0001.html From sthorger at redhat.com Mon Dec 7 04:50:08 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 7 Dec 2015 10:50:08 +0100 Subject: [keycloak-dev] Realm cache In-Reply-To: <566549BA.3060403@redhat.com> References: <56605B4F.4060403@redhat.com> <566549BA.3060403@redhat.com> Message-ID: I think it's ok for 1.x. We just need to make sure there's not to many invalidation messages sent to the cluster. If an invalidation of a realm results in a message for the realm and one message for each client, role and group, it's not going to be very nice. On 7 December 2015 at 09:56, Marek Posolda wrote: > On 07/12/15 09:36, Stian Thorgersen wrote: > > > > On 3 December 2015 at 16:10, Bill Burke wrote: > >> On 12/3/2015 7:50 AM, Stian Thorgersen wrote: >> > There's still some outstanding issues with the realm cache. It works, >> > but can and should be improved for 1.8. >> > >> > One issue was that once the realm is updated any methods on clients, >> > roles or groups returns the underlying adapter instead of the cache >> > adapters. As a work around in 1.7 it now ejects all clients for a realm >> > when it sees any changes. >> > >> >> Why is that a bad thing? Usually, roles groups, and clients are not >> accessed in the same session as a realm update. Realms are usually not >> updated. Client registration/unregistration is rare too for most apps. >> The vast majority (90%+?) of access is read-only for realms and clients. >> > > The problem is that once you return the jpa client adapter instead of the > cache client adapter the cache no longer knows it should be invalidated. So > if you do: > > realm.set... > client = realm.getClientById("") > client.set... > > The realm is invalidated, but not the client. That's why I had to add a > work-around that invalidates all clients of a realm when the realm is > changed. > > I agree writes are rare. If we end up invalidating everything for a realm > for every update that's not a good thing either though. > > Depends. It seems that update realm settings is so rare operation, that > it's likely not a problem to be rather defensive and invalidate everything > (unless we figure out easy and safe way to not do it). On the other hand > add/remove role is possibly more common, so here we should be likely more > smart in invalidating stuff. > > Marek > > > > Also, we need to consider the way things are invalidated. Sending a single > message to the cluster that a realm is invalidated is ok. However, if we > send a message for each realm, client and role for each update that would > be terrible. > > > >> >> > We have a few potential ways to solve this: >> > >> > a) try to always return cache adapters - I went down this road attacking >> > it from a few different approaches, but was never successful as there >> > was always something that didn't work >> >> See above, I don't think this is an issue. What we should do is >> identify if any updates are performed on realms/clients per login/token >> refresh and remove or isolate them so that the realm/client caches >> aren't invalidated. >> > > +1 At least for 1.x that would be the target. After 1.x I'd like to have a > separate store for clients like we do for users. I think in some scenarios > there may be 1K+ clients. > > >> >> > b) only cache realms and have everything else hang off it - this is my >> > preferred option for now. As long as updating clients requires >> > invalidating the realm it seems a bit over the top to have separate >> > caches for everything >> >> Why can't you keep it as it is? >> >> RealmAdapter.getDelegateForUpdate() always registers a realm >> invalidation. add/remove client are methods on RealmModel so the realm >> cache was always invalidated. The only time you need to invalidate the >> realm is when clientId is changed. >> > > As I said above if realm returns jpa adapter for clients when you retrieve > clients then updates to clients are not visible to the cache after the > realm has been updated. > > >> >> > c) make the cache smarter - instead of invalidating a realm, make sure >> > we add/remove the clients, etc.. >> > >> >> Its an invalidation cache, so "C" won't work unless you have a separate >> cache for the client list. So you'd need a realm cache, client list >> cache, and client cache. >> >> > We also need more automated testing around clustering. Late in 1.7 >> > release process I identified that caches where invalidated when other >> > nodes loaded things to it, so effectively the cache wasn't working at >> > all in a cluster. >> > >> > Thoughts? >> > >> >> I think this is a bit of effort for little gain. users will only see a >> difference if there is a lot of realm adminstration happening. >> > > For small/medium installations there's probably little realm admin going > on. However, on big installations where performance is crucial I imagine > that some admin is going to be relatively frequent so it's worth limiting > what is invalidated. > > >> >> >> -- >> 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/20151207/f1656765/attachment.html From mhajas at redhat.com Mon Dec 7 07:56:40 2015 From: mhajas at redhat.com (Michal Hajas) Date: Mon, 7 Dec 2015 07:56:40 -0500 (EST) Subject: [keycloak-dev] Disabling SAML client In-Reply-To: <1588330903.31722839.1449492228760.JavaMail.zimbra@redhat.com> Message-ID: <513318823.31730484.1449493000181.JavaMail.zimbra@redhat.com> Hi, I am wondering what should happen in second scenario below. I have working SAML client and try to disable client in admin console in next two scenarios: First: 1. Disable client in admin console 2. Try to access client URL -> I am getting "Login requester not enabled". I think this behavior is correct. Second: 1. Login to client 2. Disable client in admin console 3. Nothing happens, secured resource is still available, even after some time. Is it correct? Shouldn't keycloak forbid to refresh token or somehow restrict accessing secured resource? Thank you, Michal Hajas. From erik.mulder at docdatapayments.com Mon Dec 7 09:46:39 2015 From: erik.mulder at docdatapayments.com (Erik Mulder) Date: Mon, 7 Dec 2015 15:46:39 +0100 Subject: [keycloak-dev] Add custom REST paths? New SPI? References: <565F017B.2000503@redhat.com> <565F052A.1020001@redhat.com> <565F0716.3060505@redhat.com> <565F089C.3090400@redhat.com> <565F0EDC.2040500@redhat.com> <565F10AA.2080306@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> Message-ID: <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> As some of you might know, our team is busy adding data to the keycloak system to incorporate some custom authorization information in the access token. So far we've successfully extended the JPA entities, Liquibase table definitions and added a custom mapper to put that data in the access token. All of this without custom modifications to the original keycloak sources. This is working great, thanks for the support so far! I know I've promised some PR's for this and they will come, but first we'd like to get everything fully working, so we know it's a well functioning whole. The last piece of the puzzle is extending the REST services to include CRUD actions for our custom resources. I've been looking into the way RESTEasy/JAX-RS works and it seems to me that in the current implementation there is no way to add extra paths. As I see it now, the KeycloakApplication class will register some singletons in it's constructor and that's that. No way to extend or to 'interfere' there. So my question is: is there any 'official' way to add extra REST paths to Keycloak? If not, is it an idea to add this as a new SPI? The current code for adding root paths in the KeycloakApplication constructor lists: singletons.add(new ServerVersionResource()); singletons.add(new RealmsResource()); singletons.add(new AdminRoot()); So just plain contructor calls. That seems like an easy target for 'SPI-ing' :-). Or just leave the current ones 'hardcoded' and add an SPI for custom extensions. Your thoughts on this please. As before, I'm happy to implement this myself, but I'd like to discuss it first, so a future PR will be honored. From psilva at redhat.com Mon Dec 7 10:03:04 2015 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 7 Dec 2015 10:03:04 -0500 (EST) Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> References: <565F017B.2000503@redhat.com> <565F0EDC.2040500@redhat.com> <565F10AA.2080306@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> Message-ID: <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> I've done something at this regard, where you can use a SPI in order to plug additional APIs for: * Realm Admin RESTFul API (eg.: used by admin console) * Realm RESFTFul API (eg.: to plug additional endpoints for realms) The two Provider interfaces are very simple and just provide a single method: Object getResource(String pathName); Where pathName is the path that must be resolved to your custom JAX-RS resource. The factories are also very simple and allows you to build those resources for the current Realm and KeycloakSession. Eg.: RealmResourceProvider create(RealmModel realm, KeycloakSession keycloakSession); Do you need something other than that ? Regards. Pedro Igor ----- Original Message ----- From: "Erik Mulder" To: keycloak-dev at lists.jboss.org Sent: Monday, December 7, 2015 12:46:39 PM Subject: [keycloak-dev] Add custom REST paths? New SPI? As some of you might know, our team is busy adding data to the keycloak system to incorporate some custom authorization information in the access token. So far we've successfully extended the JPA entities, Liquibase table definitions and added a custom mapper to put that data in the access token. All of this without custom modifications to the original keycloak sources. This is working great, thanks for the support so far! I know I've promised some PR's for this and they will come, but first we'd like to get everything fully working, so we know it's a well functioning whole. The last piece of the puzzle is extending the REST services to include CRUD actions for our custom resources. I've been looking into the way RESTEasy/JAX-RS works and it seems to me that in the current implementation there is no way to add extra paths. As I see it now, the KeycloakApplication class will register some singletons in it's constructor and that's that. No way to extend or to 'interfere' there. So my question is: is there any 'official' way to add extra REST paths to Keycloak? If not, is it an idea to add this as a new SPI? The current code for adding root paths in the KeycloakApplication constructor lists: singletons.add(new ServerVersionResource()); singletons.add(new RealmsResource()); singletons.add(new AdminRoot()); So just plain contructor calls. That seems like an easy target for 'SPI-ing' :-). Or just leave the current ones 'hardcoded' and add an SPI for custom extensions. Your thoughts on this please. As before, I'm happy to implement this myself, but I'd like to discuss it first, so a future PR will be honored. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Mon Dec 7 10:29:00 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 7 Dec 2015 10:29:00 -0500 Subject: [keycloak-dev] Disabling SAML client In-Reply-To: <513318823.31730484.1449493000181.JavaMail.zimbra@redhat.com> References: <513318823.31730484.1449493000181.JavaMail.zimbra@redhat.com> Message-ID: <5665A5BC.8000109@redhat.com> On 12/7/2015 7:56 AM, Michal Hajas wrote: > Hi, > > I am wondering what should happen in second scenario below. > > I have working SAML client and try to disable client in admin console in next two scenarios: > > First: > 1. Disable client in admin console > 2. Try to access client URL -> I am getting "Login requester not enabled". I think this behavior is correct. > > Second: > 1. Login to client > 2. Disable client in admin console > 3. Nothing happens, secured resource is still available, even after some time. > > Is it correct? Shouldn't keycloak forbid to refresh token or somehow restrict accessing secured resource? > Good catch. Looks like when refresh token and/or the client-auth flow was added, the check for disabled client was lost. Both in the logic and in the testsuite. https://issues.jboss.org/browse/KEYCLOAK-2204 FYI though, Keycloak does not broadcast disabled client events. We let token timeouts and token refresh handle that. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Dec 7 10:31:39 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 7 Dec 2015 10:31:39 -0500 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: References: <566092B5.8080208@redhat.com> <56654484.2080104@redhat.com> Message-ID: <5665A65B.9030107@redhat.com> Why? On 12/7/2015 3:38 AM, Stian Thorgersen wrote: > Should we not have one client for the roles that represents the services > (bearer-only), then have a separate clients for admin GUI and CLI? > > On 7 December 2015 at 09:34, Marek Posolda > wrote: > > On 03/12/15 20:06, Bill Burke wrote: > > * We can remove the realm-management client in each realm and just merge > > the roles into security-admin-console. > Not sure about this one TBH. Also in 1.7 we introduced the "admin-cli" > client, which is used for direct-grants and has scope to > realm-management similarly like security-admin-console. The > security-admin-console is used for UI of admin console (javascript > client) when admin-cli is used for direct access to admin REST endpoints > for example from admin-client. > > 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 bburke at redhat.com Mon Dec 7 10:36:26 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 7 Dec 2015 10:36:26 -0500 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: <566547E3.4090108@redhat.com> References: <566092B5.8080208@redhat.com> <56654484.2080104@redhat.com> <566547E3.4090108@redhat.com> Message-ID: <5665A77A.9070002@redhat.com> Sorry, makes sense now after reading your exchange. In practice though, does it matter to have this split? Is it not better to consolidate into one client? On 12/7/2015 3:48 AM, Marek Posolda wrote: > +1. That's what we have now and it's good pattern IMO. > > Marek > > On 07/12/15 09:38, Stian Thorgersen wrote: >> Should we not have one client for the roles that represents the >> services (bearer-only), then have a separate clients for admin GUI and >> CLI? >> >> On 7 December 2015 at 09:34, Marek Posolda > > wrote: >> >> On 03/12/15 20:06, Bill Burke wrote: >> > * We can remove the realm-management client in each realm and >> just merge >> > the roles into security-admin-console. >> Not sure about this one TBH. Also in 1.7 we introduced the "admin-cli" >> client, which is used for direct-grants and has scope to >> realm-management similarly like security-admin-console. The >> security-admin-console is used for UI of admin console (javascript >> client) when admin-cli is used for direct access to admin REST >> endpoints >> for example from admin-client. >> >> 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 mposolda at redhat.com Mon Dec 7 11:02:17 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 7 Dec 2015 17:02:17 +0100 Subject: [keycloak-dev] Disabling SAML client In-Reply-To: <5665A5BC.8000109@redhat.com> References: <513318823.31730484.1449493000181.JavaMail.zimbra@redhat.com> <5665A5BC.8000109@redhat.com> Message-ID: <5665AD89.60704@redhat.com> It seems that it works for OIDC clients. Just added a comment to https://issues.jboss.org/browse/KEYCLOAK-2204 But note, this email is about SAML client. Not sure if SAML has something like "refresh token" ? I guess not, so once SAML client successfully login into application, the authenticated session on application side is valid until HTTP Session expired. Marek On 07/12/15 16:29, Bill Burke wrote: > > On 12/7/2015 7:56 AM, Michal Hajas wrote: >> Hi, >> >> I am wondering what should happen in second scenario below. >> >> I have working SAML client and try to disable client in admin console in next two scenarios: >> >> First: >> 1. Disable client in admin console >> 2. Try to access client URL -> I am getting "Login requester not enabled". I think this behavior is correct. >> >> Second: >> 1. Login to client >> 2. Disable client in admin console >> 3. Nothing happens, secured resource is still available, even after some time. >> >> Is it correct? Shouldn't keycloak forbid to refresh token or somehow restrict accessing secured resource? >> > Good catch. Looks like when refresh token and/or the client-auth flow > was added, the check for disabled client was lost. Both in the logic > and in the testsuite. > > https://issues.jboss.org/browse/KEYCLOAK-2204 > > FYI though, Keycloak does not broadcast disabled client events. We let > token timeouts and token refresh handle that. > From ayoung at redhat.com Mon Dec 7 13:25:16 2015 From: ayoung at redhat.com (Adam Young) Date: Mon, 7 Dec 2015 13:25:16 -0500 Subject: [keycloak-dev] inter-realm trust model In-Reply-To: References: <5661BDF4.5040508@redhat.com> Message-ID: <5665CF0C.20205@redhat.com> On 12/07/2015 02:43 AM, Stian Thorgersen wrote: > Added this comment to the previous thread, but copy/pasting here: > > I was thinking a bit more about trust between realms and I think that > should be limited to authentication only. An admin with certain roles > in one realm shouldn't necessarily have the same roles in another > realm. So I think we need either a user that can exist in multiple > realms or utilize identity brokering to get "linked" users. I'm > worried if we allow roles from one realm to give admin permissions in > another it will be hard to get a full picture of who has access to the > realm. It may also give unintentional permissions. Also, if we > introduce admins that can only manage a "group" of users or roles that > specify what roles an admin can grant that would require users in the > specific realm to manage. Again to use the Keystone comparison-other. A Domain in OpenStack is the top level entity for ownership. Under domains in *identity* you have \users and groups. Under domains in "resource" you have projects. I think projects most map to Realms in Keycloak. A user is a resource to be managed by a domain. The fact that a specific domain owns the user does not give the user any role assignment in that domain; it is just ownership of the record. All role assignments are on the "resource" side of Keystone. A user gets a role assignment on a project or a domain. Just about everything in Keystone has both a name and an id. For the majority, these the IDs are UUIDs. An assignement is then a tuple: actor_id, target_id, role_id. Actor is either user or group. Target is either project or domain. Role is enforced by name, but assigned by ID. I've been calling this "Scoped RBAC" to contrast it with NIST, where role assignments are not scoped to some namespace. The same would work for Keycloak: a Role is always assigned on a Realm, never just a global role assignment. What becomes important, then, is that the application, or whatever is requesting the set of roels for a user, get the right set for the scope. When I log in to Wordpress for Marketing I get a different set of roles listed from when I log in to Wordpress for Engineering. Now, I feel like Domains are bad extension, that we should have just made projects hierarchical. Are Realms hierarchical in Keycloak? > > On 4 December 2015 at 17:23, Bill Burke > wrote: > > To establish trust between realms I was thinking about a simple table: > > realm|trusted-realm|role > > Here's some example records: > > test-realm|master|manage-clients > test-realm|master|view-users > > means > > "test-realm" trusts the "master" realm, but they can only > "manage-clients" and "view-users" > > The "role" column would just be the name of the realm, not an id and > would reference the "realm-management" client roles (which will be > moved > to security-admin-console client). > > -- > 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/20151207/2ad76e5e/attachment.html From sthorger at redhat.com Mon Dec 7 13:53:27 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 7 Dec 2015 19:53:27 +0100 Subject: [keycloak-dev] getting rid of master realm In-Reply-To: <5665A77A.9070002@redhat.com> References: <566092B5.8080208@redhat.com> <56654484.2080104@redhat.com> <566547E3.4090108@redhat.com> <5665A77A.9070002@redhat.com> Message-ID: I think in practice it makes sense. The bearer-only should not be shown in clients list as it's just about roles. The admin console should have redirect-uris for the admin console, but not have direct grant enabled. Finally the admin cli should only have direct grant enabled. That way they can be configured independently. As they are separate things and this is how we recommend others to organize their clients then we should do the same. On 7 December 2015 at 16:36, Bill Burke wrote: > Sorry, makes sense now after reading your exchange. In practice though, > does it matter to have this split? Is it not better to consolidate into > one client? > > On 12/7/2015 3:48 AM, Marek Posolda wrote: > >> +1. That's what we have now and it's good pattern IMO. >> >> Marek >> >> On 07/12/15 09:38, Stian Thorgersen wrote: >> >>> Should we not have one client for the roles that represents the >>> services (bearer-only), then have a separate clients for admin GUI and >>> CLI? >>> >>> On 7 December 2015 at 09:34, Marek Posolda >> > wrote: >>> >>> On 03/12/15 20:06, Bill Burke wrote: >>> > * We can remove the realm-management client in each realm and >>> just merge >>> > the roles into security-admin-console. >>> Not sure about this one TBH. Also in 1.7 we introduced the >>> "admin-cli" >>> client, which is used for direct-grants and has scope to >>> realm-management similarly like security-admin-console. The >>> security-admin-console is used for UI of admin console (javascript >>> client) when admin-cli is used for direct access to admin REST >>> endpoints >>> for example from admin-client. >>> >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151207/811c104f/attachment.html From bburke at redhat.com Mon Dec 7 17:00:05 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 7 Dec 2015 17:00:05 -0500 Subject: [keycloak-dev] inter-realm trust model In-Reply-To: <5665CF0C.20205@redhat.com> References: <5661BDF4.5040508@redhat.com> <5665CF0C.20205@redhat.com> Message-ID: <56660165.5090704@redhat.com> On 12/7/2015 1:25 PM, Adam Young wrote: > On 12/07/2015 02:43 AM, Stian Thorgersen wrote: >> Added this comment to the previous thread, but copy/pasting here: >> >> I was thinking a bit more about trust between realms and I think that >> should be limited to authentication only. An admin with certain roles >> in one realm shouldn't necessarily have the same roles in another >> realm. So I think we need either a user that can exist in multiple >> realms or utilize identity brokering to get "linked" users. I'm >> worried if we allow roles from one realm to give admin permissions in >> another it will be hard to get a full picture of who has access to the >> realm. It may also give unintentional permissions. Also, if we >> introduce admins that can only manage a "group" of users or roles that >> specify what roles an admin can grant that would require users in the >> specific realm to manage. > > Again to use the Keystone comparison-other. > > A Domain in OpenStack is the top level entity for ownership. Under > domains in *identity* you have \users and groups. Under domains in > "resource" you have projects. I think projects most map to Realms in > Keycloak. > > > A user is a resource to be managed by a domain. The fact that a > specific domain owns the user does not give the user any role assignment > in that domain; it is just ownership of the record. > > All role assignments are on the "resource" side of Keystone. A user > gets a role assignment on a project or a domain. > > > Just about everything in Keystone has both a name and an id. For the > majority, these the IDs are UUIDs. An assignement is then a tuple: > > > actor_id, target_id, role_id. > > Actor is either user or group. > Target is either project or domain. > Role is enforced by name, but assigned by ID. > > I've been calling this "Scoped RBAC" to contrast it with NIST, where > role assignments are not scoped to some namespace. > > > The same would work for Keycloak: a Role is always assigned on a Realm, > never just a global role assignment. > > What becomes important, then, is that the application, or whatever is > requesting the set of roels for a user, get the right set for the > scope. When I log in to Wordpress for Marketing I get a different set > of roles listed from when I log in to Wordpress for Engineering. > > > Now, I feel like Domains are bad extension, that we should have just > made projects hierarchical. Are Realms hierarchical in Keycloak? > > The realm in Keycloak is the top-level construct. Realms are completely isolated from one another. Realms contain users, roles, groups and applications/clients. Each realm can have a theme that describes the css templates/screens, etc. for login, account management, even the admin console. Each realm decides on its flows for authentication, registration, credential reset, etc. For the realm you can state how the user logs in, username? password? otp? terms and conditions? This is the login flow. So, all that stuff makes up a realm. Each realm has a set of admin roles which are really different permissions for managing the roles (view users, edit users, edit clients, etc..). We also currently have the concept of a master realm. Admins in the master realm can manage other realms configured on the server. Because we never created the separate concept of a namespace for roles, clients were used to hack in the concept of a namespace for admin roles. So the master realm has all these "clients" that are really nothing more than role namespaces Right now, Keycloak does not have the concept of permissions and resources. It is up to each individual client/application what permissions a particular role has. The original idea was that each application has their own set of roles that have their own meaning in that context. An "admin" in one app may mean something totally different than "admin" in another. So, what we hoped to get to is that in JBoss somebody would click on a button to secure an existing WAR via Keycloak, enter in some admin credential, and the role metdata in the WAR would automatically be uploaded to keycloak, registered and the appropriate config would be saved at the JBoss side. Admins would then assign application roles as appropriate to each user or group. With pedro's permission stuff the idea is to be able to define a permission model for resources, where resource could be anything: a url, a machine, etc. But right now Keycloak just manages users, groups, and roles and role mappings for each of those things. Hope that makes sense. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From erik.mulder at docdatapayments.com Tue Dec 8 04:17:16 2015 From: erik.mulder at docdatapayments.com (Erik Mulder) Date: Tue, 8 Dec 2015 10:17:16 +0100 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> Message-ID: <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> Pedro's change (see below) is kindof what I was looking for, but for my case and for general flexibility I think it's good to also have a more basic point to hook into the REST API's. I implemented and tested my own suggestion of having an SPI to be able to add a REST resource at the root level. Combined with the (coming) ability to freely extend the JPA entities and DB schema, I think this creates a really powerful extensibility to Keycloak. When we finish these changes, I can write a blog post about what we did, why and how as a showcase for custom extensions to Keycloak. So are the Keycloak dev's open to a PR with a new SPI that enables you to add custom REST paths? For example, you could create something like: http://localhost:8080/auth/myPath/myResource -----Oorspronkelijk bericht----- Van: Pedro Igor Silva [mailto:psilva at redhat.com] Verzonden: maandag 7 december 2015 22:18 Aan: Erik Mulder Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? It is part of a working in progress around fine-grained authorization [1]. The new SPI changes [2] specific to Keycloak are located in a specific branch [3] in my Keycloak fork. I need to discuss these changes with Bill and see what he thinks about it. Depending on his feedback, I can prepare a PR and send these changes to upstream. [1] https://github.com/pedroigor/keycloak-authz [2] https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 [3] https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified Regards. ----- Original Message ----- From: "Erik Mulder" To: "Pedro Igor Silva" Sent: Monday, December 7, 2015 5:51:26 PM Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? Great, that's probably all we need! I'd like to try it out, but I cannot find any reference to what you mention on Github. Is it (going to be) a pull request? Is it going to be part of a future release? Can you point me to / provide me with these changes so I can give it a spin? Thanks! ________________________________________ Van: Pedro Igor Silva [psilva at redhat.com] Verzonden: maandag 7 december 2015 16:03 Aan: Erik Mulder CC: keycloak-dev at lists.jboss.org Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? I've done something at this regard, where you can use a SPI in order to plug additional APIs for: * Realm Admin RESTFul API (eg.: used by admin console) * Realm RESFTFul API (eg.: to plug additional endpoints for realms) The two Provider interfaces are very simple and just provide a single method: Object getResource(String pathName); Where pathName is the path that must be resolved to your custom JAX-RS resource. The factories are also very simple and allows you to build those resources for the current Realm and KeycloakSession. Eg.: RealmResourceProvider create(RealmModel realm, KeycloakSession keycloakSession); Do you need something other than that ? Regards. Pedro Igor ----- Original Message ----- From: "Erik Mulder" To: keycloak-dev at lists.jboss.org Sent: Monday, December 7, 2015 12:46:39 PM Subject: [keycloak-dev] Add custom REST paths? New SPI? As some of you might know, our team is busy adding data to the keycloak system to incorporate some custom authorization information in the access token. So far we've successfully extended the JPA entities, Liquibase table definitions and added a custom mapper to put that data in the access token. All of this without custom modifications to the original keycloak sources. This is working great, thanks for the support so far! I know I've promised some PR's for this and they will come, but first we'd like to get everything fully working, so we know it's a well functioning whole. The last piece of the puzzle is extending the REST services to include CRUD actions for our custom resources. I've been looking into the way RESTEasy/JAX-RS works and it seems to me that in the current implementation there is no way to add extra paths. As I see it now, the KeycloakApplication class will register some singletons in it's constructor and that's that. No way to extend or to 'interfere' there. So my question is: is there any 'official' way to add extra REST paths to Keycloak? If not, is it an idea to add this as a new SPI? The current code for adding root paths in the KeycloakApplication constructor lists: singletons.add(new ServerVersionResource()); singletons.add(new RealmsResource()); singletons.add(new AdminRoot()); So just plain contructor calls. That seems like an easy target for 'SPI-ing' :-). Or just leave the current ones 'hardcoded' and add an SPI for custom extensions. Your thoughts on this please. As before, I'm happy to implement this myself, but I'd like to discuss it first, so a future PR will be honored. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From gregj at thesoftwarecottage.com.au Tue Dec 8 04:22:21 2015 From: gregj at thesoftwarecottage.com.au (Greg Jones) Date: Tue, 8 Dec 2015 20:22:21 +1100 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> Message-ID: <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> +1 for these changes. We have been looking at a way to add custom REST endpoints and would be happy to use this approach. Regards Greg Jones > On 8 Dec 2015, at 8:17 PM, Erik Mulder wrote: > > Pedro's change (see below) is kindof what I was looking for, but for my case and for general flexibility I think it's good to also have a more basic point to hook into the REST API's. > I implemented and tested my own suggestion of having an SPI to be able to add a REST resource at the root level. Combined with the (coming) ability to freely extend the JPA entities and DB schema, I think this creates a really powerful extensibility to Keycloak. When we finish these changes, I can write a blog post about what we did, why and how as a showcase for custom extensions to Keycloak. > > So are the Keycloak dev's open to a PR with a new SPI that enables you to add custom REST paths? > For example, you could create something like: > http://localhost:8080/auth/myPath/myResource > > > -----Oorspronkelijk bericht----- > Van: Pedro Igor Silva [mailto:psilva at redhat.com] > Verzonden: maandag 7 december 2015 22:18 > Aan: Erik Mulder > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > It is part of a working in progress around fine-grained authorization [1]. > > The new SPI changes [2] specific to Keycloak are located in a specific branch [3] in my Keycloak fork. > > I need to discuss these changes with Bill and see what he thinks about it. Depending on his feedback, I can prepare a PR and send these changes to upstream. > > [1] https://github.com/pedroigor/keycloak-authz > [2] https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 > [3] https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified > > Regards. > > ----- Original Message ----- > From: "Erik Mulder" > To: "Pedro Igor Silva" > Sent: Monday, December 7, 2015 5:51:26 PM > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? > > Great, that's probably all we need! > I'd like to try it out, but I cannot find any reference to what you mention on Github. Is it (going to be) a pull request? Is it going to be part of a future release? > Can you point me to / provide me with these changes so I can give it a spin? Thanks! > > ________________________________________ > Van: Pedro Igor Silva [psilva at redhat.com] > Verzonden: maandag 7 december 2015 16:03 > Aan: Erik Mulder > CC: keycloak-dev at lists.jboss.org > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > I've done something at this regard, where you can use a SPI in order to plug additional APIs for: > > * Realm Admin RESTFul API (eg.: used by admin console) > * Realm RESFTFul API (eg.: to plug additional endpoints for realms) > > The two Provider interfaces are very simple and just provide a single method: > > Object getResource(String pathName); > > Where pathName is the path that must be resolved to your custom JAX-RS resource. > > The factories are also very simple and allows you to build those resources for the current Realm and KeycloakSession. Eg.: > > RealmResourceProvider create(RealmModel realm, KeycloakSession keycloakSession); > > Do you need something other than that ? > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Erik Mulder" > To: keycloak-dev at lists.jboss.org > Sent: Monday, December 7, 2015 12:46:39 PM > Subject: [keycloak-dev] Add custom REST paths? New SPI? > > As some of you might know, our team is busy adding data to the keycloak system to incorporate some custom authorization information in the access token. > So far we've successfully extended the JPA entities, Liquibase table definitions and added a custom mapper to put that data in the access token. All of this without custom modifications to the original keycloak sources. This is working great, thanks for the support so far! > I know I've promised some PR's for this and they will come, but first we'd like to get everything fully working, so we know it's a well functioning whole. > > The last piece of the puzzle is extending the REST services to include CRUD actions for our custom resources. I've been looking into the way RESTEasy/JAX-RS works and it seems to me that in the current implementation there is no way to add extra paths. As I see it now, the KeycloakApplication class will register some singletons in it's constructor and that's that. No way to extend or to 'interfere' there. > > So my question is: is there any 'official' way to add extra REST paths to Keycloak? > > If not, is it an idea to add this as a new SPI? The current code for adding root paths in the KeycloakApplication constructor lists: > > singletons.add(new ServerVersionResource()); > singletons.add(new RealmsResource()); > singletons.add(new AdminRoot()); > > So just plain contructor calls. That seems like an easy target for 'SPI-ing' :-). > Or just leave the current ones 'hardcoded' and add an SPI for custom extensions. > Your thoughts on this please. > > As before, I'm happy to implement this myself, but I'd like to discuss it first, so a future PR will be honored. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Tue Dec 8 04:32:02 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 8 Dec 2015 10:32:02 +0100 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> Message-ID: -1 To adding rest endpoints to the root level. I'd like to get rid of 'realms' part as some point and have all rest endpoints sit underneath a realm. This makes sure the KeycloakSession always knows what realm is being handled, so we don't need to pass the realm around as it can be retrived from the KeycloakContext. It also means that the url can be shortened as we can drop the 'realms' part. On 8 December 2015 at 10:22, Greg Jones wrote: > +1 for these changes. We have been looking at a way to add custom REST > endpoints and would be happy to use this approach. > > Regards > Greg Jones > > > > On 8 Dec 2015, at 8:17 PM, Erik Mulder > wrote: > > > > Pedro's change (see below) is kindof what I was looking for, but for my > case and for general flexibility I think it's good to also have a more > basic point to hook into the REST API's. > > I implemented and tested my own suggestion of having an SPI to be able > to add a REST resource at the root level. Combined with the (coming) > ability to freely extend the JPA entities and DB schema, I think this > creates a really powerful extensibility to Keycloak. When we finish these > changes, I can write a blog post about what we did, why and how as a > showcase for custom extensions to Keycloak. > > > > So are the Keycloak dev's open to a PR with a new SPI that enables you > to add custom REST paths? > > For example, you could create something like: > > http://localhost:8080/auth/myPath/myResource > > > > > > -----Oorspronkelijk bericht----- > > Van: Pedro Igor Silva [mailto:psilva at redhat.com] > > Verzonden: maandag 7 december 2015 22:18 > > Aan: Erik Mulder > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > It is part of a working in progress around fine-grained authorization > [1]. > > > > The new SPI changes [2] specific to Keycloak are located in a specific > branch [3] in my Keycloak fork. > > > > I need to discuss these changes with Bill and see what he thinks about > it. Depending on his feedback, I can prepare a PR and send these changes to > upstream. > > > > [1] https://github.com/pedroigor/keycloak-authz > > [2] > https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 > > [3] https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified > > > > Regards. > > > > ----- Original Message ----- > > From: "Erik Mulder" > > To: "Pedro Igor Silva" > > Sent: Monday, December 7, 2015 5:51:26 PM > > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? > > > > Great, that's probably all we need! > > I'd like to try it out, but I cannot find any reference to what you > mention on Github. Is it (going to be) a pull request? Is it going to be > part of a future release? > > Can you point me to / provide me with these changes so I can give it a > spin? Thanks! > > > > ________________________________________ > > Van: Pedro Igor Silva [psilva at redhat.com] > > Verzonden: maandag 7 december 2015 16:03 > > Aan: Erik Mulder > > CC: keycloak-dev at lists.jboss.org > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > I've done something at this regard, where you can use a SPI in order to > plug additional APIs for: > > > > * Realm Admin RESTFul API (eg.: used by admin console) > > * Realm RESFTFul API (eg.: to plug additional endpoints for realms) > > > > The two Provider interfaces are very simple and just provide a single > method: > > > > Object getResource(String pathName); > > > > Where pathName is the path that must be resolved to your custom JAX-RS > resource. > > > > The factories are also very simple and allows you to build those > resources for the current Realm and KeycloakSession. Eg.: > > > > RealmResourceProvider create(RealmModel realm, KeycloakSession > keycloakSession); > > > > Do you need something other than that ? > > > > Regards. > > Pedro Igor > > > > ----- Original Message ----- > > From: "Erik Mulder" > > To: keycloak-dev at lists.jboss.org > > Sent: Monday, December 7, 2015 12:46:39 PM > > Subject: [keycloak-dev] Add custom REST paths? New SPI? > > > > As some of you might know, our team is busy adding data to the keycloak > system to incorporate some custom authorization information in the access > token. > > So far we've successfully extended the JPA entities, Liquibase table > definitions and added a custom mapper to put that data in the access token. > All of this without custom modifications to the original keycloak sources. > This is working great, thanks for the support so far! > > I know I've promised some PR's for this and they will come, but first > we'd like to get everything fully working, so we know it's a well > functioning whole. > > > > The last piece of the puzzle is extending the REST services to include > CRUD actions for our custom resources. I've been looking into the way > RESTEasy/JAX-RS works and it seems to me that in the current implementation > there is no way to add extra paths. As I see it now, the > KeycloakApplication class will register some singletons in it's constructor > and that's that. No way to extend or to 'interfere' there. > > > > So my question is: is there any 'official' way to add extra REST paths > to Keycloak? > > > > If not, is it an idea to add this as a new SPI? The current code for > adding root paths in the KeycloakApplication constructor lists: > > > > singletons.add(new ServerVersionResource()); > > singletons.add(new RealmsResource()); > > singletons.add(new AdminRoot()); > > > > So just plain contructor calls. That seems like an easy target for > 'SPI-ing' :-). > > Or just leave the current ones 'hardcoded' and add an SPI for custom > extensions. > > Your thoughts on this please. > > > > As before, I'm happy to implement this myself, but I'd like to discuss > it first, so a future PR will be honored. > > > > > > _______________________________________________ > > 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/20151208/ce7aac0f/attachment-0001.html From erik.mulder at docdatapayments.com Tue Dec 8 05:18:13 2015 From: erik.mulder at docdatapayments.com (Erik Mulder) Date: Tue, 8 Dec 2015 11:18:13 +0100 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> Message-ID: <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> Stian, I can see your point. Using the realm name as the root level certainly has advantages. It also really fixes everything to a realm, but I guess that is what you want. So how about the current ?/admin? url, how does that fit in the new picture? Because that would be my next best target to hook into. Furthermore, there?s currently a ?/version? root path that should end up somewhere else. Personally, I think it?s not so bad to have a descriptive root level like ?realms?, which leaves open the possibility to add extra root level paths, like meta data (version) or special contexts (admin, customPath). Van: Stian Thorgersen [mailto:sthorger at redhat.com] Verzonden: dinsdag 8 december 2015 10:32 Aan: Greg Jones CC: Erik Mulder ; keycloak-dev at lists.jboss.org Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? -1 To adding rest endpoints to the root level. I'd like to get rid of 'realms' part as some point and have all rest endpoints sit underneath a realm. This makes sure the KeycloakSession always knows what realm is being handled, so we don't need to pass the realm around as it can be retrived from the KeycloakContext. It also means that the url can be shortened as we can drop the 'realms' part. On 8 December 2015 at 10:22, Greg Jones > wrote: +1 for these changes. We have been looking at a way to add custom REST endpoints and would be happy to use this approach. Regards Greg Jones > On 8 Dec 2015, at 8:17 PM, Erik Mulder > wrote: > > Pedro's change (see below) is kindof what I was looking for, but for my case and for general flexibility I think it's good to also have a more basic point to hook into the REST API's. > I implemented and tested my own suggestion of having an SPI to be able to add a REST resource at the root level. Combined with the (coming) ability to freely extend the JPA entities and DB schema, I think this creates a really powerful extensibility to Keycloak. When we finish these changes, I can write a blog post about what we did, why and how as a showcase for custom extensions to Keycloak. > > So are the Keycloak dev's open to a PR with a new SPI that enables you to add custom REST paths? > For example, you could create something like: > http://localhost:8080/auth/myPath/myResource > > > -----Oorspronkelijk bericht----- > Van: Pedro Igor Silva [mailto:psilva at redhat.com] > Verzonden: maandag 7 december 2015 22:18 > Aan: Erik Mulder > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > It is part of a working in progress around fine-grained authorization [1]. > > The new SPI changes [2] specific to Keycloak are located in a specific branch [3] in my Keycloak fork. > > I need to discuss these changes with Bill and see what he thinks about it. Depending on his feedback, I can prepare a PR and send these changes to upstream. > > [1] https://github.com/pedroigor/keycloak-authz > [2] https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 > [3] https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified > > Regards. > > ----- Original Message ----- > From: "Erik Mulder" > > To: "Pedro Igor Silva" > > Sent: Monday, December 7, 2015 5:51:26 PM > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? > > Great, that's probably all we need! > I'd like to try it out, but I cannot find any reference to what you mention on Github. Is it (going to be) a pull request? Is it going to be part of a future release? > Can you point me to / provide me with these changes so I can give it a spin? Thanks! > > ________________________________________ > Van: Pedro Igor Silva [psilva at redhat.com] > Verzonden: maandag 7 december 2015 16:03 > Aan: Erik Mulder > CC: keycloak-dev at lists.jboss.org > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > I've done something at this regard, where you can use a SPI in order to plug additional APIs for: > > * Realm Admin RESTFul API (eg.: used by admin console) > * Realm RESFTFul API (eg.: to plug additional endpoints for realms) > > The two Provider interfaces are very simple and just provide a single method: > > Object getResource(String pathName); > > Where pathName is the path that must be resolved to your custom JAX-RS resource. > > The factories are also very simple and allows you to build those resources for the current Realm and KeycloakSession. Eg.: > > RealmResourceProvider create(RealmModel realm, KeycloakSession keycloakSession); > > Do you need something other than that ? > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Erik Mulder" > > To: keycloak-dev at lists.jboss.org > Sent: Monday, December 7, 2015 12:46:39 PM > Subject: [keycloak-dev] Add custom REST paths? New SPI? > > As some of you might know, our team is busy adding data to the keycloak system to incorporate some custom authorization information in the access token. > So far we've successfully extended the JPA entities, Liquibase table definitions and added a custom mapper to put that data in the access token. All of this without custom modifications to the original keycloak sources. This is working great, thanks for the support so far! > I know I've promised some PR's for this and they will come, but first we'd like to get everything fully working, so we know it's a well functioning whole. > > The last piece of the puzzle is extending the REST services to include CRUD actions for our custom resources. I've been looking into the way RESTEasy/JAX-RS works and it seems to me that in the current implementation there is no way to add extra paths. As I see it now, the KeycloakApplication class will register some singletons in it's constructor and that's that. No way to extend or to 'interfere' there. > > So my question is: is there any 'official' way to add extra REST paths to Keycloak? > > If not, is it an idea to add this as a new SPI? The current code for adding root paths in the KeycloakApplication constructor lists: > > singletons.add(new ServerVersionResource()); > singletons.add(new RealmsResource()); > singletons.add(new AdminRoot()); > > So just plain contructor calls. That seems like an easy target for 'SPI-ing' :-). > Or just leave the current ones 'hardcoded' and add an SPI for custom extensions. > Your thoughts on this please. > > As before, I'm happy to implement this myself, but I'd like to discuss it first, so a future PR will be honored. > > > _______________________________________________ > 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/20151208/fbcbe313/attachment-0001.html From gregj at thesoftwarecottage.com.au Tue Dec 8 05:32:51 2015 From: gregj at thesoftwarecottage.com.au (Greg Jones) Date: Tue, 8 Dec 2015 21:32:51 +1100 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> Message-ID: Hi Erik and Stian, Just clearing up our usage. We have added custom endpoints at /auth/realms/{realm}/xxxx to perform the functions we need. This allows us to create a register endpoint that we can call from a mobile app to register a new user, without the need to go through a web view. We are also working on a direct call for reset password, using this mechanism. This path operates on the realm specified. Regards Greg J. > On 8 Dec 2015, at 9:18 PM, Erik Mulder wrote: > > Stian, I can see your point. Using the realm name as the root level certainly has advantages. It also really fixes everything to a realm, but I guess that is what you want. So how about the current ?/admin? url, how does that fit in the new picture? Because that would be my next best target to hook into. Furthermore, there?s currently a ?/version? root path that should end up somewhere else. Personally, I think it?s not so bad to have a descriptive root level like ?realms?, which leaves open the possibility to add extra root level paths, like meta data (version) or special contexts (admin, customPath). > > > Van: Stian Thorgersen [mailto:sthorger at redhat.com ] > Verzonden: dinsdag 8 december 2015 10:32 > Aan: Greg Jones > > CC: Erik Mulder >; keycloak-dev at lists.jboss.org > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > -1 To adding rest endpoints to the root level. I'd like to get rid of 'realms' part as some point and have all rest endpoints sit underneath a realm. This makes sure the KeycloakSession always knows what realm is being handled, so we don't need to pass the realm around as it can be retrived from the KeycloakContext. It also means that the url can be shortened as we can drop the 'realms' part. > > On 8 December 2015 at 10:22, Greg Jones > wrote: > +1 for these changes. We have been looking at a way to add custom REST endpoints and would be happy to use this approach. > > Regards > Greg Jones > > > > On 8 Dec 2015, at 8:17 PM, Erik Mulder > wrote: > > > > Pedro's change (see below) is kindof what I was looking for, but for my case and for general flexibility I think it's good to also have a more basic point to hook into the REST API's. > > I implemented and tested my own suggestion of having an SPI to be able to add a REST resource at the root level. Combined with the (coming) ability to freely extend the JPA entities and DB schema, I think this creates a really powerful extensibility to Keycloak. When we finish these changes, I can write a blog post about what we did, why and how as a showcase for custom extensions to Keycloak. > > > > So are the Keycloak dev's open to a PR with a new SPI that enables you to add custom REST paths? > > For example, you could create something like: > > http://localhost:8080/auth/myPath/myResource > > > > > > -----Oorspronkelijk bericht----- > > Van: Pedro Igor Silva [mailto:psilva at redhat.com ] > > Verzonden: maandag 7 december 2015 22:18 > > Aan: Erik Mulder > > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > It is part of a working in progress around fine-grained authorization [1]. > > > > The new SPI changes [2] specific to Keycloak are located in a specific branch [3] in my Keycloak fork. > > > > I need to discuss these changes with Bill and see what he thinks about it. Depending on his feedback, I can prepare a PR and send these changes to upstream. > > > > [1] https://github.com/pedroigor/keycloak-authz > > [2] https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 > > [3] https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified > > > > Regards. > > > > ----- Original Message ----- > > From: "Erik Mulder" > > > To: "Pedro Igor Silva" > > > Sent: Monday, December 7, 2015 5:51:26 PM > > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? > > > > Great, that's probably all we need! > > I'd like to try it out, but I cannot find any reference to what you mention on Github. Is it (going to be) a pull request? Is it going to be part of a future release? > > Can you point me to / provide me with these changes so I can give it a spin? Thanks! > > > > ________________________________________ > > Van: Pedro Igor Silva [psilva at redhat.com ] > > Verzonden: maandag 7 december 2015 16:03 > > Aan: Erik Mulder > > CC: keycloak-dev at lists.jboss.org > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > I've done something at this regard, where you can use a SPI in order to plug additional APIs for: > > > > * Realm Admin RESTFul API (eg.: used by admin console) > > * Realm RESFTFul API (eg.: to plug additional endpoints for realms) > > > > The two Provider interfaces are very simple and just provide a single method: > > > > Object getResource(String pathName); > > > > Where pathName is the path that must be resolved to your custom JAX-RS resource. > > > > The factories are also very simple and allows you to build those resources for the current Realm and KeycloakSession. Eg.: > > > > RealmResourceProvider create(RealmModel realm, KeycloakSession keycloakSession); > > > > Do you need something other than that ? > > > > Regards. > > Pedro Igor > > > > ----- Original Message ----- > > From: "Erik Mulder" > > > To: keycloak-dev at lists.jboss.org > > Sent: Monday, December 7, 2015 12:46:39 PM > > Subject: [keycloak-dev] Add custom REST paths? New SPI? > > > > As some of you might know, our team is busy adding data to the keycloak system to incorporate some custom authorization information in the access token. > > So far we've successfully extended the JPA entities, Liquibase table definitions and added a custom mapper to put that data in the access token. All of this without custom modifications to the original keycloak sources. This is working great, thanks for the support so far! > > I know I've promised some PR's for this and they will come, but first we'd like to get everything fully working, so we know it's a well functioning whole. > > > > The last piece of the puzzle is extending the REST services to include CRUD actions for our custom resources. I've been looking into the way RESTEasy/JAX-RS works and it seems to me that in the current implementation there is no way to add extra paths. As I see it now, the KeycloakApplication class will register some singletons in it's constructor and that's that. No way to extend or to 'interfere' there. > > > > So my question is: is there any 'official' way to add extra REST paths to Keycloak? > > > > If not, is it an idea to add this as a new SPI? The current code for adding root paths in the KeycloakApplication constructor lists: > > > > singletons.add(new ServerVersionResource()); > > singletons.add(new RealmsResource()); > > singletons.add(new AdminRoot()); > > > > So just plain contructor calls. That seems like an easy target for 'SPI-ing' :-). > > Or just leave the current ones 'hardcoded' and add an SPI for custom extensions. > > Your thoughts on this please. > > > > As before, I'm happy to implement this myself, but I'd like to discuss it first, so a future PR will be honored. > > > > > > _______________________________________________ > > 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/20151208/bdec6ce1/attachment-0001.html From sthorger at redhat.com Tue Dec 8 05:34:29 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 8 Dec 2015 11:34:29 +0100 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> Message-ID: 'admin' will probably move at some point to be under the realm. 'version' would move as well. Although this one should probably be removed altogether. KeycloakSession and SPIs needs to be tied to a specific realm. This makes everything cleaner. Besides it just doesn't make any sense to add arbitrary rest endpoints to Keycloak. A rest endpoint should be tied to a realm, otherwise it just doesn't make sense to host it on the Keycloak server. On 8 December 2015 at 11:18, Erik Mulder wrote: > Stian, I can see your point. Using the realm name as the root level > certainly has advantages. It also really fixes everything to a realm, but I > guess that is what you want. So how about the current ?/admin? url, how > does that fit in the new picture? Because that would be my next best target > to hook into. Furthermore, there?s currently a ?/version? root path that > should end up somewhere else. Personally, I think it?s not so bad to have a > descriptive root level like ?realms?, which leaves open the possibility to > add extra root level paths, like meta data (version) or special contexts > (admin, customPath). > > > > > > *Van:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Verzonden:* dinsdag 8 december 2015 10:32 > *Aan:* Greg Jones > *CC:* Erik Mulder ; > keycloak-dev at lists.jboss.org > > *Onderwerp:* Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > -1 To adding rest endpoints to the root level. I'd like to get rid of > 'realms' part as some point and have all rest endpoints sit underneath a > realm. This makes sure the KeycloakSession always knows what realm is being > handled, so we don't need to pass the realm around as it can be retrived > from the KeycloakContext. It also means that the url can be shortened as we > can drop the 'realms' part. > > > > On 8 December 2015 at 10:22, Greg Jones > wrote: > > +1 for these changes. We have been looking at a way to add custom REST > endpoints and would be happy to use this approach. > > Regards > Greg Jones > > > > > On 8 Dec 2015, at 8:17 PM, Erik Mulder > wrote: > > > > Pedro's change (see below) is kindof what I was looking for, but for my > case and for general flexibility I think it's good to also have a more > basic point to hook into the REST API's. > > I implemented and tested my own suggestion of having an SPI to be able > to add a REST resource at the root level. Combined with the (coming) > ability to freely extend the JPA entities and DB schema, I think this > creates a really powerful extensibility to Keycloak. When we finish these > changes, I can write a blog post about what we did, why and how as a > showcase for custom extensions to Keycloak. > > > > So are the Keycloak dev's open to a PR with a new SPI that enables you > to add custom REST paths? > > For example, you could create something like: > > http://localhost:8080/auth/myPath/myResource > > > > > > -----Oorspronkelijk bericht----- > > Van: Pedro Igor Silva [mailto:psilva at redhat.com] > > Verzonden: maandag 7 december 2015 22:18 > > Aan: Erik Mulder > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > It is part of a working in progress around fine-grained authorization > [1]. > > > > The new SPI changes [2] specific to Keycloak are located in a specific > branch [3] in my Keycloak fork. > > > > I need to discuss these changes with Bill and see what he thinks about > it. Depending on his feedback, I can prepare a PR and send these changes to > upstream. > > > > [1] https://github.com/pedroigor/keycloak-authz > > [2] > https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 > > [3] https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified > > > > Regards. > > > > ----- Original Message ----- > > From: "Erik Mulder" > > To: "Pedro Igor Silva" > > Sent: Monday, December 7, 2015 5:51:26 PM > > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? > > > > Great, that's probably all we need! > > I'd like to try it out, but I cannot find any reference to what you > mention on Github. Is it (going to be) a pull request? Is it going to be > part of a future release? > > Can you point me to / provide me with these changes so I can give it a > spin? Thanks! > > > > ________________________________________ > > Van: Pedro Igor Silva [psilva at redhat.com] > > Verzonden: maandag 7 december 2015 16:03 > > Aan: Erik Mulder > > CC: keycloak-dev at lists.jboss.org > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > I've done something at this regard, where you can use a SPI in order to > plug additional APIs for: > > > > * Realm Admin RESTFul API (eg.: used by admin console) > > * Realm RESFTFul API (eg.: to plug additional endpoints for realms) > > > > The two Provider interfaces are very simple and just provide a single > method: > > > > Object getResource(String pathName); > > > > Where pathName is the path that must be resolved to your custom JAX-RS > resource. > > > > The factories are also very simple and allows you to build those > resources for the current Realm and KeycloakSession. Eg.: > > > > RealmResourceProvider create(RealmModel realm, KeycloakSession > keycloakSession); > > > > Do you need something other than that ? > > > > Regards. > > Pedro Igor > > > > ----- Original Message ----- > > From: "Erik Mulder" > > To: keycloak-dev at lists.jboss.org > > Sent: Monday, December 7, 2015 12:46:39 PM > > Subject: [keycloak-dev] Add custom REST paths? New SPI? > > > > As some of you might know, our team is busy adding data to the keycloak > system to incorporate some custom authorization information in the access > token. > > So far we've successfully extended the JPA entities, Liquibase table > definitions and added a custom mapper to put that data in the access token. > All of this without custom modifications to the original keycloak sources. > This is working great, thanks for the support so far! > > I know I've promised some PR's for this and they will come, but first > we'd like to get everything fully working, so we know it's a well > functioning whole. > > > > The last piece of the puzzle is extending the REST services to include > CRUD actions for our custom resources. I've been looking into the way > RESTEasy/JAX-RS works and it seems to me that in the current implementation > there is no way to add extra paths. As I see it now, the > KeycloakApplication class will register some singletons in it's constructor > and that's that. No way to extend or to 'interfere' there. > > > > So my question is: is there any 'official' way to add extra REST paths > to Keycloak? > > > > If not, is it an idea to add this as a new SPI? The current code for > adding root paths in the KeycloakApplication constructor lists: > > > > singletons.add(new ServerVersionResource()); > > singletons.add(new RealmsResource()); > > singletons.add(new AdminRoot()); > > > > So just plain contructor calls. That seems like an easy target for > 'SPI-ing' :-). > > Or just leave the current ones 'hardcoded' and add an SPI for custom > extensions. > > Your thoughts on this please. > > > > As before, I'm happy to implement this myself, but I'd like to discuss > it first, so a future PR will be honored. > > > > > > _______________________________________________ > > 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/20151208/aa754872/attachment.html From lkrzyzan at redhat.com Tue Dec 8 06:49:08 2015 From: lkrzyzan at redhat.com (Libor Krzyzanek) Date: Tue, 8 Dec 2015 12:49:08 +0100 Subject: [keycloak-dev] [keycloak-user] Keycloak 1.7.0.CR1 Released In-Reply-To: References: Message-ID: <2594C622-1B8D-4B44-84EF-93E4DAB886E1@redhat.com> Hi, thank you very much for CR release. we tried upgrade from 1.6 on EAP 6.4 + Postgres and everything seems to be working so far. Thanks, Libor Krzy?anek jboss.org Development Team > On Dec 3, 2015, at 4:56 PM, Stian Thorgersen wrote: > > I'm pleased to announce the release of Keycloak 1.7.0.CR1. Recently we've gone straight to Final, but we'd like to give everyone a chance to try a release out first. Unless there are major issues reported we will release Final next week. > > As usual we've been far from idle and have a number of highlights in this release, including: > > Groups - users can belong to one or more groups and inherit role mappings and attributes from the group. > First Broker Login Flow - we've introduced a number of improvements to first login with identity brokers as well as the ability to customize the flow used. > Client Registration - clients can now dynamically register themselves with a Keycloak server. This supports Keycloak client representations, OpenID Connect Dynamic Client Registration and SAML Entity Descriptors. Client registration are simple REST endpoints, there's also a Java library and a CLI is coming soon. > OpenID Connect Implicit and Hybrid flows - we've added support for the Implicit and Hybrid flows. It's also possible to select what flows are available for a specific client. > Add User script - as a first step to not having a default admin user we've added a script that allows creating an initial admin account. > Cache fixes - there's a number of fixes related to caching, which should improve performance especially in clusters. > Email Sender SPI - previously we had one SPI that created email content from FreeMarker and also sent emails. We've now split this into two separate SPIs. > SAML SP WildFly subsystem - there's now a WildFly subsystem for the SAML SP adapter, which makes it easier to use the SAML SP adapter on WildFly. > WildFly 10 adapter support - the WildFly adapter, including adapter subsystem, now supports WildFly 10. > > 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/20151208/91cf4234/attachment-0001.html From bburke at redhat.com Tue Dec 8 07:50:48 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 8 Dec 2015 07:50:48 -0500 Subject: [keycloak-dev] cross-realm administration Message-ID: <5666D228.6080402@redhat.com> Continuing our hangout from yesterday... The primary goal, IMO is to 1) clean up the master realm realm clients 2) remove the master realm requirement for cross-realm impersonation 3) give possibility to remove the master realm Right now non-master realms trust admins in the master realm. These "child" realms allow the master realm to decide which users in the master realm are allowed to access it. I'll call this "cross-realm administration". We could continue this model, but without role namespaces you'd have to create realm-clients in each trusted realm. Another idea is to do something really simple. Realm A decides to trust Realm B and they "share" admin roles. If user in Realm B has "view-user" permission, then he also has "view-user" permission. The UI is simple and there's no need for Realm A and B to know anything else about each other. This is a simpler version of "cross-realm administration" which doesn't give you any fine grain per-realm control. This requires very little UI work which is the big blocker for me. Building on that idea, which is what I started to implement, is that Realm A "shares" admin roles still, but only allows certain permissions for Realm B. Realm A grants admins in Realm B "view user and create client" If you want to go further with the ability to grant a specific user or group in another realm admin privileges then it becomes more complicated. You have a chicken and egg problem first as you'd need a way to view users and groups in another realm so you can grant permission to them. I guess it could be you 1. Granting trust ot a realm allows that realm to view your users and groups. Well, at least query for username/email/attributes 2. UI screens would have to be created specific for managing users/groups in another realm as you would want to filter what information gets displayed -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Tue Dec 8 08:40:51 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 8 Dec 2015 14:40:51 +0100 Subject: [keycloak-dev] Keycloak 1.7.0.Final Released Message-ID: This release contains no changes since 1.7.0.CR1 as there where no major bugs reported. Thanks to everyone that did give CR1 a try and provided feedback. For new features in this release check out the blog post about Keycloak 1.7.0.CR1 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/20151208/fc19bf6a/attachment.html From sthorger at redhat.com Tue Dec 8 10:07:16 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 8 Dec 2015 16:07:16 +0100 Subject: [keycloak-dev] [keycloak-user] Keycloak 1.7.0.Final Released In-Reply-To: References: Message-ID: add-user.sh now adds users for Keycloak. If you need to add users to WildFly console you should run "add-user.sh --container [OPTIONS]" On 8 December 2015 at 14:55, Pavel Maslov wrote: > Hi Stian, > > > Where has the --silent parameter in the add-user.sh file gone? > > -s, --silent Activate the silent mode (no output to > the console) > > Thanks. > > Regards, > Pavel Maslov, MS > > On Tue, Dec 8, 2015 at 2:40 PM, Stian Thorgersen > wrote: > >> This release contains no changes since 1.7.0.CR1 as there where no major >> bugs reported. Thanks to everyone that did give CR1 a try and provided >> feedback. >> >> For new features in this release check out the blog post about Keycloak >> 1.7.0.CR1 release >> >> >> 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/20151208/a629fbb0/attachment.html From erik.mulder at docdatapayments.com Tue Dec 8 11:00:58 2015 From: erik.mulder at docdatapayments.com (Erik Mulder) Date: Tue, 8 Dec 2015 17:00:58 +0100 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> Message-ID: <9A5619B792BBA041AE094585791BB71C0137B668B0CD@DDPEX01.DDP.dcloud.local> Alright, I understand the wish to bring everything under a realm context. In fact, our extension indeed is also tied to the realm scope. It was implicit, but now I made it explicit, so it better fits mapping the REST paths under a realm. To prevent passing around a realm instance everywhere (besides the KeycloakSession), I use session.getContext().getRealm(). That will be filled whenever you are working ?under? a ?/realms/{realm}/? path. Or is there a risk in this usage? I did use Pedro?s code to be able to map URL?s like ?/auth/realms/{realm}/xxxx? and ?/auth/admin/realms/{realm}/xxxx?. That works fine, so it might be an option for you Greg, so you don?t have to modify the Keycloak sources directly. Or how did you solve that mapping at the moment? Van: Stian Thorgersen [mailto:sthorger at redhat.com] Verzonden: dinsdag 8 december 2015 11:34 Aan: Erik Mulder CC: Greg Jones ; keycloak-dev at lists.jboss.org Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? 'admin' will probably move at some point to be under the realm. 'version' would move as well. Although this one should probably be removed altogether. KeycloakSession and SPIs needs to be tied to a specific realm. This makes everything cleaner. Besides it just doesn't make any sense to add arbitrary rest endpoints to Keycloak. A rest endpoint should be tied to a realm, otherwise it just doesn't make sense to host it on the Keycloak server. On 8 December 2015 at 11:18, Erik Mulder > wrote: Stian, I can see your point. Using the realm name as the root level certainly has advantages. It also really fixes everything to a realm, but I guess that is what you want. So how about the current ?/admin? url, how does that fit in the new picture? Because that would be my next best target to hook into. Furthermore, there?s currently a ?/version? root path that should end up somewhere else. Personally, I think it?s not so bad to have a descriptive root level like ?realms?, which leaves open the possibility to add extra root level paths, like meta data (version) or special contexts (admin, customPath). Van: Stian Thorgersen [mailto:sthorger at redhat.com] Verzonden: dinsdag 8 december 2015 10:32 Aan: Greg Jones > CC: Erik Mulder >; keycloak-dev at lists.jboss.org Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? -1 To adding rest endpoints to the root level. I'd like to get rid of 'realms' part as some point and have all rest endpoints sit underneath a realm. This makes sure the KeycloakSession always knows what realm is being handled, so we don't need to pass the realm around as it can be retrived from the KeycloakContext. It also means that the url can be shortened as we can drop the 'realms' part. On 8 December 2015 at 10:22, Greg Jones > wrote: +1 for these changes. We have been looking at a way to add custom REST endpoints and would be happy to use this approach. Regards Greg Jones > On 8 Dec 2015, at 8:17 PM, Erik Mulder > wrote: > > Pedro's change (see below) is kindof what I was looking for, but for my case and for general flexibility I think it's good to also have a more basic point to hook into the REST API's. > I implemented and tested my own suggestion of having an SPI to be able to add a REST resource at the root level. Combined with the (coming) ability to freely extend the JPA entities and DB schema, I think this creates a really powerful extensibility to Keycloak. When we finish these changes, I can write a blog post about what we did, why and how as a showcase for custom extensions to Keycloak. > > So are the Keycloak dev's open to a PR with a new SPI that enables you to add custom REST paths? > For example, you could create something like: > http://localhost:8080/auth/myPath/myResource > > > -----Oorspronkelijk bericht----- > Van: Pedro Igor Silva [mailto:psilva at redhat.com] > Verzonden: maandag 7 december 2015 22:18 > Aan: Erik Mulder > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > It is part of a working in progress around fine-grained authorization [1]. > > The new SPI changes [2] specific to Keycloak are located in a specific branch [3] in my Keycloak fork. > > I need to discuss these changes with Bill and see what he thinks about it. Depending on his feedback, I can prepare a PR and send these changes to upstream. > > [1] https://github.com/pedroigor/keycloak-authz > [2] https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 > [3] https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified > > Regards. > > ----- Original Message ----- > From: "Erik Mulder" > > To: "Pedro Igor Silva" > > Sent: Monday, December 7, 2015 5:51:26 PM > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? > > Great, that's probably all we need! > I'd like to try it out, but I cannot find any reference to what you mention on Github. Is it (going to be) a pull request? Is it going to be part of a future release? > Can you point me to / provide me with these changes so I can give it a spin? Thanks! > > ________________________________________ > Van: Pedro Igor Silva [psilva at redhat.com] > Verzonden: maandag 7 december 2015 16:03 > Aan: Erik Mulder > CC: keycloak-dev at lists.jboss.org > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > I've done something at this regard, where you can use a SPI in order to plug additional APIs for: > > * Realm Admin RESTFul API (eg.: used by admin console) > * Realm RESFTFul API (eg.: to plug additional endpoints for realms) > > The two Provider interfaces are very simple and just provide a single method: > > Object getResource(String pathName); > > Where pathName is the path that must be resolved to your custom JAX-RS resource. > > The factories are also very simple and allows you to build those resources for the current Realm and KeycloakSession. Eg.: > > RealmResourceProvider create(RealmModel realm, KeycloakSession keycloakSession); > > Do you need something other than that ? > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Erik Mulder" > > To: keycloak-dev at lists.jboss.org > Sent: Monday, December 7, 2015 12:46:39 PM > Subject: [keycloak-dev] Add custom REST paths? New SPI? > > As some of you might know, our team is busy adding data to the keycloak system to incorporate some custom authorization information in the access token. > So far we've successfully extended the JPA entities, Liquibase table definitions and added a custom mapper to put that data in the access token. All of this without custom modifications to the original keycloak sources. This is working great, thanks for the support so far! > I know I've promised some PR's for this and they will come, but first we'd like to get everything fully working, so we know it's a well functioning whole. > > The last piece of the puzzle is extending the REST services to include CRUD actions for our custom resources. I've been looking into the way RESTEasy/JAX-RS works and it seems to me that in the current implementation there is no way to add extra paths. As I see it now, the KeycloakApplication class will register some singletons in it's constructor and that's that. No way to extend or to 'interfere' there. > > So my question is: is there any 'official' way to add extra REST paths to Keycloak? > > If not, is it an idea to add this as a new SPI? The current code for adding root paths in the KeycloakApplication constructor lists: > > singletons.add(new ServerVersionResource()); > singletons.add(new RealmsResource()); > singletons.add(new AdminRoot()); > > So just plain contructor calls. That seems like an easy target for 'SPI-ing' :-). > Or just leave the current ones 'hardcoded' and add an SPI for custom extensions. > Your thoughts on this please. > > As before, I'm happy to implement this myself, but I'd like to discuss it first, so a future PR will be honored. > > > _______________________________________________ > 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/20151208/81d669fc/attachment-0001.html From gregj at thesoftwarecottage.com.au Tue Dec 8 15:36:33 2015 From: gregj at thesoftwarecottage.com.au (Greg Jones) Date: Wed, 9 Dec 2015 07:36:33 +1100 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: <9A5619B792BBA041AE094585791BB71C0137B668B0CD@DDPEX01.DDP.dcloud.local> References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> <9A5619B792BBA041AE094585791BB71C0137B668B0CD@DDPEX01.DDP.dcloud.local> Message-ID: Hi Erik, Sounds like Pedro?s code will help us to do what we need to do. I am currently updating a fork of Keycloak to investigate our needs and have simply added the endpoints to the existing code while we search for a longer-term solution. This one sounds perfect! > On 9 Dec 2015, at 3:00 AM, Erik Mulder wrote: > > Alright, I understand the wish to bring everything under a realm context. In fact, our extension indeed is also tied to the realm scope. It was implicit, but now I made it explicit, so it better fits mapping the REST paths under a realm. To prevent passing around a realm instance everywhere (besides the KeycloakSession), I use session.getContext().getRealm(). That will be filled whenever you are working ?under? a ?/realms/{realm}/? path. Or is there a risk in this usage? > > I did use Pedro?s code to be able to map URL?s like ?/auth/realms/{realm}/xxxx? and ?/auth/admin/realms/{realm}/xxxx?. That works fine, so it might be an option for you Greg, so you don?t have to modify the Keycloak sources directly. Or how did you solve that mapping at the moment? > > > Van: Stian Thorgersen [mailto:sthorger at redhat.com] > Verzonden: dinsdag 8 december 2015 11:34 > Aan: Erik Mulder > CC: Greg Jones ; keycloak-dev at lists.jboss.org > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > 'admin' will probably move at some point to be under the realm. > > 'version' would move as well. Although this one should probably be removed altogether. > > KeycloakSession and SPIs needs to be tied to a specific realm. This makes everything cleaner. > > Besides it just doesn't make any sense to add arbitrary rest endpoints to Keycloak. A rest endpoint should be tied to a realm, otherwise it just doesn't make sense to host it on the Keycloak server. > > > > On 8 December 2015 at 11:18, Erik Mulder > wrote: > Stian, I can see your point. Using the realm name as the root level certainly has advantages. It also really fixes everything to a realm, but I guess that is what you want. So how about the current ?/admin? url, how does that fit in the new picture? Because that would be my next best target to hook into. Furthermore, there?s currently a ?/version? root path that should end up somewhere else. Personally, I think it?s not so bad to have a descriptive root level like ?realms?, which leaves open the possibility to add extra root level paths, like meta data (version) or special contexts (admin, customPath). > > > Van: Stian Thorgersen [mailto:sthorger at redhat.com ] > Verzonden: dinsdag 8 december 2015 10:32 > Aan: Greg Jones > > CC: Erik Mulder >; keycloak-dev at lists.jboss.org > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > -1 To adding rest endpoints to the root level. I'd like to get rid of 'realms' part as some point and have all rest endpoints sit underneath a realm. This makes sure the KeycloakSession always knows what realm is being handled, so we don't need to pass the realm around as it can be retrived from the KeycloakContext. It also means that the url can be shortened as we can drop the 'realms' part. > > On 8 December 2015 at 10:22, Greg Jones > wrote: > +1 for these changes. We have been looking at a way to add custom REST endpoints and would be happy to use this approach. > > Regards > Greg Jones > > > > On 8 Dec 2015, at 8:17 PM, Erik Mulder > wrote: > > > > Pedro's change (see below) is kindof what I was looking for, but for my case and for general flexibility I think it's good to also have a more basic point to hook into the REST API's. > > I implemented and tested my own suggestion of having an SPI to be able to add a REST resource at the root level. Combined with the (coming) ability to freely extend the JPA entities and DB schema, I think this creates a really powerful extensibility to Keycloak. When we finish these changes, I can write a blog post about what we did, why and how as a showcase for custom extensions to Keycloak. > > > > So are the Keycloak dev's open to a PR with a new SPI that enables you to add custom REST paths? > > For example, you could create something like: > > http://localhost:8080/auth/myPath/myResource > > > > > > -----Oorspronkelijk bericht----- > > Van: Pedro Igor Silva [mailto:psilva at redhat.com ] > > Verzonden: maandag 7 december 2015 22:18 > > Aan: Erik Mulder > > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > It is part of a working in progress around fine-grained authorization [1]. > > > > The new SPI changes [2] specific to Keycloak are located in a specific branch [3] in my Keycloak fork. > > > > I need to discuss these changes with Bill and see what he thinks about it. Depending on his feedback, I can prepare a PR and send these changes to upstream. > > > > [1] https://github.com/pedroigor/keycloak-authz > > [2] https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 > > [3] https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified > > > > Regards. > > > > ----- Original Message ----- > > From: "Erik Mulder" > > > To: "Pedro Igor Silva" > > > Sent: Monday, December 7, 2015 5:51:26 PM > > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? > > > > Great, that's probably all we need! > > I'd like to try it out, but I cannot find any reference to what you mention on Github. Is it (going to be) a pull request? Is it going to be part of a future release? > > Can you point me to / provide me with these changes so I can give it a spin? Thanks! > > > > ________________________________________ > > Van: Pedro Igor Silva [psilva at redhat.com ] > > Verzonden: maandag 7 december 2015 16:03 > > Aan: Erik Mulder > > CC: keycloak-dev at lists.jboss.org > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > I've done something at this regard, where you can use a SPI in order to plug additional APIs for: > > > > * Realm Admin RESTFul API (eg.: used by admin console) > > * Realm RESFTFul API (eg.: to plug additional endpoints for realms) > > > > The two Provider interfaces are very simple and just provide a single method: > > > > Object getResource(String pathName); > > > > Where pathName is the path that must be resolved to your custom JAX-RS resource. > > > > The factories are also very simple and allows you to build those resources for the current Realm and KeycloakSession. Eg.: > > > > RealmResourceProvider create(RealmModel realm, KeycloakSession keycloakSession); > > > > Do you need something other than that ? > > > > Regards. > > Pedro Igor > > > > ----- Original Message ----- > > From: "Erik Mulder" > > > To: keycloak-dev at lists.jboss.org > > Sent: Monday, December 7, 2015 12:46:39 PM > > Subject: [keycloak-dev] Add custom REST paths? New SPI? > > > > As some of you might know, our team is busy adding data to the keycloak system to incorporate some custom authorization information in the access token. > > So far we've successfully extended the JPA entities, Liquibase table definitions and added a custom mapper to put that data in the access token. All of this without custom modifications to the original keycloak sources. This is working great, thanks for the support so far! > > I know I've promised some PR's for this and they will come, but first we'd like to get everything fully working, so we know it's a well functioning whole. > > > > The last piece of the puzzle is extending the REST services to include CRUD actions for our custom resources. I've been looking into the way RESTEasy/JAX-RS works and it seems to me that in the current implementation there is no way to add extra paths. As I see it now, the KeycloakApplication class will register some singletons in it's constructor and that's that. No way to extend or to 'interfere' there. > > > > So my question is: is there any 'official' way to add extra REST paths to Keycloak? > > > > If not, is it an idea to add this as a new SPI? The current code for adding root paths in the KeycloakApplication constructor lists: > > > > singletons.add(new ServerVersionResource()); > > singletons.add(new RealmsResource()); > > singletons.add(new AdminRoot()); > > > > So just plain contructor calls. That seems like an easy target for 'SPI-ing' :-). > > Or just leave the current ones 'hardcoded' and add an SPI for custom extensions. > > Your thoughts on this please. > > > > As before, I'm happy to implement this myself, but I'd like to discuss it first, so a future PR will be honored. > > > > > > _______________________________________________ > > 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/20151209/8af6c7c3/attachment-0001.html From chanras.sun at jcamst.com Wed Dec 9 00:35:51 2015 From: chanras.sun at jcamst.com (chanras.sun at jcamst.com) Date: Wed, 9 Dec 2015 12:35:51 +0700 Subject: [keycloak-dev] Use Cassandra as storage instead of MySQL and MongoDB Message-ID: <000001d13243$7907d890$6b1789b0$@jcamst.com> Hi, My core backend system use Cassandra and Elasticsearch, running on Wildfly 9. I need to change keycloak data store implementation to use Cassandra instead of MySQL and MongdoDB. I need also change login, sign up to fit with my web app. What is the best way to change as I mentioned above? Best Regards, Sun Chanras -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151209/2c6b5533/attachment.html From mposolda at redhat.com Wed Dec 9 03:25:50 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 9 Dec 2015 09:25:50 +0100 Subject: [keycloak-dev] Use Cassandra as storage instead of MySQL and MongoDB In-Reply-To: <000001d13243$7907d890$6b1789b0$@jcamst.com> References: <000001d13243$7907d890$6b1789b0$@jcamst.com> Message-ID: <5667E58E.2000602@redhat.com> On 09/12/15 06:35, chanras.sun at jcamst.com wrote: > > Hi, > > My core backend system use Cassandra and Elasticsearch, running on > Wildfly 9. > > I need to change keycloak data store implementation to use Cassandra > instead of MySQL and MongdoDB. > You have already some existing users data in Cassandra? In that case, you can implement federation provider, so your users will be visible to Keycloak and imported into Keycloak internal storage. If you want to store all core model data in Cassandra (realms, users etc), we don't have support for that though. We have just JPA and Mongo support now. I wonder if you can't use JPA model to store data into Cassandra? > I need also change login, sign up to fit with my web app. > We have themes support. See documentation and examples. Marek > > What is the best way to change as I mentioned above? > > Best Regards, > > Sun Chanras > > > > _______________________________________________ > 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/20151209/8beed791/attachment.html From bburke at redhat.com Wed Dec 9 09:33:46 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 9 Dec 2015 09:33:46 -0500 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> Message-ID: <56683BCA.60808@redhat.com> Once we go to host/{realms} we are stuck with it. The matching rules of JAX-RS will prevent us from adding any top level resource that is more specific. Stian, we might want to reconsider removing "/realms". On 12/8/2015 5:34 AM, Stian Thorgersen wrote: > 'admin' will probably move at some point to be under the realm. > > 'version' would move as well. Although this one should probably be > removed altogether. > > KeycloakSession and SPIs needs to be tied to a specific realm. This > makes everything cleaner. > > Besides it just doesn't make any sense to add arbitrary rest endpoints > to Keycloak. A rest endpoint should be tied to a realm, otherwise it > just doesn't make sense to host it on the Keycloak server. > > > > On 8 December 2015 at 11:18, Erik Mulder > > wrote: > > Stian, I can see your point. Using the realm name as the root level > certainly has advantages. It also really fixes everything to a > realm, but I guess that is what you want. So how about the current > ?/admin? url, how does that fit in the new picture? Because that > would be my next best target to hook into. Furthermore, there?s > currently a ?/version? root path that should end up somewhere else. > Personally, I think it?s not so bad to have a descriptive root level > like ?realms?, which leaves open the possibility to add extra root > level paths, like meta data (version) or special contexts (admin, > customPath).____ > > __ __ > > __ __ > > *Van:*Stian Thorgersen [mailto:sthorger at redhat.com > ] > *Verzonden:* dinsdag 8 december 2015 10:32 > *Aan:* Greg Jones > > *CC:* Erik Mulder >; > keycloak-dev at lists.jboss.org > > > *Onderwerp:* Re: [keycloak-dev] Add custom REST paths? New SPI?____ > > __ __ > > -1 To adding rest endpoints to the root level. I'd like to get rid > of 'realms' part as some point and have all rest endpoints sit > underneath a realm. This makes sure the KeycloakSession always knows > what realm is being handled, so we don't need to pass the realm > around as it can be retrived from the KeycloakContext. It also means > that the url can be shortened as we can drop the 'realms' part.____ > > __ __ > > On 8 December 2015 at 10:22, Greg Jones > > wrote:____ > > +1 for these changes. We have been looking at a way to add > custom REST endpoints and would be happy to use this approach. > > Regards > Greg Jones____ > > > > > On 8 Dec 2015, at 8:17 PM, Erik Mulder > > wrote: > > > > Pedro's change (see below) is kindof what I was looking for, > but for my case and for general flexibility I think it's good to > also have a more basic point to hook into the REST API's. > > I implemented and tested my own suggestion of having an SPI > to be able to add a REST resource at the root level. Combined > with the (coming) ability to freely extend the JPA entities and > DB schema, I think this creates a really powerful extensibility > to Keycloak. When we finish these changes, I can write a blog > post about what we did, why and how as a showcase for custom > extensions to Keycloak. > > > > So are the Keycloak dev's open to a PR with a new SPI that > enables you to add custom REST paths? > > For example, you could create something like: > > http://localhost:8080/auth/myPath/myResource > > > > > > -----Oorspronkelijk bericht----- > > Van: Pedro Igor Silva [mailto:psilva at redhat.com > ] > > Verzonden: maandag 7 december 2015 22:18 > > Aan: Erik Mulder > > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > It is part of a working in progress around fine-grained > authorization [1]. > > > > The new SPI changes [2] specific to Keycloak are located in a > specific branch [3] in my Keycloak fork. > > > > I need to discuss these changes with Bill and see what he > thinks about it. Depending on his feedback, I can prepare a PR > and send these changes to upstream. > > > > [1] https://github.com/pedroigor/keycloak-authz > > [2] > https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 > > [3] > https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified > > > > Regards. > > > > ----- Original Message ----- > > From: "Erik Mulder" > > > To: "Pedro Igor Silva" > > > Sent: Monday, December 7, 2015 5:51:26 PM > > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? > > > > Great, that's probably all we need! > > I'd like to try it out, but I cannot find any reference to > what you mention on Github. Is it (going to be) a pull request? > Is it going to be part of a future release? > > Can you point me to / provide me with these changes so I can > give it a spin? Thanks! > > > > ________________________________________ > > Van: Pedro Igor Silva [psilva at redhat.com > ] > > Verzonden: maandag 7 december 2015 16:03 > > Aan: Erik Mulder > > CC: keycloak-dev at lists.jboss.org > > > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? > > > > I've done something at this regard, where you can use a SPI > in order to plug additional APIs for: > > > > * Realm Admin RESTFul API (eg.: used by admin console) > > * Realm RESFTFul API (eg.: to plug additional endpoints > for realms) > > > > The two Provider interfaces are very simple and just provide > a single method: > > > > Object getResource(String pathName); > > > > Where pathName is the path that must be resolved to your > custom JAX-RS resource. > > > > The factories are also very simple and allows you to build > those resources for the current Realm and KeycloakSession. Eg.: > > > > RealmResourceProvider create(RealmModel realm, > KeycloakSession keycloakSession); > > > > Do you need something other than that ? > > > > Regards. > > Pedro Igor > > > > ----- Original Message ----- > > From: "Erik Mulder" > > > To: keycloak-dev at lists.jboss.org > > > Sent: Monday, December 7, 2015 12:46:39 PM > > Subject: [keycloak-dev] Add custom REST paths? New SPI? > > > > As some of you might know, our team is busy adding data to > the keycloak system to incorporate some custom authorization > information in the access token. > > So far we've successfully extended the JPA entities, > Liquibase table definitions and added a custom mapper to put > that data in the access token. All of this without custom > modifications to the original keycloak sources. This is working > great, thanks for the support so far! > > I know I've promised some PR's for this and they will come, > but first we'd like to get everything fully working, so we know > it's a well functioning whole. > > > > The last piece of the puzzle is extending the REST services > to include CRUD actions for our custom resources. I've been > looking into the way RESTEasy/JAX-RS works and it seems to me > that in the current implementation there is no way to add extra > paths. As I see it now, the KeycloakApplication class will > register some singletons in it's constructor and that's that. No > way to extend or to 'interfere' there. > > > > So my question is: is there any 'official' way to add extra > REST paths to Keycloak? > > > > If not, is it an idea to add this as a new SPI? The current > code for adding root paths in the KeycloakApplication > constructor lists: > > > > singletons.add(new ServerVersionResource()); > > singletons.add(new RealmsResource()); > > singletons.add(new AdminRoot()); > > > > So just plain contructor calls. That seems like an easy > target for 'SPI-ing' :-). > > Or just leave the current ones 'hardcoded' and add an SPI for > custom extensions. > > Your thoughts on this please. > > > > As before, I'm happy to implement this myself, but I'd like > to discuss it first, so a future PR will be honored. > > > > > > _______________________________________________ > > 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 mposolda at redhat.com Wed Dec 9 13:15:42 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 9 Dec 2015 19:15:42 +0100 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: <56683BCA.60808@redhat.com> References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> <56683BCA.60808@redhat.com> Message-ID: <56686FCE.4020609@redhat.com> +1 some things like ServerVersionResource or static resources ( keycloak.js etc) are just not tight to any specific realm. Removing "/realms" would mean that we will need to move all of them under the path specific to some realm. For example move keycloak.js under "http://localhost:8080/auth/foo/keycloak.js" . But that doesn't seem to be very good practice as keycloak.js is not resource specific to realm "foo" . If we want shorter and more user-memorable URLs, we can maybe introduce some URLAliasService, where will people have possibility to define short URL aliases for some endpoints. This might have support for regexes etc. However Apache HTTPD already provides something like this AFAIK Marek On 09/12/15 15:33, Bill Burke wrote: > Once we go to host/{realms} we are stuck with it. The matching rules of > JAX-RS will prevent us from adding any top level resource that is more > specific. Stian, we might want to reconsider removing "/realms". > > On 12/8/2015 5:34 AM, Stian Thorgersen wrote: >> 'admin' will probably move at some point to be under the realm. >> >> 'version' would move as well. Although this one should probably be >> removed altogether. >> >> KeycloakSession and SPIs needs to be tied to a specific realm. This >> makes everything cleaner. >> >> Besides it just doesn't make any sense to add arbitrary rest endpoints >> to Keycloak. A rest endpoint should be tied to a realm, otherwise it >> just doesn't make sense to host it on the Keycloak server. >> >> >> >> On 8 December 2015 at 11:18, Erik Mulder >> > > wrote: >> >> Stian, I can see your point. Using the realm name as the root level >> certainly has advantages. It also really fixes everything to a >> realm, but I guess that is what you want. So how about the current >> ?/admin? url, how does that fit in the new picture? Because that >> would be my next best target to hook into. Furthermore, there?s >> currently a ?/version? root path that should end up somewhere else. >> Personally, I think it?s not so bad to have a descriptive root level >> like ?realms?, which leaves open the possibility to add extra root >> level paths, like meta data (version) or special contexts (admin, >> customPath).____ >> >> __ __ >> >> __ __ >> >> *Van:*Stian Thorgersen [mailto:sthorger at redhat.com >> ] >> *Verzonden:* dinsdag 8 december 2015 10:32 >> *Aan:* Greg Jones > > >> *CC:* Erik Mulder > >; >> keycloak-dev at lists.jboss.org >> >> >> *Onderwerp:* Re: [keycloak-dev] Add custom REST paths? New SPI?____ >> >> __ __ >> >> -1 To adding rest endpoints to the root level. I'd like to get rid >> of 'realms' part as some point and have all rest endpoints sit >> underneath a realm. This makes sure the KeycloakSession always knows >> what realm is being handled, so we don't need to pass the realm >> around as it can be retrived from the KeycloakContext. It also means >> that the url can be shortened as we can drop the 'realms' part.____ >> >> __ __ >> >> On 8 December 2015 at 10:22, Greg Jones >> > > wrote:____ >> >> +1 for these changes. We have been looking at a way to add >> custom REST endpoints and would be happy to use this approach. >> >> Regards >> Greg Jones____ >> >> >> >> > On 8 Dec 2015, at 8:17 PM, Erik Mulder >> > > wrote: >> > >> > Pedro's change (see below) is kindof what I was looking for, >> but for my case and for general flexibility I think it's good to >> also have a more basic point to hook into the REST API's. >> > I implemented and tested my own suggestion of having an SPI >> to be able to add a REST resource at the root level. Combined >> with the (coming) ability to freely extend the JPA entities and >> DB schema, I think this creates a really powerful extensibility >> to Keycloak. When we finish these changes, I can write a blog >> post about what we did, why and how as a showcase for custom >> extensions to Keycloak. >> > >> > So are the Keycloak dev's open to a PR with a new SPI that >> enables you to add custom REST paths? >> > For example, you could create something like: >> > http://localhost:8080/auth/myPath/myResource >> > >> > >> > -----Oorspronkelijk bericht----- >> > Van: Pedro Igor Silva [mailto:psilva at redhat.com >> ] >> > Verzonden: maandag 7 december 2015 22:18 >> > Aan: Erik Mulder > > >> > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? >> > >> > It is part of a working in progress around fine-grained >> authorization [1]. >> > >> > The new SPI changes [2] specific to Keycloak are located in a >> specific branch [3] in my Keycloak fork. >> > >> > I need to discuss these changes with Bill and see what he >> thinks about it. Depending on his feedback, I can prepare a PR >> and send these changes to upstream. >> > >> > [1] https://github.com/pedroigor/keycloak-authz >> > [2] >> https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 >> > [3] >> https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified >> > >> > Regards. >> > >> > ----- Original Message ----- >> > From: "Erik Mulder" > > >> > To: "Pedro Igor Silva" > > >> > Sent: Monday, December 7, 2015 5:51:26 PM >> > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? >> > >> > Great, that's probably all we need! >> > I'd like to try it out, but I cannot find any reference to >> what you mention on Github. Is it (going to be) a pull request? >> Is it going to be part of a future release? >> > Can you point me to / provide me with these changes so I can >> give it a spin? Thanks! >> > >> > ________________________________________ >> > Van: Pedro Igor Silva [psilva at redhat.com >> ] >> > Verzonden: maandag 7 december 2015 16:03 >> > Aan: Erik Mulder >> > CC: keycloak-dev at lists.jboss.org >> >> > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New SPI? >> > >> > I've done something at this regard, where you can use a SPI >> in order to plug additional APIs for: >> > >> > * Realm Admin RESTFul API (eg.: used by admin console) >> > * Realm RESFTFul API (eg.: to plug additional endpoints >> for realms) >> > >> > The two Provider interfaces are very simple and just provide >> a single method: >> > >> > Object getResource(String pathName); >> > >> > Where pathName is the path that must be resolved to your >> custom JAX-RS resource. >> > >> > The factories are also very simple and allows you to build >> those resources for the current Realm and KeycloakSession. Eg.: >> > >> > RealmResourceProvider create(RealmModel realm, >> KeycloakSession keycloakSession); >> > >> > Do you need something other than that ? >> > >> > Regards. >> > Pedro Igor >> > >> > ----- Original Message ----- >> > From: "Erik Mulder" > > >> > To: keycloak-dev at lists.jboss.org >> >> > Sent: Monday, December 7, 2015 12:46:39 PM >> > Subject: [keycloak-dev] Add custom REST paths? New SPI? >> > >> > As some of you might know, our team is busy adding data to >> the keycloak system to incorporate some custom authorization >> information in the access token. >> > So far we've successfully extended the JPA entities, >> Liquibase table definitions and added a custom mapper to put >> that data in the access token. All of this without custom >> modifications to the original keycloak sources. This is working >> great, thanks for the support so far! >> > I know I've promised some PR's for this and they will come, >> but first we'd like to get everything fully working, so we know >> it's a well functioning whole. >> > >> > The last piece of the puzzle is extending the REST services >> to include CRUD actions for our custom resources. I've been >> looking into the way RESTEasy/JAX-RS works and it seems to me >> that in the current implementation there is no way to add extra >> paths. As I see it now, the KeycloakApplication class will >> register some singletons in it's constructor and that's that. No >> way to extend or to 'interfere' there. >> > >> > So my question is: is there any 'official' way to add extra >> REST paths to Keycloak? >> > >> > If not, is it an idea to add this as a new SPI? The current >> code for adding root paths in the KeycloakApplication >> constructor lists: >> > >> > singletons.add(new ServerVersionResource()); >> > singletons.add(new RealmsResource()); >> > singletons.add(new AdminRoot()); >> > >> > So just plain contructor calls. That seems like an easy >> target for 'SPI-ing' :-). >> > Or just leave the current ones 'hardcoded' and add an SPI for >> custom extensions. >> > Your thoughts on this please. >> > >> > As before, I'm happy to implement this myself, but I'd like >> to discuss it first, so a future PR will be honored. >> > >> > >> > _______________________________________________ >> > 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 >> From jm85martins at gmail.com Wed Dec 9 13:33:09 2015 From: jm85martins at gmail.com (Jorge M.) Date: Wed, 9 Dec 2015 18:33:09 +0000 Subject: [keycloak-dev] Custom federation - webservice Message-ID: I'm developing a custom federation that communicates with my user repository via webservices. Probably this is a very strange scenario for a federation but that's the unique way that I have to communicate with the repository. My problem is that, as the webservices only exposes methods such as createUser and updateUser, I'm having problems with registrations and user profile updates because I'm not being able to do atomic calls to the webservice methods, with all the information that I need. As far as I know, from the properties file example and from the ldap federation source (probably I'm missing something) it seems that the federation api is intended to update and sync attribute by attribute (Keycloak <-> Federation). Am i wrong? Do you suggest another approach? Should I give up from having a federation that uses a webservice? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151209/b64dc556/attachment.html From mposolda at redhat.com Wed Dec 9 13:35:41 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 9 Dec 2015 19:35:41 +0100 Subject: [keycloak-dev] cross-realm administration In-Reply-To: <5666D228.6080402@redhat.com> References: <5666D228.6080402@redhat.com> Message-ID: <5668747D.80502@redhat.com> On 08/12/15 13:50, Bill Burke wrote: > Continuing our hangout from yesterday... > > The primary goal, IMO is to 1) clean up the master realm realm clients > 2) remove the master realm requirement for cross-realm impersonation 3) > give possibility to remove the master realm > > Right now non-master realms trust admins in the master realm. These > "child" realms allow the master realm to decide which users in the > master realm are allowed to access it. I'll call this "cross-realm > administration". We could continue this model, but without role > namespaces you'd have to create realm-clients in each trusted realm. > > Another idea is to do something really simple. Realm A decides to trust > Realm B and they "share" admin roles. If user in Realm B has > "view-user" permission, then he also has "view-user" permission. The UI > is simple and there's no need for Realm A and B to know anything else > about each other. This is a simpler version of "cross-realm > administration" which doesn't give you any fine grain per-realm control. > This requires very little UI work which is the big blocker for me. > > Building on that idea, which is what I started to implement, is that > Realm A "shares" admin roles still, but only allows certain permissions > for Realm B. Realm A grants admins in Realm B "view user and create client" How about the case when I want to have: 1) user "a-admin" in realm A, which is supposed to have "view-user" permission just for realm A 2) user "b-admin" in realm B, which is supposed to have "view-user" permission just for realm B 3) user "admin" in realm A, which is supposed to have "view-user" permission for both realms A and B If I understand correctly, I won't be able to model this because: For rule (3), I need realm B to trust realm A . However that implies that user "a-admin" from realm A will be able to have "view-user" for realm B, which breaks rule (1) and is something I don't want. But still, maybe most of the people don't need something powerful and this simple model will be sufficient for them? Maybe we can go with simple model for now and later (after 1.0) we can introduce something more powerful and incorporate Pedro's authorization stuff to be able to specify more fine-grained permissions? Marek > > If you want to go further with the ability to grant a specific user or > group in another realm admin privileges then it becomes more > complicated. You have a chicken and egg problem first as you'd need a > way to view users and groups in another realm so you can grant > permission to them. I guess it could be you > > 1. Granting trust ot a realm allows that realm to view your users and > groups. Well, at least query for username/email/attributes > 2. UI screens would have to be created specific for managing > users/groups in another realm as you would want to filter what > information gets displayed > > From mposolda at redhat.com Wed Dec 9 13:39:24 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 9 Dec 2015 19:39:24 +0100 Subject: [keycloak-dev] Custom federation - webservice In-Reply-To: References: Message-ID: <5668755C.6040500@redhat.com> On 09/12/15 19:33, Jorge M. wrote: > > I'm developing a custom federation that communicates with my user > repository via webservices. > Probably this is a very strange scenario for a federation but that's > the unique way that I have to communicate with the repository. > > My problem is that, as the webservices only exposes methods such as > createUser and updateUser, I'm having problems with registrations and > user profile updates because I'm not being able to do atomic calls to > the webservice methods, with all the information that I need. > > As far as I know, from the properties file example and from the ldap > federation source (probably I'm missing something) it seems that the > federation api is intended to update and sync attribute by attribute > (Keycloak <-> Federation). > Am i wrong? Do you suggest another approach? Should I give up from > having a federation that uses a webservice? > You can use "transaction wrapper", which will allow you to store all the updates to user locally, but send the UPDATE request to your webservice later at transaction commit time. You may need to create custom transaction and enlist it with Keycloak TransactionManager. This is what we have for LDAP federation provider right now. See TxAwareLDAPUserModelDelegate. Marek > > 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/20151209/2e57ed5c/attachment.html From bburke at redhat.com Wed Dec 9 14:18:04 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 9 Dec 2015 14:18:04 -0500 Subject: [keycloak-dev] new URI scheme In-Reply-To: <56686FCE.4020609@redhat.com> References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> <56683BCA.60808@redhat.com> <56686FCE.4020609@redhat.com> Message-ID: <56687E6C.8030108@redhat.com> We can remove /auth, but reworking the rest of the URI scheme depends on a few things (some we have discussed): * We need the flexibility to add root resources. {realm} as the root resource does not play well with JAX-RS if you ahve more specific root resources you want to add * There are already specific root resources: /version, and /js/keycloak.js and /qrcode and /resources and "/" * There are a number of public URIs under /realms/ i.e. .well-known Our URIs actually aren't bad: /admin/realms - admin REST API /admin/serverinfo - admin REST API describing installed server providers /admin/{realm}/console - admin console login for a specific realm /admin - redirects to /admin/master/console /admin/index.html - redirects to /admin/master/console /realms/{realm}/account - account service /realms/{realm}/protocol - protocol specific endpoints for SAML, etc. /realms/{realm}/broker - broker specific endpoints for SAML, etc. /realms/{realm}/login-actions - auth flow for reg, auth, reset, etc. We will want to refactor the admin REST API, but other than that the URI scheme is ok and allowed us to modularize code into Sub Resource Locators quite nicely. One thing I might change is the admin console and make it consistent with account: /realms/{realm}/console That's it though. On 12/9/2015 1:15 PM, Marek Posolda wrote: > +1 > > some things like ServerVersionResource or static resources ( keycloak.js > etc) are just not tight to any specific realm. Removing "/realms" would > mean that we will need to move all of them under the path specific to > some realm. For example move keycloak.js under > "http://localhost:8080/auth/foo/keycloak.js" . But that doesn't seem to > be very good practice as keycloak.js is not resource specific to realm > "foo" . > > If we want shorter and more user-memorable URLs, we can maybe introduce > some URLAliasService, where will people have possibility to define short > URL aliases for some endpoints. This might have support for regexes etc. > However Apache HTTPD already provides something like this AFAIK > > Marek > > > On 09/12/15 15:33, Bill Burke wrote: >> Once we go to host/{realms} we are stuck with it. The matching rules of >> JAX-RS will prevent us from adding any top level resource that is more >> specific. Stian, we might want to reconsider removing "/realms". >> >> On 12/8/2015 5:34 AM, Stian Thorgersen wrote: >>> 'admin' will probably move at some point to be under the realm. >>> >>> 'version' would move as well. Although this one should probably be >>> removed altogether. >>> >>> KeycloakSession and SPIs needs to be tied to a specific realm. This >>> makes everything cleaner. >>> >>> Besides it just doesn't make any sense to add arbitrary rest endpoints >>> to Keycloak. A rest endpoint should be tied to a realm, otherwise it >>> just doesn't make sense to host it on the Keycloak server. >>> >>> >>> >>> On 8 December 2015 at 11:18, Erik Mulder >>> >> > wrote: >>> >>> Stian, I can see your point. Using the realm name as the root level >>> certainly has advantages. It also really fixes everything to a >>> realm, but I guess that is what you want. So how about the current >>> ?/admin? url, how does that fit in the new picture? Because that >>> would be my next best target to hook into. Furthermore, there?s >>> currently a ?/version? root path that should end up somewhere else. >>> Personally, I think it?s not so bad to have a descriptive root >>> level >>> like ?realms?, which leaves open the possibility to add extra root >>> level paths, like meta data (version) or special contexts (admin, >>> customPath).____ >>> >>> __ __ >>> >>> __ __ >>> >>> *Van:*Stian Thorgersen [mailto:sthorger at redhat.com >>> ] >>> *Verzonden:* dinsdag 8 december 2015 10:32 >>> *Aan:* Greg Jones >> > >>> *CC:* Erik Mulder >> >; >>> keycloak-dev at lists.jboss.org >>> >>> >>> *Onderwerp:* Re: [keycloak-dev] Add custom REST paths? New SPI?____ >>> >>> __ __ >>> >>> -1 To adding rest endpoints to the root level. I'd like to get rid >>> of 'realms' part as some point and have all rest endpoints sit >>> underneath a realm. This makes sure the KeycloakSession always >>> knows >>> what realm is being handled, so we don't need to pass the realm >>> around as it can be retrived from the KeycloakContext. It also >>> means >>> that the url can be shortened as we can drop the 'realms' part.____ >>> >>> __ __ >>> >>> On 8 December 2015 at 10:22, Greg Jones >>> >> > wrote:____ >>> >>> +1 for these changes. We have been looking at a way to add >>> custom REST endpoints and would be happy to use this approach. >>> >>> Regards >>> Greg Jones____ >>> >>> >>> >>> > On 8 Dec 2015, at 8:17 PM, Erik Mulder >>> >> > wrote: >>> > >>> > Pedro's change (see below) is kindof what I was looking for, >>> but for my case and for general flexibility I think it's >>> good to >>> also have a more basic point to hook into the REST API's. >>> > I implemented and tested my own suggestion of having an SPI >>> to be able to add a REST resource at the root level. Combined >>> with the (coming) ability to freely extend the JPA entities and >>> DB schema, I think this creates a really powerful extensibility >>> to Keycloak. When we finish these changes, I can write a blog >>> post about what we did, why and how as a showcase for custom >>> extensions to Keycloak. >>> > >>> > So are the Keycloak dev's open to a PR with a new SPI that >>> enables you to add custom REST paths? >>> > For example, you could create something like: >>> > http://localhost:8080/auth/myPath/myResource >>> > >>> > >>> > -----Oorspronkelijk bericht----- >>> > Van: Pedro Igor Silva [mailto:psilva at redhat.com >>> ] >>> > Verzonden: maandag 7 december 2015 22:18 >>> > Aan: Erik Mulder >> > >>> > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New >>> SPI? >>> > >>> > It is part of a working in progress around fine-grained >>> authorization [1]. >>> > >>> > The new SPI changes [2] specific to Keycloak are located >>> in a >>> specific branch [3] in my Keycloak fork. >>> > >>> > I need to discuss these changes with Bill and see what he >>> thinks about it. Depending on his feedback, I can prepare a PR >>> and send these changes to upstream. >>> > >>> > [1] https://github.com/pedroigor/keycloak-authz >>> > [2] >>> >>> https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 >>> >>> > [3] >>> >>> https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified >>> > >>> > Regards. >>> > >>> > ----- Original Message ----- >>> > From: "Erik Mulder" >> > >>> > To: "Pedro Igor Silva" >> > >>> > Sent: Monday, December 7, 2015 5:51:26 PM >>> > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? >>> > >>> > Great, that's probably all we need! >>> > I'd like to try it out, but I cannot find any reference to >>> what you mention on Github. Is it (going to be) a pull request? >>> Is it going to be part of a future release? >>> > Can you point me to / provide me with these changes so I can >>> give it a spin? Thanks! >>> > >>> > ________________________________________ >>> > Van: Pedro Igor Silva [psilva at redhat.com >>> ] >>> > Verzonden: maandag 7 december 2015 16:03 >>> > Aan: Erik Mulder >>> > CC: keycloak-dev at lists.jboss.org >>> >>> > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New >>> SPI? >>> > >>> > I've done something at this regard, where you can use a SPI >>> in order to plug additional APIs for: >>> > >>> > * Realm Admin RESTFul API (eg.: used by admin console) >>> > * Realm RESFTFul API (eg.: to plug additional endpoints >>> for realms) >>> > >>> > The two Provider interfaces are very simple and just provide >>> a single method: >>> > >>> > Object getResource(String pathName); >>> > >>> > Where pathName is the path that must be resolved to your >>> custom JAX-RS resource. >>> > >>> > The factories are also very simple and allows you to build >>> those resources for the current Realm and KeycloakSession. Eg.: >>> > >>> > RealmResourceProvider create(RealmModel realm, >>> KeycloakSession keycloakSession); >>> > >>> > Do you need something other than that ? >>> > >>> > Regards. >>> > Pedro Igor >>> > >>> > ----- Original Message ----- >>> > From: "Erik Mulder" >> > >>> > To: keycloak-dev at lists.jboss.org >>> >>> > Sent: Monday, December 7, 2015 12:46:39 PM >>> > Subject: [keycloak-dev] Add custom REST paths? New SPI? >>> > >>> > As some of you might know, our team is busy adding data to >>> the keycloak system to incorporate some custom authorization >>> information in the access token. >>> > So far we've successfully extended the JPA entities, >>> Liquibase table definitions and added a custom mapper to put >>> that data in the access token. All of this without custom >>> modifications to the original keycloak sources. This is working >>> great, thanks for the support so far! >>> > I know I've promised some PR's for this and they will come, >>> but first we'd like to get everything fully working, so we know >>> it's a well functioning whole. >>> > >>> > The last piece of the puzzle is extending the REST services >>> to include CRUD actions for our custom resources. I've been >>> looking into the way RESTEasy/JAX-RS works and it seems to me >>> that in the current implementation there is no way to add extra >>> paths. As I see it now, the KeycloakApplication class will >>> register some singletons in it's constructor and that's >>> that. No >>> way to extend or to 'interfere' there. >>> > >>> > So my question is: is there any 'official' way to add extra >>> REST paths to Keycloak? >>> > >>> > If not, is it an idea to add this as a new SPI? The current >>> code for adding root paths in the KeycloakApplication >>> constructor lists: >>> > >>> > singletons.add(new ServerVersionResource()); >>> > singletons.add(new RealmsResource()); >>> > singletons.add(new AdminRoot()); >>> > >>> > So just plain contructor calls. That seems like an easy >>> target for 'SPI-ing' :-). >>> > Or just leave the current ones 'hardcoded' and add an SPI >>> for >>> custom extensions. >>> > Your thoughts on this please. >>> > >>> > As before, I'm happy to implement this myself, but I'd like >>> to discuss it first, so a future PR will be honored. >>> > >>> > >>> > _______________________________________________ >>> > 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 bburke at redhat.com Wed Dec 9 14:22:46 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 9 Dec 2015 14:22:46 -0500 Subject: [keycloak-dev] cross-realm administration In-Reply-To: <5668747D.80502@redhat.com> References: <5666D228.6080402@redhat.com> <5668747D.80502@redhat.com> Message-ID: <56687F86.9080302@redhat.com> On 12/9/2015 1:35 PM, Marek Posolda wrote: > On 08/12/15 13:50, Bill Burke wrote: >> Continuing our hangout from yesterday... >> >> The primary goal, IMO is to 1) clean up the master realm realm clients >> 2) remove the master realm requirement for cross-realm impersonation 3) >> give possibility to remove the master realm >> >> Right now non-master realms trust admins in the master realm. These >> "child" realms allow the master realm to decide which users in the >> master realm are allowed to access it. I'll call this "cross-realm >> administration". We could continue this model, but without role >> namespaces you'd have to create realm-clients in each trusted realm. >> >> Another idea is to do something really simple. Realm A decides to trust >> Realm B and they "share" admin roles. If user in Realm B has >> "view-user" permission, then he also has "view-user" permission. The UI >> is simple and there's no need for Realm A and B to know anything else >> about each other. This is a simpler version of "cross-realm >> administration" which doesn't give you any fine grain per-realm control. >> This requires very little UI work which is the big blocker for me. >> >> Building on that idea, which is what I started to implement, is that >> Realm A "shares" admin roles still, but only allows certain permissions >> for Realm B. Realm A grants admins in Realm B "view user and create >> client" > How about the case when I want to have: > 1) user "a-admin" in realm A, which is supposed to have "view-user" > permission just for realm A > 2) user "b-admin" in realm B, which is supposed to have "view-user" > permission just for realm B > 3) user "admin" in realm A, which is supposed to have "view-user" > permission for both realms A and B > > If I understand correctly, I won't be able to model this because: > For rule (3), I need realm B to trust realm A . However that implies > that user "a-admin" from realm A will be able to have "view-user" for > realm B, which breaks rule (1) and is something I don't want. > > But still, maybe most of the people don't need something powerful and > this simple model will be sufficient for them? Maybe we can go with > simple model for now and later (after 1.0) we can introduce something > more powerful and incorporate Pedro's authorization stuff to be able to > specify more fine-grained permissions? > Eh, the simple model breaks backward compatibility. Maybe the focus should be on just continuing what we have: * Cleaning up master realm per realm clients. We would need to keep this metadata somewhere else though. * Ability to turn any one realm into a "master" realm for a set of "child" realms. So, everything works the same way as we have now except assigning per realm permissions in the master realm has a new UI, and we can turn any other realm into a master realm with the same UI. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Dec 9 14:33:51 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 9 Dec 2015 14:33:51 -0500 Subject: [keycloak-dev] cross-realm adminstration part II Message-ID: <5668821F.8080602@redhat.com> So, decided on goals are: * remove and provide alternative for master realm per-realm clients * Ability to turn any realm into a "master" realm of a set of realms Maybe we should just wait for role namespaces....I'll work on client templates instead. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From gerbermichi at me.com Thu Dec 10 07:29:09 2015 From: gerbermichi at me.com (Michael Gerber) Date: Thu, 10 Dec 2015 12:29:09 +0000 (GMT) Subject: [keycloak-dev] NoSuchMethodError Message-ID: Hi, I am using WildFly 10.0.0.CR4 and Keycloak 1.7.0.CR1. I received the following error: 2015-12-10 12:26:59,012 ERROR [io.undertow.request] (default task-74) UT005023: Exception handling request to /admin/system-config/login.html: java.lang.NoSuchMethodError: io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V at org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] at org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] at org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88) [keycloak-adapter-core-1.7.0.CR1.jar:1.7.0.CR1] at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:788) [undertow-core-1.3.3.Final.jar:1.3.3.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_51] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_51] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51] It looks like the method?Connectors.ungetRequestBytes has changed.... Keycloak currently uses undertow-core-1.1.1.Final and Wildfly uses undertow-core.1.3.3.Final. Should I create a JIRA for that or is that already known? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151210/026718b3/attachment.html From bburke at redhat.com Thu Dec 10 09:09:25 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 10 Dec 2015 09:09:25 -0500 Subject: [keycloak-dev] NoSuchMethodError In-Reply-To: References: Message-ID: <56698795.508@redhat.com> jira please On 12/10/2015 7:29 AM, Michael Gerber wrote: > Hi, > > I am using WildFly 10.0.0.CR4 and Keycloak 1.7.0.CR1. > > I received the following error: > 2015-12-10 12:26:59,012 ERROR [io.undertow.request] (default task-74) > UT005023: Exception handling request to /admin/system-config/login.html: > java.lang.NoSuchMethodError: > io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V > at > org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112) > [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] > at > org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119) > [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] > at > org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67) > [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] > at > org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88) > [keycloak-adapter-core-1.7.0.CR1.jar:1.7.0.CR1] > at > org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) > [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] > at > org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) > [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) > [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) > [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > [keycloak-undertow-adapter-1.7.0.CR1.jar:1.7.0.CR1] > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > [undertow-servlet-1.3.3.Final.jar:1.3.3.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:788) > [undertow-core-1.3.3.Final.jar:1.3.3.Final] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [rt.jar:1.8.0_51] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [rt.jar:1.8.0_51] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51] > > It looks like the method Connectors.ungetRequestBytes has changed.... > > Keycloak currently uses undertow-core-1.1.1.Final and Wildfly uses > undertow-core.1.3.3.Final. > > Should I create a JIRA for that or is that already known? > > 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 mposolda at redhat.com Thu Dec 10 10:24:55 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 10 Dec 2015 16:24:55 +0100 Subject: [keycloak-dev] cross-realm adminstration part II In-Reply-To: <5668821F.8080602@redhat.com> References: <5668821F.8080602@redhat.com> Message-ID: <56699947.2000100@redhat.com> On 09/12/15 20:33, Bill Burke wrote: > So, decided on goals are: > > * remove and provide alternative for master realm per-realm clients > * Ability to turn any realm into a "master" realm of a set of realms > > Maybe we should just wait for role namespaces....I'll work on client > templates instead. > > +1 to wait for role-namespaces. Otherwise I am not seeing how to easily get rid of master realm per-realm clients... Marek From jm85martins at gmail.com Thu Dec 10 12:49:35 2015 From: jm85martins at gmail.com (Jorge M.) Date: Thu, 10 Dec 2015 17:49:35 +0000 Subject: [keycloak-dev] Custom federation - webservice In-Reply-To: <5668755C.6040500@redhat.com> References: <5668755C.6040500@redhat.com> Message-ID: Hi, I think I'm in the right track now. I'm being able to call the webservice before commit. However, when the user is sucessfully created by the webservice, I need to update my local user to add a property with the external user id. How can I do that in the same transaction? I'm trying to set the property on the managed delegate user model, but it has no effect. Thank you! On 9 Dec 2015 18:39, "Marek Posolda" wrote: > On 09/12/15 19:33, Jorge M. wrote: > > I'm developing a custom federation that communicates with my user > repository via webservices. > Probably this is a very strange scenario for a federation but that's the > unique way that I have to communicate with the repository. > > My problem is that, as the webservices only exposes methods such as > createUser and updateUser, I'm having problems with registrations and user > profile updates because I'm not being able to do atomic calls to the > webservice methods, with all the information that I need. > > As far as I know, from the properties file example and from the ldap > federation source (probably I'm missing something) it seems that the > federation api is intended to update and sync attribute by attribute > (Keycloak <-> Federation). > Am i wrong? Do you suggest another approach? Should I give up from having > a federation that uses a webservice? > > You can use "transaction wrapper", which will allow you to store all the > updates to user locally, but send the UPDATE request to your webservice > later at transaction commit time. You may need to create custom transaction > and enlist it with Keycloak TransactionManager. > > This is what we have for LDAP federation provider right now. See > TxAwareLDAPUserModelDelegate. > > Marek > > Thank you. > > > _______________________________________________ > 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/20151210/ceced954/attachment.html From velias at redhat.com Fri Dec 11 04:50:11 2015 From: velias at redhat.com (Vlastimil Elias) Date: Fri, 11 Dec 2015 10:50:11 +0100 Subject: [keycloak-dev] Custom federation - webservice In-Reply-To: References: <5668755C.6040500@redhat.com> Message-ID: <566A9C53.1080401@redhat.com> Hi, I use similar approach and problem is (at least I think) that local DB transaction is already commited when our code runs. It has two negative effects: - if remote service call is successful you are not able to write anything locally as Jorge mentioned - if remote service call fails local DB record is commited already and it is hard to implement correct error handling So I think User Federation SPI should be extended by exact method which allows atomic call of backend during user creation or update before local transaction is commited. I already created issue for it but not resolved yet https://issues.jboss.org/browse/KEYCLOAK-1075 Vlastimil On 10.12.2015 18:49, Jorge M. wrote: > > Hi, > > I think I'm in the right track now. I'm being able to call the > webservice before commit. However, when the user is sucessfully > created by the webservice, I need to update my local user to add a > property with the external user id. How can I do that in the same > transaction? > I'm trying to set the property on the managed delegate user model, but > it has no effect. > > Thank you! > > On 9 Dec 2015 18:39, "Marek Posolda" > wrote: > > On 09/12/15 19:33, Jorge M. wrote: >> >> I'm developing a custom federation that communicates with my user >> repository via webservices. >> Probably this is a very strange scenario for a federation but >> that's the unique way that I have to communicate with the repository. >> >> My problem is that, as the webservices only exposes methods such >> as createUser and updateUser, I'm having problems with >> registrations and user profile updates because I'm not being able >> to do atomic calls to the webservice methods, with all the >> information that I need. >> >> As far as I know, from the properties file example and from the >> ldap federation source (probably I'm missing something) it seems >> that the federation api is intended to update and sync attribute >> by attribute (Keycloak <-> Federation). >> Am i wrong? Do you suggest another approach? Should I give up >> from having a federation that uses a webservice? >> > You can use "transaction wrapper", which will allow you to store > all the updates to user locally, but send the UPDATE request to > your webservice later at transaction commit time. You may need to > create custom transaction and enlist it with Keycloak > TransactionManager. > > This is what we have for LDAP federation provider right now. See > TxAwareLDAPUserModelDelegate. > > Marek >> >> Thank you. >> >> >> >> _______________________________________________ >> 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 Developer Portal Engineering Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151211/3e4feea7/attachment.html From mposolda at redhat.com Fri Dec 11 06:19:19 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 11 Dec 2015 12:19:19 +0100 Subject: [keycloak-dev] Custom federation - webservice In-Reply-To: <566A9C53.1080401@redhat.com> References: <5668755C.6040500@redhat.com> <566A9C53.1080401@redhat.com> Message-ID: <566AB137.3050107@redhat.com> I think what we can possibly do is: 1) Improve KeycloakTransactionManager to allow enlist with "priority" . Instead of methods: void enlist(KeycloakTransaction transaction); void enlistAfterCompletion(KeycloakTransaction transaction); we will have single method: void enlist(KeycloakTransaction transaction, int priority); By default, JPA will enlist transaction with priority 10 and infinispan with priority 20 or something like that. This change will allow to enlist your transaction in your FederationProvider with exact priority. So you can choose whether the commit will happen before JPA commit, or after JPA commit or even after infinispan commit etc. 2) Make TxAwareLDAPUserModelDelegate class more generic and reusable for other federation providers Marek On 11/12/15 10:50, Vlastimil Elias wrote: > Hi, > > I use similar approach and problem is (at least I think) that local DB > transaction is already commited when our code runs. It has two > negative effects: > - if remote service call is successful you are not able to write > anything locally as Jorge mentioned > - if remote service call fails local DB record is commited already and > it is hard to implement correct error handling > > So I think User Federation SPI should be extended by exact method > which allows atomic call of backend during user creation or update > before local transaction is commited. I already created issue for it > but not resolved yet https://issues.jboss.org/browse/KEYCLOAK-1075 > > Vlastimil > > On 10.12.2015 18:49, Jorge M. wrote: >> >> Hi, >> >> I think I'm in the right track now. I'm being able to call the >> webservice before commit. However, when the user is sucessfully >> created by the webservice, I need to update my local user to add a >> property with the external user id. How can I do that in the same >> transaction? >> I'm trying to set the property on the managed delegate user model, >> but it has no effect. >> >> Thank you! >> >> On 9 Dec 2015 18:39, "Marek Posolda" wrote: >> >> On 09/12/15 19:33, Jorge M. wrote: >>> >>> I'm developing a custom federation that communicates with my >>> user repository via webservices. >>> Probably this is a very strange scenario for a federation but >>> that's the unique way that I have to communicate with the >>> repository. >>> >>> My problem is that, as the webservices only exposes methods such >>> as createUser and updateUser, I'm having problems with >>> registrations and user profile updates because I'm not being >>> able to do atomic calls to the webservice methods, with all the >>> information that I need. >>> >>> As far as I know, from the properties file example and from the >>> ldap federation source (probably I'm missing something) it seems >>> that the federation api is intended to update and sync attribute >>> by attribute (Keycloak <-> Federation). >>> Am i wrong? Do you suggest another approach? Should I give up >>> from having a federation that uses a webservice? >>> >> You can use "transaction wrapper", which will allow you to store >> all the updates to user locally, but send the UPDATE request to >> your webservice later at transaction commit time. You may need to >> create custom transaction and enlist it with Keycloak >> TransactionManager. >> >> This is what we have for LDAP federation provider right now. See >> TxAwareLDAPUserModelDelegate. >> >> Marek >>> >>> Thank you. >>> >>> >>> >>> _______________________________________________ >>> 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 > Developer Portal Engineering 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/20151211/cebd1857/attachment-0001.html From velias at redhat.com Fri Dec 11 07:15:12 2015 From: velias at redhat.com (Vlastimil Elias) Date: Fri, 11 Dec 2015 13:15:12 +0100 Subject: [keycloak-dev] Custom federation - webservice In-Reply-To: <566AB137.3050107@redhat.com> References: <5668755C.6040500@redhat.com> <566A9C53.1080401@redhat.com> <566AB137.3050107@redhat.com> Message-ID: <566ABE50.8020606@redhat.com> On 11.12.2015 12:19, Marek Posolda wrote: > I think what we can possibly do is: > > 1) Improve KeycloakTransactionManager to allow enlist with "priority" > . Instead of methods: > > void enlist(KeycloakTransaction transaction); > void enlistAfterCompletion(KeycloakTransaction transaction); > > we will have single method: > > void enlist(KeycloakTransaction transaction, int priority); > > By default, JPA will enlist transaction with priority 10 and > infinispan with priority 20 or something like that. > > This change will allow to enlist your transaction in your > FederationProvider with exact priority. So you can choose whether the > commit will happen before JPA commit, or after JPA commit or even > after infinispan commit etc. > +1, this may help to resolve current problems > 2) Make TxAwareLDAPUserModelDelegate class more generic and reusable > for other federation providers may also help, but point 1 with correct documentation is main what we have to do Thanks Vlastimil > > Marek > > On 11/12/15 10:50, Vlastimil Elias wrote: >> Hi, >> >> I use similar approach and problem is (at least I think) that local >> DB transaction is already commited when our code runs. It has two >> negative effects: >> - if remote service call is successful you are not able to write >> anything locally as Jorge mentioned >> - if remote service call fails local DB record is commited already >> and it is hard to implement correct error handling >> >> So I think User Federation SPI should be extended by exact method >> which allows atomic call of backend during user creation or update >> before local transaction is commited. I already created issue for it >> but not resolved yet https://issues.jboss.org/browse/KEYCLOAK-1075 >> >> Vlastimil >> >> On 10.12.2015 18:49, Jorge M. wrote: >>> >>> Hi, >>> >>> I think I'm in the right track now. I'm being able to call the >>> webservice before commit. However, when the user is sucessfully >>> created by the webservice, I need to update my local user to add a >>> property with the external user id. How can I do that in the same >>> transaction? >>> I'm trying to set the property on the managed delegate user model, >>> but it has no effect. >>> >>> Thank you! >>> >>> On 9 Dec 2015 18:39, "Marek Posolda" wrote: >>> >>> On 09/12/15 19:33, Jorge M. wrote: >>>> >>>> I'm developing a custom federation that communicates with my >>>> user repository via webservices. >>>> Probably this is a very strange scenario for a federation but >>>> that's the unique way that I have to communicate with the >>>> repository. >>>> >>>> My problem is that, as the webservices only exposes methods >>>> such as createUser and updateUser, I'm having problems with >>>> registrations and user profile updates because I'm not being >>>> able to do atomic calls to the webservice methods, with all the >>>> information that I need. >>>> >>>> As far as I know, from the properties file example and from the >>>> ldap federation source (probably I'm missing something) it >>>> seems that the federation api is intended to update and sync >>>> attribute by attribute (Keycloak <-> Federation). >>>> Am i wrong? Do you suggest another approach? Should I give up >>>> from having a federation that uses a webservice? >>>> >>> You can use "transaction wrapper", which will allow you to store >>> all the updates to user locally, but send the UPDATE request to >>> your webservice later at transaction commit time. You may need >>> to create custom transaction and enlist it with Keycloak >>> TransactionManager. >>> >>> This is what we have for LDAP federation provider right now. See >>> TxAwareLDAPUserModelDelegate. >>> >>> Marek >>>> >>>> Thank you. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> Developer Portal Engineering Team >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Vlastimil Elias Principal Software Engineer Developer Portal Engineering Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151211/e69aa8c5/attachment.html From bburke at redhat.com Fri Dec 11 11:11:45 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 11 Dec 2015 11:11:45 -0500 Subject: [keycloak-dev] had to bump surefire memory Message-ID: <566AF5C1.9080905@redhat.com> My build was running really really slow. Bumping the heap and permgen for surefire seemed to fix the problem. Its probably either the server starting/stopping so much and not fully cleaning itself up after a stop, and/or we have a lot of open JAX-RS clients Apache Http Clients that aren't being closed from our tests, and/or selenium doesn't clean itself up nicely. Something we might want to look into later. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Sun Dec 13 14:16:46 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Sun, 13 Dec 2015 20:16:46 +0100 Subject: [keycloak-dev] Add custom REST paths? New SPI? In-Reply-To: <56686FCE.4020609@redhat.com> References: <565F017B.2000503@redhat.com> <565F1669.8030905@redhat.com> <565F3053.6050208@redhat.com> <565F3149.3030401@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C6@DDPEX01.DDP.dcloud.local> <245367499.29937698.1449500584163.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668FD6C@DDPEX01.DDP.dcloud.local> <1396421146.30256013.1449523077000.JavaMail.zimbra@redhat.com> <9A5619B792BBA041AE094585791BB71C0137B668B0C8@DDPEX01.DDP.dcloud.local> <10BA57B3-9278-48D5-9CB1-DDCB2DB35505@thesoftwarecottage.com.au> <9A5619B792BBA041AE094585791BB71C0137B668B0C9@DDPEX01.DDP.dcloud.local> <56683BCA.60808@redhat.com> <56686FCE.4020609@redhat.com> Message-ID: There's two issues here really: #1 KeycloakSession bound to a realm. Pretty much all requests with the exception to admin can take the realm from KeycloakContext. I'd like to extend that so realm can always be returned from KeycloakContext, which I think we will get to when we redo master realm stuff #2 Shorten/clean-up urls. Resources could in fact be realm specific. There could be different cache settings, or even different images etc for each realm. The fact that it's not ATM is more a limitation than anything. Version doesn't matter if it's avail under a realm or not really. I reckon dropping realms wouldn't just shorten the url, but also make things cleaner and simpler. On 9 Dec 2015 6:16 pm, "Marek Posolda" wrote: > +1 > > some things like ServerVersionResource or static resources ( keycloak.js > etc) are just not tight to any specific realm. Removing "/realms" would > mean that we will need to move all of them under the path specific to > some realm. For example move keycloak.js under > "http://localhost:8080/auth/foo/keycloak.js" . But that doesn't seem to > be very good practice as keycloak.js is not resource specific to realm > "foo" . > > If we want shorter and more user-memorable URLs, we can maybe introduce > some URLAliasService, where will people have possibility to define short > URL aliases for some endpoints. This might have support for regexes etc. > However Apache HTTPD already provides something like this AFAIK > > Marek > > > On 09/12/15 15:33, Bill Burke wrote: > > Once we go to host/{realms} we are stuck with it. The matching rules of > > JAX-RS will prevent us from adding any top level resource that is more > > specific. Stian, we might want to reconsider removing "/realms". > > > > On 12/8/2015 5:34 AM, Stian Thorgersen wrote: > >> 'admin' will probably move at some point to be under the realm. > >> > >> 'version' would move as well. Although this one should probably be > >> removed altogether. > >> > >> KeycloakSession and SPIs needs to be tied to a specific realm. This > >> makes everything cleaner. > >> > >> Besides it just doesn't make any sense to add arbitrary rest endpoints > >> to Keycloak. A rest endpoint should be tied to a realm, otherwise it > >> just doesn't make sense to host it on the Keycloak server. > >> > >> > >> > >> On 8 December 2015 at 11:18, Erik Mulder > >> >> > wrote: > >> > >> Stian, I can see your point. Using the realm name as the root level > >> certainly has advantages. It also really fixes everything to a > >> realm, but I guess that is what you want. So how about the current > >> ?/admin? url, how does that fit in the new picture? Because that > >> would be my next best target to hook into. Furthermore, there?s > >> currently a ?/version? root path that should end up somewhere else. > >> Personally, I think it?s not so bad to have a descriptive root > level > >> like ?realms?, which leaves open the possibility to add extra root > >> level paths, like meta data (version) or special contexts (admin, > >> customPath).____ > >> > >> __ __ > >> > >> __ __ > >> > >> *Van:*Stian Thorgersen [mailto:sthorger at redhat.com > >> ] > >> *Verzonden:* dinsdag 8 december 2015 10:32 > >> *Aan:* Greg Jones >> > > >> *CC:* Erik Mulder >> >; > >> keycloak-dev at lists.jboss.org > >> > >> > >> *Onderwerp:* Re: [keycloak-dev] Add custom REST paths? New SPI?____ > >> > >> __ __ > >> > >> -1 To adding rest endpoints to the root level. I'd like to get rid > >> of 'realms' part as some point and have all rest endpoints sit > >> underneath a realm. This makes sure the KeycloakSession always > knows > >> what realm is being handled, so we don't need to pass the realm > >> around as it can be retrived from the KeycloakContext. It also > means > >> that the url can be shortened as we can drop the 'realms' part.____ > >> > >> __ __ > >> > >> On 8 December 2015 at 10:22, Greg Jones > >> >> > wrote:____ > >> > >> +1 for these changes. We have been looking at a way to add > >> custom REST endpoints and would be happy to use this approach. > >> > >> Regards > >> Greg Jones____ > >> > >> > >> > >> > On 8 Dec 2015, at 8:17 PM, Erik Mulder > >> >> > wrote: > >> > > >> > Pedro's change (see below) is kindof what I was looking for, > >> but for my case and for general flexibility I think it's good > to > >> also have a more basic point to hook into the REST API's. > >> > I implemented and tested my own suggestion of having an SPI > >> to be able to add a REST resource at the root level. Combined > >> with the (coming) ability to freely extend the JPA entities and > >> DB schema, I think this creates a really powerful extensibility > >> to Keycloak. When we finish these changes, I can write a blog > >> post about what we did, why and how as a showcase for custom > >> extensions to Keycloak. > >> > > >> > So are the Keycloak dev's open to a PR with a new SPI that > >> enables you to add custom REST paths? > >> > For example, you could create something like: > >> > http://localhost:8080/auth/myPath/myResource > >> > > >> > > >> > -----Oorspronkelijk bericht----- > >> > Van: Pedro Igor Silva [mailto:psilva at redhat.com > >> ] > >> > Verzonden: maandag 7 december 2015 22:18 > >> > Aan: Erik Mulder >> > > >> > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New > SPI? > >> > > >> > It is part of a working in progress around fine-grained > >> authorization [1]. > >> > > >> > The new SPI changes [2] specific to Keycloak are located in > a > >> specific branch [3] in my Keycloak fork. > >> > > >> > I need to discuss these changes with Bill and see what he > >> thinks about it. Depending on his feedback, I can prepare a PR > >> and send these changes to upstream. > >> > > >> > [1] https://github.com/pedroigor/keycloak-authz > >> > [2] > >> > https://github.com/pedroigor/keycloak/commit/5e99614aacb70f7840a5ae25cfeaf3fc9d74ac54 > >> > [3] > >> > https://github.com/pedroigor/keycloak/tree/keycloak-authz-modified > >> > > >> > Regards. > >> > > >> > ----- Original Message ----- > >> > From: "Erik Mulder" >> > > >> > To: "Pedro Igor Silva" >> > > >> > Sent: Monday, December 7, 2015 5:51:26 PM > >> > Subject: RE: [keycloak-dev] Add custom REST paths? New SPI? > >> > > >> > Great, that's probably all we need! > >> > I'd like to try it out, but I cannot find any reference to > >> what you mention on Github. Is it (going to be) a pull request? > >> Is it going to be part of a future release? > >> > Can you point me to / provide me with these changes so I can > >> give it a spin? Thanks! > >> > > >> > ________________________________________ > >> > Van: Pedro Igor Silva [psilva at redhat.com > >> ] > >> > Verzonden: maandag 7 december 2015 16:03 > >> > Aan: Erik Mulder > >> > CC: keycloak-dev at lists.jboss.org > >> > >> > Onderwerp: Re: [keycloak-dev] Add custom REST paths? New > SPI? > >> > > >> > I've done something at this regard, where you can use a SPI > >> in order to plug additional APIs for: > >> > > >> > * Realm Admin RESTFul API (eg.: used by admin console) > >> > * Realm RESFTFul API (eg.: to plug additional endpoints > >> for realms) > >> > > >> > The two Provider interfaces are very simple and just provide > >> a single method: > >> > > >> > Object getResource(String pathName); > >> > > >> > Where pathName is the path that must be resolved to your > >> custom JAX-RS resource. > >> > > >> > The factories are also very simple and allows you to build > >> those resources for the current Realm and KeycloakSession. Eg.: > >> > > >> > RealmResourceProvider create(RealmModel realm, > >> KeycloakSession keycloakSession); > >> > > >> > Do you need something other than that ? > >> > > >> > Regards. > >> > Pedro Igor > >> > > >> > ----- Original Message ----- > >> > From: "Erik Mulder" >> > > >> > To: keycloak-dev at lists.jboss.org > >> > >> > Sent: Monday, December 7, 2015 12:46:39 PM > >> > Subject: [keycloak-dev] Add custom REST paths? New SPI? > >> > > >> > As some of you might know, our team is busy adding data to > >> the keycloak system to incorporate some custom authorization > >> information in the access token. > >> > So far we've successfully extended the JPA entities, > >> Liquibase table definitions and added a custom mapper to put > >> that data in the access token. All of this without custom > >> modifications to the original keycloak sources. This is working > >> great, thanks for the support so far! > >> > I know I've promised some PR's for this and they will come, > >> but first we'd like to get everything fully working, so we know > >> it's a well functioning whole. > >> > > >> > The last piece of the puzzle is extending the REST services > >> to include CRUD actions for our custom resources. I've been > >> looking into the way RESTEasy/JAX-RS works and it seems to me > >> that in the current implementation there is no way to add extra > >> paths. As I see it now, the KeycloakApplication class will > >> register some singletons in it's constructor and that's that. > No > >> way to extend or to 'interfere' there. > >> > > >> > So my question is: is there any 'official' way to add extra > >> REST paths to Keycloak? > >> > > >> > If not, is it an idea to add this as a new SPI? The current > >> code for adding root paths in the KeycloakApplication > >> constructor lists: > >> > > >> > singletons.add(new ServerVersionResource()); > >> > singletons.add(new RealmsResource()); > >> > singletons.add(new AdminRoot()); > >> > > >> > So just plain contructor calls. That seems like an easy > >> target for 'SPI-ing' :-). > >> > Or just leave the current ones 'hardcoded' and add an SPI > for > >> custom extensions. > >> > Your thoughts on this please. > >> > > >> > As before, I'm happy to implement this myself, but I'd like > >> to discuss it first, so a future PR will be honored. > >> > > >> > > >> > _______________________________________________ > >> > 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 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/20151213/ef35d23c/attachment-0001.html From sss2174 at columbia.edu Sun Dec 13 14:30:13 2015 From: sss2174 at columbia.edu (sabir) Date: Sun, 13 Dec 2015 14:30:13 -0500 Subject: [keycloak-dev] keycloak authentication with session id instead of the token Message-ID: Hello, I am working on integration keycloak authentication and setting up authorization on endpoints in Dropwizard application. I've looked into existing project here: https://github.com/ahus1/keycloak-dropwizard-integration/ Also, I looked into https://github.com/keycloak/keycloak/blob/c9e0a7a97dd98b31836195df167684a42dae4d3c/services/src/main/java/org/keycloak/authentication/authenticators/browser/CookieAuthenticator.java I am able to authenticate by username/password or passing keycloak token. It is crucial for us to authenticate existing session without credentials or keycloak token. Does keycloak expose endpoints to authenticate via Cookie like: KEYCLOAK_SESSION, KEYCLOAK_IDENTITY and/or KEYCLOAK_STATE_CHECKER I'm not sure if this is the correct place for questions like these. Please direct me otherwise. Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151213/2326ddb1/attachment.html From prabhalar at yahoo.com Mon Dec 14 07:33:25 2015 From: prabhalar at yahoo.com (Raghuram Prabhala) Date: Mon, 14 Dec 2015 12:33:25 +0000 (UTC) Subject: [keycloak-dev] Use Cassandra as storage instead of MySQL and MongoDB In-Reply-To: <5667E58E.2000602@redhat.com> References: <5667E58E.2000602@redhat.com> Message-ID: <1117722656.656199.1450096405373.JavaMail.yahoo@mail.yahoo.com> There are some drivers (Kundera, Datanucleus, spring cassandra, Hibernate OGM etc) that apparently use JPA to NOSQL conversion that I tried earlier with one project but didn't have a good experience and had to replace the entire persistence layer. On the same subject, if I were to do that (replace Mongodb with Cassandra), where should I start? Thanks,Raghu From: Marek Posolda To: chanras.sun at jcamst.com; keycloak-dev at lists.jboss.org Sent: Wednesday, December 9, 2015 3:25 AM Subject: Re: [keycloak-dev] Use Cassandra as storage instead of MySQL and MongoDB On 09/12/15 06:35, chanras.sun at jcamst.com wrote: #yiv9340802711 #yiv9340802711 -- _filtered #yiv9340802711 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv9340802711 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv9340802711 {font-family:DaunPenh;panose-1:1 1 1 1 1 1 1 1 1 1;}#yiv9340802711 #yiv9340802711 p.yiv9340802711MsoNormal, #yiv9340802711 li.yiv9340802711MsoNormal, #yiv9340802711 div.yiv9340802711MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv9340802711 a:link, #yiv9340802711 span.yiv9340802711MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv9340802711 a:visited, #yiv9340802711 span.yiv9340802711MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv9340802711 span.yiv9340802711EmailStyle17 {color:windowtext;}#yiv9340802711 .yiv9340802711MsoChpDefault {} _filtered #yiv9340802711 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv9340802711 div.yiv9340802711WordSection1 {}#yiv9340802711 Hi, My core backend system use Cassandra and Elasticsearch, running on Wildfly 9. I need to change keycloak data store implementation to use Cassandra instead of MySQL and MongdoDB. You have already some existing users data in Cassandra? In that case, you can implement federation provider, so your users will be visible to Keycloak and imported into Keycloak internal storage. If you want to store all core model data in Cassandra (realms, users etc), we don't have support for that though. We have just JPA and Mongo support now. I wonder if you can't use JPA model to store data into Cassandra? I need also change login, sign up to fit with my web app. We have themes support. See documentation and examples. Marek What is the best way to change as I mentioned above? ? ? Best Regards, Sun Chanras _______________________________________________ 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/20151214/c129c747/attachment.html From bburke at redhat.com Mon Dec 14 10:52:18 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 14 Dec 2015 10:52:18 -0500 Subject: [keycloak-dev] wildfly adapter subsystem not compiling Message-ID: <566EE5B2.2020503@redhat.com> java.lang.UnsupportedClassVersionError: org/jboss/as/subsystem/test/AbstractSubsystemBaseTest : Unsupported major.minor version 52.0 I guess I have to upgrade to Java 1.8? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From jm85martins at gmail.com Mon Dec 14 11:15:33 2015 From: jm85martins at gmail.com (Jorge M.) Date: Mon, 14 Dec 2015 16:15:33 +0000 Subject: [keycloak-dev] Custom federation - webservice In-Reply-To: <566ABE50.8020606@redhat.com> References: <5668755C.6040500@redhat.com> <566A9C53.1080401@redhat.com> <566AB137.3050107@redhat.com> <566ABE50.8020606@redhat.com> Message-ID: I agree. I think that could solve these issues. Is that something that can go on a near release? Thank yoy On 11 Dec 2015 12:15, "Vlastimil Elias" wrote: > > > On 11.12.2015 12:19, Marek Posolda wrote: > > I think what we can possibly do is: > > 1) Improve KeycloakTransactionManager to allow enlist with "priority" . > Instead of methods: > > void enlist(KeycloakTransaction transaction); > void enlistAfterCompletion(KeycloakTransaction transaction); > > we will have single method: > > void enlist(KeycloakTransaction transaction, int priority); > > By default, JPA will enlist transaction with priority 10 and infinispan > with priority 20 or something like that. > > This change will allow to enlist your transaction in your > FederationProvider with exact priority. So you can choose whether the > commit will happen before JPA commit, or after JPA commit or even after > infinispan commit etc. > > > +1, this may help to resolve current problems > > 2) Make TxAwareLDAPUserModelDelegate class more generic and reusable for > other federation providers > > > may also help, but point 1 with correct documentation is main what we have > to do > > Thanks > > Vlastimil > > > Marek > > On 11/12/15 10:50, Vlastimil Elias wrote: > > Hi, > > I use similar approach and problem is (at least I think) that local DB > transaction is already commited when our code runs. It has two negative > effects: > - if remote service call is successful you are not able to write anything > locally as Jorge mentioned > - if remote service call fails local DB record is commited already and it > is hard to implement correct error handling > > So I think User Federation SPI should be extended by exact method which > allows atomic call of backend during user creation or update before local > transaction is commited. I already created issue for it but not resolved > yet https://issues.jboss.org/browse/KEYCLOAK-1075 > > Vlastimil > > On 10.12.2015 18:49, Jorge M. wrote: > > Hi, > > I think I'm in the right track now. I'm being able to call the webservice > before commit. However, when the user is sucessfully created by the > webservice, I need to update my local user to add a property with the > external user id. How can I do that in the same transaction? > I'm trying to set the property on the managed delegate user model, but it > has no effect. > > Thank you! > On 9 Dec 2015 18:39, "Marek Posolda" wrote: > >> On 09/12/15 19:33, Jorge M. wrote: >> >> I'm developing a custom federation that communicates with my user >> repository via webservices. >> Probably this is a very strange scenario for a federation but that's the >> unique way that I have to communicate with the repository. >> >> My problem is that, as the webservices only exposes methods such as >> createUser and updateUser, I'm having problems with registrations and user >> profile updates because I'm not being able to do atomic calls to the >> webservice methods, with all the information that I need. >> >> As far as I know, from the properties file example and from the ldap >> federation source (probably I'm missing something) it seems that the >> federation api is intended to update and sync attribute by attribute >> (Keycloak <-> Federation). >> Am i wrong? Do you suggest another approach? Should I give up from having >> a federation that uses a webservice? >> >> You can use "transaction wrapper", which will allow you to store all the >> updates to user locally, but send the UPDATE request to your webservice >> later at transaction commit time. You may need to create custom transaction >> and enlist it with Keycloak TransactionManager. >> >> This is what we have for LDAP federation provider right now. See >> TxAwareLDAPUserModelDelegate. >> >> Marek >> >> Thank you. >> >> >> _______________________________________________ >> 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 > > > -- > Vlastimil Elias > Principal Software Engineer > Developer Portal Engineering Team > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Vlastimil Elias > Principal Software Engineer > Developer Portal Engineering 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/20151214/ae1d18a3/attachment-0001.html From kunal at plivo.com Mon Dec 14 11:16:38 2015 From: kunal at plivo.com (Kunal K) Date: Mon, 14 Dec 2015 21:46:38 +0530 Subject: [keycloak-dev] Issue with salt value while importing user json Message-ID: Hi, I'm using the migration script to import my users with a new hash algorithm with the following command - bin/standalone.sh -Dkeycloak.migration.action=import -Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=keycloak-data However all my salt values get changed mid way during the whole operation and are stored (in the database) differently than what they should be. I checked the code and saw that the script expects the salt values to be base64 encoded. I tried encoding the salt to base64, but the same issue persists. Lastly I tried to update the salt in the database (postgres) directly using an UPDATE statement, which worked well. Another observation I made is that salt is a 'bytea' data type in postgres and is stored as a hex value. Is there some issue with the import script? I'll be happy to fix it if anyone points me in the right direction. -- *KUNAL KERKAR *| PRODUCT ENGINEER Plivo, Inc. 340 Pine St, San Francisco - 94104, USA Web: www.plivo.com | Twitter: @plivo , @tsudot Free Incoming SMS for All US Short Codes ? Get One Today!? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151214/1a21753c/attachment.html From bruno at abstractj.org Mon Dec 14 12:05:17 2015 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 14 Dec 2015 15:05:17 -0200 Subject: [keycloak-dev] Issue with salt value while importing user json In-Reply-To: References: Message-ID: Hi Kunal, could you please tell me which version are you trying? I would to try it locally here and see if I can reproduce the issue. On Mon, Dec 14, 2015 at 2:16 PM, Kunal K wrote: > Hi, > > I'm using the migration script to import my users with a new hash algorithm > with the following command - > > bin/standalone.sh -Dkeycloak.migration.action=import > -Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=keycloak-data > > However all my salt values get changed mid way during the whole operation > and are stored (in the database) differently than what they should be. I > checked the code and saw that the script expects the salt values to be > base64 encoded. I tried encoding the salt to base64, but the same issue > persists. > > Lastly I tried to update the salt in the database (postgres) directly using > an UPDATE statement, which worked well. Another observation I made is that > salt is a 'bytea' data type in postgres and is stored as a hex value. > > Is there some issue with the import script? I'll be happy to fix it if > anyone points me in the right direction. > > > -- > KUNAL KERKAR | PRODUCT ENGINEER > Plivo, Inc. 340 Pine St, San Francisco - 94104, USA > Web: www.plivo.com | Twitter: @plivo, @tsudot > > Free Incoming SMS for All US Short Codes ? Get One Today!? > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- - abstractj From kunal at plivo.com Mon Dec 14 12:08:25 2015 From: kunal at plivo.com (Kunal Kerkar) Date: Mon, 14 Dec 2015 22:38:25 +0530 Subject: [keycloak-dev] Issue with salt value while importing user json In-Reply-To: References: Message-ID: Hi Bruno, I'm trying out master. KUNAL | PRODUCT ENGINEER Plivo, Inc. 340 Pine St, San Francisco - 94104, USA > On Dec 14, 2015, at 22:35, Bruno Oliveira wrote: > > Hi Kunal, could you please tell me which version are you trying? I > would to try it locally here and see if I can reproduce the issue. > >> On Mon, Dec 14, 2015 at 2:16 PM, Kunal K wrote: >> Hi, >> >> I'm using the migration script to import my users with a new hash algorithm >> with the following command - >> >> bin/standalone.sh -Dkeycloak.migration.action=import >> -Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=keycloak-data >> >> However all my salt values get changed mid way during the whole operation >> and are stored (in the database) differently than what they should be. I >> checked the code and saw that the script expects the salt values to be >> base64 encoded. I tried encoding the salt to base64, but the same issue >> persists. >> >> Lastly I tried to update the salt in the database (postgres) directly using >> an UPDATE statement, which worked well. Another observation I made is that >> salt is a 'bytea' data type in postgres and is stored as a hex value. >> >> Is there some issue with the import script? I'll be happy to fix it if >> anyone points me in the right direction. >> >> >> -- >> KUNAL KERKAR | PRODUCT ENGINEER >> Plivo, Inc. 340 Pine St, San Francisco - 94104, USA >> Web: www.plivo.com | Twitter: @plivo, @tsudot >> >> Free Incoming SMS for All US Short Codes ? Get One Today!? >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > - abstractj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151214/f8c540d1/attachment.html From mposolda at redhat.com Mon Dec 14 15:21:00 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 14 Dec 2015 21:21:00 +0100 Subject: [keycloak-dev] Custom federation - webservice In-Reply-To: References: <5668755C.6040500@redhat.com> <566A9C53.1080401@redhat.com> <566AB137.3050107@redhat.com> <566ABE50.8020606@redhat.com> Message-ID: <566F24AC.4020904@redhat.com> I think yes. It should be quite easy to change the signature of KeycloakTransactionManager methods. Just waiting if other team members agree and then we can possibly change fix version of https://issues.jboss.org/browse/KEYCLOAK-1075 to 1.8 and do it for this release. Marek On 14/12/15 17:15, Jorge M. wrote: > > I agree. I think that could solve these issues. Is that something that > can go on a near release? > > Thank yoy > > On 11 Dec 2015 12:15, "Vlastimil Elias" > wrote: > > > > On 11.12.2015 12:19, Marek Posolda wrote: >> I think what we can possibly do is: >> >> 1) Improve KeycloakTransactionManager to allow enlist with >> "priority" . Instead of methods: >> >> void enlist(KeycloakTransaction transaction); >> void enlistAfterCompletion(KeycloakTransaction transaction); >> >> we will have single method: >> >> void enlist(KeycloakTransaction transaction, int priority); >> >> By default, JPA will enlist transaction with priority 10 and >> infinispan with priority 20 or something like that. >> >> This change will allow to enlist your transaction in your >> FederationProvider with exact priority. So you can choose whether >> the commit will happen before JPA commit, or after JPA commit or >> even after infinispan commit etc. >> > > +1, this may help to resolve current problems > >> 2) Make TxAwareLDAPUserModelDelegate class more generic and >> reusable for other federation providers > > may also help, but point 1 with correct documentation is main what > we have to do > > Thanks > > Vlastimil > >> >> Marek >> >> On 11/12/15 10:50, Vlastimil Elias wrote: >>> Hi, >>> >>> I use similar approach and problem is (at least I think) that >>> local DB transaction is already commited when our code runs. It >>> has two negative effects: >>> - if remote service call is successful you are not able to write >>> anything locally as Jorge mentioned >>> - if remote service call fails local DB record is commited >>> already and it is hard to implement correct error handling >>> >>> So I think User Federation SPI should be extended by exact >>> method which allows atomic call of backend during user creation >>> or update before local transaction is commited. I already >>> created issue for it but not resolved yet >>> https://issues.jboss.org/browse/KEYCLOAK-1075 >>> >>> Vlastimil >>> >>> On 10.12.2015 18:49, Jorge M. wrote: >>>> >>>> Hi, >>>> >>>> I think I'm in the right track now. I'm being able to call the >>>> webservice before commit. However, when the user is sucessfully >>>> created by the webservice, I need to update my local user to >>>> add a property with the external user id. How can I do that in >>>> the same transaction? >>>> I'm trying to set the property on the managed delegate user >>>> model, but it has no effect. >>>> >>>> Thank you! >>>> >>>> On 9 Dec 2015 18:39, "Marek Posolda" >>> > wrote: >>>> >>>> On 09/12/15 19:33, Jorge M. wrote: >>>>> >>>>> I'm developing a custom federation that communicates with >>>>> my user repository via webservices. >>>>> Probably this is a very strange scenario for a federation >>>>> but that's the unique way that I have to communicate with >>>>> the repository. >>>>> >>>>> My problem is that, as the webservices only exposes >>>>> methods such as createUser and updateUser, I'm having >>>>> problems with registrations and user profile updates >>>>> because I'm not being able to do atomic calls to the >>>>> webservice methods, with all the information that I need. >>>>> >>>>> As far as I know, from the properties file example and >>>>> from the ldap federation source (probably I'm missing >>>>> something) it seems that the federation api is intended to >>>>> update and sync attribute by attribute (Keycloak <-> >>>>> Federation). >>>>> Am i wrong? Do you suggest another approach? Should I give >>>>> up from having a federation that uses a webservice? >>>>> >>>> You can use "transaction wrapper", which will allow you to >>>> store all the updates to user locally, but send the UPDATE >>>> request to your webservice later at transaction commit >>>> time. You may need to create custom transaction and enlist >>>> it with Keycloak TransactionManager. >>>> >>>> This is what we have for LDAP federation provider right >>>> now. See TxAwareLDAPUserModelDelegate. >>>> >>>> Marek >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> Developer Portal Engineering Team >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- > Vlastimil Elias > Principal Software Engineer > Developer Portal Engineering 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/20151214/97d02a64/attachment-0001.html From mstrukel at redhat.com Mon Dec 14 15:59:33 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 14 Dec 2015 21:59:33 +0100 Subject: [keycloak-dev] wildfly adapter subsystem not compiling In-Reply-To: <566EE5B2.2020503@redhat.com> References: <566EE5B2.2020503@redhat.com> Message-ID: That's a side-effect of upgrading to Wildfly 10 which is built with Java 8. So now Keycloak also requires Java 8 to build. On Dec 14, 2015 4:52 PM, "Bill Burke" wrote: > java.lang.UnsupportedClassVersionError: > org/jboss/as/subsystem/test/AbstractSubsystemBaseTest : Unsupported > major.minor version 52.0 > > > I guess I have to upgrade to Java 1.8? > -- > 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/20151214/03446867/attachment.html From chanras.sun at jcamst.com Tue Dec 15 06:12:13 2015 From: chanras.sun at jcamst.com (chanras.sun at jcamst.com) Date: Tue, 15 Dec 2015 18:12:13 +0700 Subject: [keycloak-dev] Using Cassandra as storage backend, fully customize admin console Message-ID: <005401d13729$75276d40$5f7647c0$@jcamst.com> Dear Keycloak Team, Since my architecture is designed to be based on Cassandra for primary storage backend and ElasticSearch for search functionality. Where should I start, if I need to change code base of keycloak to use Cassandra and customize field required for login and registration. For example. I don't want to have "username" field in my registration page. We need only "firstName","lastName","email", "password", and "confirmPassword". I want to custome "keycloak-server.war" to fit with my application. Where can I get start to customize "keycloak-server.war". PS:Using Themes and SPI provide by keycloak is not enough to customize to fit my implementation. Best Regards, Sun Chanras -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151215/2bc7a897/attachment.html From jm85martins at gmail.com Tue Dec 15 07:02:44 2015 From: jm85martins at gmail.com (Jorge M.) Date: Tue, 15 Dec 2015 12:02:44 +0000 Subject: [keycloak-dev] Themes per client Message-ID: Is there any chance to configure login themes per client, instead of per realm? Basically I need to set a different login page for a mobile app client. The app client is not directly related with the other clients of my realm (different branding, name, logo, colors, etc), but it shares the user accounts. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151215/a8170f5e/attachment.html From bburke at redhat.com Tue Dec 15 09:51:34 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Dec 2015 09:51:34 -0500 Subject: [keycloak-dev] Themes per client In-Reply-To: References: Message-ID: <567028F6.20706@redhat.com> Not until sometime next year unless somebody wants to contribute it. Feature freeze in about 3-4 weeks as we prepare for productization. On 12/15/2015 7:02 AM, Jorge M. wrote: > Is there any chance to configure login themes per client, instead of per > realm? > Basically I need to set a different login page for a mobile app client. > The app client is not directly related with the other clients of my > realm (different branding, name, logo, colors, etc), but it shares the > user accounts. > > Thank you. > > > > _______________________________________________ > 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 Tue Dec 15 09:58:38 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Dec 2015 09:58:38 -0500 Subject: [keycloak-dev] Using Cassandra as storage backend, fully customize admin console In-Reply-To: <005401d13729$75276d40$5f7647c0$@jcamst.com> References: <005401d13729$75276d40$5f7647c0$@jcamst.com> Message-ID: <56702A9E.7070304@redhat.com> On 12/15/2015 6:12 AM, chanras.sun at jcamst.com wrote: > Dear Keycloak Team, > > Since my architecture is designed to be based on Cassandra for primary > storage backend and ElasticSearch for search functionality. > > Where should I start, if I need to change code base of keycloak to use > Cassandra and customize field required for login and registration. > Look at model/api, model/jpa, model/mongo to see how other databases are handled. > For example. I don?t want to have ?username? field in my registration > page. We need only ?firstName?,?lastName?,?email?, ?password?, and > ?confirmPassword?. > > I want to custome ?keycloak-server.war? to fit with my application. > We do not support cracking open the WAR. You are on your own. > Where can I get start to customize ?keycloak-server.war?. > > PS:Using Themes and SPI provide by keycloak is not enough to customize > to fit my implementation. > Why can't you use themes and SPI? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Dec 15 12:26:17 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Dec 2015 12:26:17 -0500 Subject: [keycloak-dev] client templates and default mappers Message-ID: <56704D39.6000600@redhat.com> What to do with default mappers and clients and client templates? When you create a client, it automatically adds default mappers for each protocol. Now with client teampltes, if you create a client and specify a client template when you create it, it will not add default mappers to the client. Sound like right behavior? When creating a client template, should efault mappers be added to the temaplte automatically? Or should the user have to manually add them? The mappers tab of a client will have a link "view template mappers" which will bring you to the template's mapper page. You will be able to add additional mappers to your client, but you will not be able to override a template's mappers. Sound cool enough? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Dec 15 12:34:49 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Dec 2015 12:34:49 -0500 Subject: [keycloak-dev] scope and client templates Message-ID: <56704F39.507@redhat.com> So, what to do about scope and client templates? Client templates could have "full scope allowed" or define a scope. A client would either click "full scope allowed" or it can add additional scoped roles. Sound ok? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bmngouda at gmail.com Tue Dec 15 14:16:19 2015 From: bmngouda at gmail.com (Bheemanagouda A) Date: Wed, 16 Dec 2015 00:46:19 +0530 Subject: [keycloak-dev] Need Help Message-ID: Hi All, I would like to contribute to the keycloack project, can someone please guide me. -- Regards, Bheeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151216/42b3bd7c/attachment.html From bburke at redhat.com Tue Dec 15 14:22:48 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Dec 2015 14:22:48 -0500 Subject: [keycloak-dev] Need Help In-Reply-To: References: Message-ID: <56706888.6070106@redhat.com> https://issues.jboss.org/projects/KEYCLOAK?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page On 12/15/2015 2:16 PM, Bheemanagouda A wrote: > Hi All, > > I would like to contribute to the keycloack project, can someone please > guide me. > > > -- > Regards, > Bheeman > > > _______________________________________________ > 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 patrykkacpergala at gmail.com Tue Dec 15 14:44:42 2015 From: patrykkacpergala at gmail.com (Patryk Gala) Date: Tue, 15 Dec 2015 20:44:42 +0100 Subject: [keycloak-dev] Need Help In-Reply-To: References: Message-ID: Hi, Me too. Bill, could you suggest easy task? This task seems to be good for start: Test-Examples-AdminClient https://issues.jboss.org/browse/KEYCLOAK-1656 I should create admin client project in https://github.com/keycloak/keycloak/tree/master/examples/demo-template or edit admin-access-app ? Thank you for the information. Patryk > > > 2015-12-15 20:16 GMT+01:00 Bheemanagouda A : > >> Hi All, >> >> I would like to contribute to the keycloack project, can someone please >> guide me. >> >> >> -- >> Regards, >> Bheeman >> >> _______________________________________________ >> 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/20151215/ff24b914/attachment-0001.html From mposolda at redhat.com Wed Dec 16 08:19:36 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 16 Dec 2015 14:19:36 +0100 Subject: [keycloak-dev] client templates and default mappers In-Reply-To: <56704D39.6000600@redhat.com> References: <56704D39.6000600@redhat.com> Message-ID: <567164E8.2090604@redhat.com> On 15/12/15 18:26, Bill Burke wrote: > What to do with default mappers and clients and client templates? > > When you create a client, it automatically adds default mappers for each > protocol. Now with client teampltes, if you create a client and specify > a client template when you create it, it will not add default mappers to > the client. Sound like right behavior? IMO yes. This also adds possibility that your client will be created with some builtin mappers removed by default. > > When creating a client template, should efault mappers be added to the > temaplte automatically? Or should the user have to manually add them? IMO it's better if he needs to manually add them. He can already add builtin mappers very easily if he wants to, so doesn't sound like usability issue that default mappers are not there. > > The mappers tab of a client will have a link "view template mappers" > which will bring you to the template's mapper page. You will be able to > add additional mappers to your client, but you will not be able to > override a template's mappers. > > Sound cool enough? > I think yes. Another possibility is that on client setup, there will be list of checkboxes with mappers inherited from the parent. And all the checkboxes (mappers) will be checked by default. Admin has possibility to uncheck some inherited mappers. That adds possibility for admin to remove some inherited mappers. Is it sufficient to support just one client template for client? I guess yes, but not sure... Marek From mposolda at redhat.com Wed Dec 16 08:22:12 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 16 Dec 2015 14:22:12 +0100 Subject: [keycloak-dev] scope and client templates In-Reply-To: <56704F39.507@redhat.com> References: <56704F39.507@redhat.com> Message-ID: <56716584.8060502@redhat.com> On 15/12/15 18:34, Bill Burke wrote: > So, what to do about scope and client templates? Client templates could > have "full scope allowed" or define a scope. A client would either > click "full scope allowed" or it can add additional scoped roles. > > Sound ok? > yes to me. I suppose each client will still automatically receives his own client roles to the scope like it's now. Marek From sthorger at redhat.com Thu Dec 17 03:37:55 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 09:37:55 +0100 Subject: [keycloak-dev] Themes per client In-Reply-To: <567028F6.20706@redhat.com> References: <567028F6.20706@redhat.com> Message-ID: It doesn't make sense to add this. For mobile phones responsive design should be used, instead of designing completely different themes. If you want to go further with different branding, etc.. then we'd also need a way to have different SSO "domains" or something within a realm. It doesn't make sense to have SSO with different logins to the same SSO "domain". On 15 December 2015 at 15:51, Bill Burke wrote: > Not until sometime next year unless somebody wants to contribute it. > Feature freeze in about 3-4 weeks as we prepare for productization. > > On 12/15/2015 7:02 AM, Jorge M. wrote: > > Is there any chance to configure login themes per client, instead of per > > realm? > > Basically I need to set a different login page for a mobile app client. > > The app client is not directly related with the other clients of my > > realm (different branding, name, logo, colors, etc), but it shares the > > user accounts. > > > > Thank you. > > > > > > > > _______________________________________________ > > 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/20151217/f7af8e0f/attachment.html From sthorger at redhat.com Thu Dec 17 03:50:20 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 09:50:20 +0100 Subject: [keycloak-dev] Custom federation - webservice In-Reply-To: <566F24AC.4020904@redhat.com> References: <5668755C.6040500@redhat.com> <566A9C53.1080401@redhat.com> <566AB137.3050107@redhat.com> <566ABE50.8020606@redhat.com> <566F24AC.4020904@redhat.com> Message-ID: I guess in certain situations this can be helpful. It doesn't solve the problem though so we need something smarter at some point, but we don't have the time to do it right now so would have to be for 2.x. On 14 December 2015 at 21:21, Marek Posolda wrote: > I think yes. It should be quite easy to change the signature of > KeycloakTransactionManager methods. Just waiting if other team members > agree and then we can possibly change fix version of > https://issues.jboss.org/browse/KEYCLOAK-1075 to 1.8 and do it for this > release. > > Marek > > > On 14/12/15 17:15, Jorge M. wrote: > > I agree. I think that could solve these issues. Is that something that can > go on a near release? > > Thank yoy > On 11 Dec 2015 12:15, "Vlastimil Elias" wrote: > >> >> >> On 11.12.2015 12:19, Marek Posolda wrote: >> >> I think what we can possibly do is: >> >> 1) Improve KeycloakTransactionManager to allow enlist with "priority" . >> Instead of methods: >> >> void enlist(KeycloakTransaction transaction); >> void enlistAfterCompletion(KeycloakTransaction transaction); >> >> we will have single method: >> >> void enlist(KeycloakTransaction transaction, int priority); >> >> By default, JPA will enlist transaction with priority 10 and infinispan >> with priority 20 or something like that. >> >> This change will allow to enlist your transaction in your >> FederationProvider with exact priority. So you can choose whether the >> commit will happen before JPA commit, or after JPA commit or even after >> infinispan commit etc. >> >> >> +1, this may help to resolve current problems >> >> 2) Make TxAwareLDAPUserModelDelegate class more generic and reusable for >> other federation providers >> >> >> may also help, but point 1 with correct documentation is main what we >> have to do >> >> Thanks >> >> Vlastimil >> >> >> Marek >> >> On 11/12/15 10:50, Vlastimil Elias wrote: >> >> Hi, >> >> I use similar approach and problem is (at least I think) that local DB >> transaction is already commited when our code runs. It has two negative >> effects: >> - if remote service call is successful you are not able to write anything >> locally as Jorge mentioned >> - if remote service call fails local DB record is commited already and it >> is hard to implement correct error handling >> >> So I think User Federation SPI should be extended by exact method which >> allows atomic call of backend during user creation or update before local >> transaction is commited. I already created issue for it but not resolved >> yet https://issues.jboss.org/browse/KEYCLOAK-1075 >> >> Vlastimil >> >> On 10.12.2015 18:49, Jorge M. wrote: >> >> Hi, >> >> I think I'm in the right track now. I'm being able to call the webservice >> before commit. However, when the user is sucessfully created by the >> webservice, I need to update my local user to add a property with the >> external user id. How can I do that in the same transaction? >> I'm trying to set the property on the managed delegate user model, but it >> has no effect. >> >> Thank you! >> On 9 Dec 2015 18:39, "Marek Posolda" wrote: >> >>> On 09/12/15 19:33, Jorge M. wrote: >>> >>> I'm developing a custom federation that communicates with my user >>> repository via webservices. >>> Probably this is a very strange scenario for a federation but that's the >>> unique way that I have to communicate with the repository. >>> >>> My problem is that, as the webservices only exposes methods such as >>> createUser and updateUser, I'm having problems with registrations and user >>> profile updates because I'm not being able to do atomic calls to the >>> webservice methods, with all the information that I need. >>> >>> As far as I know, from the properties file example and from the ldap >>> federation source (probably I'm missing something) it seems that the >>> federation api is intended to update and sync attribute by attribute >>> (Keycloak <-> Federation). >>> Am i wrong? Do you suggest another approach? Should I give up from >>> having a federation that uses a webservice? >>> >>> You can use "transaction wrapper", which will allow you to store all the >>> updates to user locally, but send the UPDATE request to your webservice >>> later at transaction commit time. You may need to create custom transaction >>> and enlist it with Keycloak TransactionManager. >>> >>> This is what we have for LDAP federation provider right now. See >>> TxAwareLDAPUserModelDelegate. >>> >>> Marek >>> >>> Thank you. >>> >>> >>> _______________________________________________ >>> 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 >> >> >> -- >> Vlastimil Elias >> Principal Software Engineer >> Developer Portal Engineering Team >> >> >> >> _______________________________________________ >> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> -- >> Vlastimil Elias >> Principal Software Engineer >> Developer Portal Engineering Team >> >> >> _______________________________________________ >> 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/20151217/fcf87f1f/attachment-0001.html From sthorger at redhat.com Thu Dec 17 03:52:58 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 09:52:58 +0100 Subject: [keycloak-dev] client templates and default mappers In-Reply-To: <56704D39.6000600@redhat.com> References: <56704D39.6000600@redhat.com> Message-ID: On 15 December 2015 at 18:26, Bill Burke wrote: > What to do with default mappers and clients and client templates? > > When you create a client, it automatically adds default mappers for each > protocol. Now with client teampltes, if you create a client and specify > a client template when you create it, it will not add default mappers to > the client. Sound like right behavior? > Yes > > When creating a client template, should efault mappers be added to the > temaplte automatically? Or should the user have to manually add them? > Add default mappers. It's easier for users to modify a sensible starting point than starting from scratch. > > The mappers tab of a client will have a link "view template mappers" > which will bring you to the template's mapper page. You will be able to > add additional mappers to your client, but you will not be able to > override a template's mappers. > > Sound cool enough? > Yep > > -- > 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/20151217/aec697fe/attachment.html From sthorger at redhat.com Thu Dec 17 03:54:55 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 09:54:55 +0100 Subject: [keycloak-dev] client templates and default mappers In-Reply-To: <567164E8.2090604@redhat.com> References: <56704D39.6000600@redhat.com> <567164E8.2090604@redhat.com> Message-ID: On 16 December 2015 at 14:19, Marek Posolda wrote: > On 15/12/15 18:26, Bill Burke wrote: > > What to do with default mappers and clients and client templates? > > > > When you create a client, it automatically adds default mappers for each > > protocol. Now with client teampltes, if you create a client and specify > > a client template when you create it, it will not add default mappers to > > the client. Sound like right behavior? > IMO yes. This also adds possibility that your client will be created > with some builtin mappers removed by default. > > > > When creating a client template, should efault mappers be added to the > > temaplte automatically? Or should the user have to manually add them? > IMO it's better if he needs to manually add them. He can already add > builtin mappers very easily if he wants to, so doesn't sound like > usability issue that default mappers are not there. > > > > The mappers tab of a client will have a link "view template mappers" > > which will bring you to the template's mapper page. You will be able to > > add additional mappers to your client, but you will not be able to > > override a template's mappers. > > > > Sound cool enough? > > > I think yes. > > Another possibility is that on client setup, there will be list of > checkboxes with mappers inherited from the parent. And all the > checkboxes (mappers) will be checked by default. Admin has possibility > to uncheck some inherited mappers. That adds possibility for admin to > remove some inherited mappers. > > Is it sufficient to support just one client template for client? I guess > yes, but not sure... > Client templates would be useful when there's a set of standard claims that a group of clients expects in a token. Allowing individual clients to add/remove/override those standard claims makes little sense. I also don't think there's a need for a client to be able to inherit from multiple templates. > > 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/20151217/e69c5530/attachment.html From sthorger at redhat.com Thu Dec 17 03:58:11 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 09:58:11 +0100 Subject: [keycloak-dev] scope and client templates In-Reply-To: <56716584.8060502@redhat.com> References: <56704F39.507@redhat.com> <56716584.8060502@redhat.com> Message-ID: Not sure we even need scope in client templates? Isn't it sufficient to only have scope control on a per-client? For example say there's 3 clients in a group of clients: * service - user and admin roles * user console * admin console You don't want the user console to have scope on the admin console just because it's in the same group. Also, you don't want the service to have any scope. Can anyone come up with an example where scope on the client template would be useful? On 16 December 2015 at 14:22, Marek Posolda wrote: > On 15/12/15 18:34, Bill Burke wrote: > > So, what to do about scope and client templates? Client templates could > > have "full scope allowed" or define a scope. A client would either > > click "full scope allowed" or it can add additional scoped roles. > > > > Sound ok? > > > yes to me. I suppose each client will still automatically receives his > own client roles to the scope like it's now. > > 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/20151217/24f5b6d7/attachment.html From mposolda at redhat.com Thu Dec 17 05:39:42 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 17 Dec 2015 11:39:42 +0100 Subject: [keycloak-dev] scope and client templates In-Reply-To: References: <56704F39.507@redhat.com> <56716584.8060502@redhat.com> Message-ID: <567290EE.3090301@redhat.com> If I understand correctly, to the template you put just scopes, which you want to be shared for all clients. You can add additional scopes per client if needed. Example where it can be useful: You want that each accessToken will contain all realm roles + all client roles of the client who issued it. So: - you add all realm roles to the client template scope - accessToken issued for clientA will contain all realm roles and all client roles of clientA - accessToken issued for clientB will contain all realm roles and all client roles of clientB In your example, you don't want any scope to be "shared", so there won't be any scope defined on template and both "user console" and "admin console" will have just their own scopes. Marek On 17/12/15 09:58, Stian Thorgersen wrote: > Not sure we even need scope in client templates? Isn't it sufficient > to only have scope control on a per-client? > > For example say there's 3 clients in a group of clients: > * service - user and admin roles > * user console > * admin console > > You don't want the user console to have scope on the admin console > just because it's in the same group. Also, you don't want the service > to have any scope. > > Can anyone come up with an example where scope on the client template > would be useful? > > On 16 December 2015 at 14:22, Marek Posolda > wrote: > > On 15/12/15 18:34, Bill Burke wrote: > > So, what to do about scope and client templates? Client > templates could > > have "full scope allowed" or define a scope. A client would either > > click "full scope allowed" or it can add additional scoped roles. > > > > Sound ok? > > > yes to me. I suppose each client will still automatically receives his > own client roles to the scope like it's now. > > 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/20151217/eb0003cf/attachment.html From sthorger at redhat.com Thu Dec 17 05:42:13 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 11:42:13 +0100 Subject: [keycloak-dev] scope and client templates In-Reply-To: <567290EE.3090301@redhat.com> References: <56704F39.507@redhat.com> <56716584.8060502@redhat.com> <567290EE.3090301@redhat.com> Message-ID: That's not a real example though. I just don't see a real use case where all clients in a group (app and services) wants to have the same scope. Scope if highly client specific. On 17 December 2015 at 11:39, Marek Posolda wrote: > If I understand correctly, to the template you put just scopes, which you > want to be shared for all clients. You can add additional scopes per client > if needed. > > Example where it can be useful: You want that each accessToken will > contain all realm roles + all client roles of the client who issued it. So: > - you add all realm roles to the client template scope > - accessToken issued for clientA will contain all realm roles and all > client roles of clientA > - accessToken issued for clientB will contain all realm roles and all > client roles of clientB > > In your example, you don't want any scope to be "shared", so there won't > be any scope defined on template and both "user console" and "admin > console" will have just their own scopes. > > Marek > > > On 17/12/15 09:58, Stian Thorgersen wrote: > > Not sure we even need scope in client templates? Isn't it sufficient to > only have scope control on a per-client? > > For example say there's 3 clients in a group of clients: > * service - user and admin roles > * user console > * admin console > > You don't want the user console to have scope on the admin console just > because it's in the same group. Also, you don't want the service to have > any scope. > > Can anyone come up with an example where scope on the client template > would be useful? > > On 16 December 2015 at 14:22, Marek Posolda wrote: > >> On 15/12/15 18:34, Bill Burke wrote: >> > So, what to do about scope and client templates? Client templates could >> > have "full scope allowed" or define a scope. A client would either >> > click "full scope allowed" or it can add additional scoped roles. >> > >> > Sound ok? >> > >> yes to me. I suppose each client will still automatically receives his >> own client roles to the scope like it's now. >> >> 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/20151217/b5eedbdd/attachment-0001.html From mposolda at redhat.com Thu Dec 17 06:24:23 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 17 Dec 2015 12:24:23 +0100 Subject: [keycloak-dev] scope and client templates In-Reply-To: References: <56704F39.507@redhat.com> <56716584.8060502@redhat.com> <567290EE.3090301@redhat.com> Message-ID: <56729B67.7040802@redhat.com> Why not real example? I can imagine that in some deployments, people have some set of "global" roles, which should be available in each access token issued to any client. I imagine that in most cases, all those global roles will be defined in same role namespace. So if we later have a way to specify: "I want all roles from namespace foo://global/* to be put to scope of clientX" that should be probably fine too. But IMO we need to avoid situation, when admin needs to manually add 50 global roles to the scope of each newly created client. Btv. I am not sure why service needs to be added to any client template? Service (bearer-only client) doesn't have it's own access token, so it doesn't need any shared protocol mappers or scopes. We already have both tabs "Mappers" and "Scopes" hidden from bearer-only clients. Shouldn't we also hide the "Client Template" from client settings of bearer-only client? Marek On 17/12/15 11:42, Stian Thorgersen wrote: > That's not a real example though. I just don't see a real use case > where all clients in a group (app and services) wants to have the same > scope. Scope if highly client specific. > > On 17 December 2015 at 11:39, Marek Posolda > wrote: > > If I understand correctly, to the template you put just scopes, > which you want to be shared for all clients. You can add > additional scopes per client if needed. > > Example where it can be useful: You want that each accessToken > will contain all realm roles + all client roles of the client who > issued it. So: > - you add all realm roles to the client template scope > - accessToken issued for clientA will contain all realm roles and > all client roles of clientA > - accessToken issued for clientB will contain all realm roles and > all client roles of clientB > > In your example, you don't want any scope to be "shared", so there > won't be any scope defined on template and both "user console" and > "admin console" will have just their own scopes. > > Marek > > > On 17/12/15 09:58, Stian Thorgersen wrote: >> Not sure we even need scope in client templates? Isn't it >> sufficient to only have scope control on a per-client? >> >> For example say there's 3 clients in a group of clients: >> * service - user and admin roles >> * user console >> * admin console >> >> You don't want the user console to have scope on the admin >> console just because it's in the same group. Also, you don't want >> the service to have any scope. >> >> Can anyone come up with an example where scope on the client >> template would be useful? >> >> On 16 December 2015 at 14:22, Marek Posolda > > wrote: >> >> On 15/12/15 18:34, Bill Burke wrote: >> > So, what to do about scope and client templates? Client >> templates could >> > have "full scope allowed" or define a scope. A client >> would either >> > click "full scope allowed" or it can add additional scoped >> roles. >> > >> > Sound ok? >> > >> yes to me. I suppose each client will still automatically >> receives his >> own client roles to the scope like it's now. >> >> 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/20151217/3a6cfca8/attachment.html From bburke at redhat.com Thu Dec 17 08:33:53 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 17 Dec 2015 08:33:53 -0500 Subject: [keycloak-dev] Themes per client In-Reply-To: References: <567028F6.20706@redhat.com> Message-ID: <5672B9C1.5070406@redhat.com> Makes sense so long as User-Agent headers are accurate. You still would want to create themes per User-Agent. On 12/17/2015 3:37 AM, Stian Thorgersen wrote: > It doesn't make sense to add this. For mobile phones responsive design > should be used, instead of designing completely different themes. If you > want to go further with different branding, etc.. then we'd also need a > way to have different SSO "domains" or something within a realm. It > doesn't make sense to have SSO with different logins to the same SSO > "domain". > > On 15 December 2015 at 15:51, Bill Burke > wrote: > > Not until sometime next year unless somebody wants to contribute it. > Feature freeze in about 3-4 weeks as we prepare for productization. > > On 12/15/2015 7:02 AM, Jorge M. wrote: > > Is there any chance to configure login themes per client, instead > of per > > realm? > > Basically I need to set a different login page for a mobile app > client. > > The app client is not directly related with the other clients of my > > realm (different branding, name, logo, colors, etc), but it > shares the > > user accounts. > > > > Thank you. > > > > > > > > _______________________________________________ > > 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 ssilvert at redhat.com Thu Dec 17 08:35:08 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 17 Dec 2015 08:35:08 -0500 Subject: [keycloak-dev] Tables in our Admin UI Message-ID: <5672BA0C.30703@redhat.com> I'd like to get feedback on our tables. For partial import, I have a summary table of what was imported and I need things like sorting, pagination, and maybe filtering. I looked at PatternFly's Table View[1], which would ideally be the way to go. The problem here is that it's based on jQuery/dataTable[2] and it's a bit problematic to get it working with Angular. It can be done, but I'm not seeing a good consensus on the best way to go about it. From what I've found so far, mixing jQuery/dataTable with Angular just doesn't look clean to me. I'm sure some of you have give a lot of thought to our tables already. Any ideas? [1] https://www.patternfly.org/patterns/table/ [2] http://datatables.net/ From bburke at redhat.com Thu Dec 17 08:37:13 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 17 Dec 2015 08:37:13 -0500 Subject: [keycloak-dev] client templates and default mappers In-Reply-To: References: <56704D39.6000600@redhat.com> <567164E8.2090604@redhat.com> Message-ID: <5672BA89.1060603@redhat.com> On 12/17/2015 3:54 AM, Stian Thorgersen wrote: > > > On 16 December 2015 at 14:19, Marek Posolda > wrote: > > On 15/12/15 18:26, Bill Burke wrote: > > What to do with default mappers and clients and client templates? > > > > When you create a client, it automatically adds default mappers for each > > protocol. Now with client teampltes, if you create a client and specify > > a client template when you create it, it will not add default mappers to > > the client. Sound like right behavior? > IMO yes. This also adds possibility that your client will be created > with some builtin mappers removed by default. > > > > When creating a client template, should efault mappers be added to the > > temaplte automatically? Or should the user have to manually add them? > IMO it's better if he needs to manually add them. He can already add > builtin mappers very easily if he wants to, so doesn't sound like > usability issue that default mappers are not there. > > > > The mappers tab of a client will have a link "view template mappers" > > which will bring you to the template's mapper page. You will be able to > > add additional mappers to your client, but you will not be able to > > override a template's mappers. > > > > Sound cool enough? > > > I think yes. > > Another possibility is that on client setup, there will be list of > checkboxes with mappers inherited from the parent. And all the > checkboxes (mappers) will be checked by default. Admin has possibility > to uncheck some inherited mappers. That adds possibility for admin to > remove some inherited mappers. > > Is it sufficient to support just one client template for client? I guess > yes, but not sure... > > > Client templates would be useful when there's a set of standard claims > that a group of clients expects in a token. Allowing individual clients > to add/remove/override those standard claims makes little sense. I also > don't think there's a need for a client to be able to inherit from > multiple templates. > Certainly makes sense for a client to be able to add additional claims. Removal and override are just too complicated to model in a UI and datamodel IMO. It *would* make things easier if a Client Template is specified for a client the client cannot change config, add scopes, or add mappers. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Thu Dec 17 08:39:10 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 17 Dec 2015 08:39:10 -0500 Subject: [keycloak-dev] scope and client templates In-Reply-To: References: <56704F39.507@redhat.com> <56716584.8060502@redhat.com> Message-ID: <5672BAFE.9060903@redhat.com> I don't think you've thought this through. Of course you would want scope on a client template. Client Template allows scope for Service A, Service B, and Service C. Client 1, Client 2, and Client 3 all need to access Service A, B, and C. You'd have to define scope in each client when it would be easier to define it in the client template. On 12/17/2015 3:58 AM, Stian Thorgersen wrote: > Not sure we even need scope in client templates? Isn't it sufficient to > only have scope control on a per-client? > > For example say there's 3 clients in a group of clients: > * service - user and admin roles > * user console > * admin console > > You don't want the user console to have scope on the admin console just > because it's in the same group. Also, you don't want the service to have > any scope. > > Can anyone come up with an example where scope on the client template > would be useful? > > On 16 December 2015 at 14:22, Marek Posolda > wrote: > > On 15/12/15 18:34, Bill Burke wrote: > > So, what to do about scope and client templates? Client templates could > > have "full scope allowed" or define a scope. A client would either > > click "full scope allowed" or it can add additional scoped roles. > > > > Sound ok? > > > yes to me. I suppose each client will still automatically receives his > own client roles to the scope like it's now. > > 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 sthorger at redhat.com Thu Dec 17 08:43:19 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 14:43:19 +0100 Subject: [keycloak-dev] Themes per client In-Reply-To: <5672B9C1.5070406@redhat.com> References: <567028F6.20706@redhat.com> <5672B9C1.5070406@redhat.com> Message-ID: On 17 December 2015 at 14:33, Bill Burke wrote: > Makes sense so long as User-Agent headers are accurate. You still would > want to create themes per User-Agent. Having separate websites for desktop, mobile, tablet, etc.. is so old school. These days folks do a responsive design that works well for all user-agents. > > > On 12/17/2015 3:37 AM, Stian Thorgersen wrote: > >> It doesn't make sense to add this. For mobile phones responsive design >> should be used, instead of designing completely different themes. If you >> want to go further with different branding, etc.. then we'd also need a >> way to have different SSO "domains" or something within a realm. It >> doesn't make sense to have SSO with different logins to the same SSO >> "domain". >> >> On 15 December 2015 at 15:51, Bill Burke > > wrote: >> >> Not until sometime next year unless somebody wants to contribute it. >> Feature freeze in about 3-4 weeks as we prepare for productization. >> >> On 12/15/2015 7:02 AM, Jorge M. wrote: >> > Is there any chance to configure login themes per client, instead >> of per >> > realm? >> > Basically I need to set a different login page for a mobile app >> client. >> > The app client is not directly related with the other clients of my >> > realm (different branding, name, logo, colors, etc), but it >> shares the >> > user accounts. >> > >> > Thank you. >> > >> > >> > >> > _______________________________________________ >> > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151217/d2e5c329/attachment-0001.html From sthorger at redhat.com Thu Dec 17 08:45:25 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 14:45:25 +0100 Subject: [keycloak-dev] Tables in our Admin UI In-Reply-To: <5672BA0C.30703@redhat.com> References: <5672BA0C.30703@redhat.com> Message-ID: I see absolutely no issue with making a table with Angular that follows the same pattern. We already have the search bit and pagination buttons, so it's simple to add to that. We're not using any JS library that's already packaged for Angular. So either find an alternative or do it manually. On 17 December 2015 at 14:35, Stan Silvert wrote: > I'd like to get feedback on our tables. For partial import, I have a > summary table of what was imported and I need things like sorting, > pagination, and maybe filtering. > > I looked at PatternFly's Table View[1], which would ideally be the way > to go. > > The problem here is that it's based on jQuery/dataTable[2] and it's a > bit problematic to get it working with Angular. It can be done, but I'm > not seeing a good consensus on the best way to go about it. From what > I've found so far, mixing jQuery/dataTable with Angular just doesn't > look clean to me. > > I'm sure some of you have give a lot of thought to our tables already. > Any ideas? > > [1] https://www.patternfly.org/patterns/table/ > [2] http://datatables.net/ > _______________________________________________ > 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/20151217/fe830f64/attachment.html From sthorger at redhat.com Thu Dec 17 08:45:56 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 14:45:56 +0100 Subject: [keycloak-dev] Tables in our Admin UI In-Reply-To: References: <5672BA0C.30703@redhat.com> Message-ID: On 17 December 2015 at 14:45, Stian Thorgersen wrote: > I see absolutely no issue with making a table with Angular that follows > the same pattern. We already have the search bit and pagination buttons, so > it's simple to add to that. > > We're not using any JS library that's already packaged for Angular. So > either find an alternative or do it manually. > We're not going to use any JS library that's not already packaged for Angular is what I meant > > > > On 17 December 2015 at 14:35, Stan Silvert wrote: > >> I'd like to get feedback on our tables. For partial import, I have a >> summary table of what was imported and I need things like sorting, >> pagination, and maybe filtering. >> >> I looked at PatternFly's Table View[1], which would ideally be the way >> to go. >> >> The problem here is that it's based on jQuery/dataTable[2] and it's a >> bit problematic to get it working with Angular. It can be done, but I'm >> not seeing a good consensus on the best way to go about it. From what >> I've found so far, mixing jQuery/dataTable with Angular just doesn't >> look clean to me. >> >> I'm sure some of you have give a lot of thought to our tables already. >> Any ideas? >> >> [1] https://www.patternfly.org/patterns/table/ >> [2] http://datatables.net/ >> _______________________________________________ >> 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/20151217/07cc640e/attachment.html From sthorger at redhat.com Thu Dec 17 08:47:51 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 14:47:51 +0100 Subject: [keycloak-dev] scope and client templates In-Reply-To: <5672BAFE.9060903@redhat.com> References: <56704F39.507@redhat.com> <56716584.8060502@redhat.com> <5672BAFE.9060903@redhat.com> Message-ID: On 17 December 2015 at 14:39, Bill Burke wrote: > I don't think you've thought this through. Of course you would want scope > on a client template. > > Client Template allows scope for Service A, Service B, and Service C. > > Client 1, Client 2, and Client 3 all need to access Service A, B, and C. > You'd have to define scope in each client when it would be easier to define > it in the client template. I have thought it through - I just think that it's a lot more likely that Client 1 will invoke Service A, Client 2 will invoke Service B. Even if all clients invoke all services they will not have the same scope, but different scope. > > > On 12/17/2015 3:58 AM, Stian Thorgersen wrote: > >> Not sure we even need scope in client templates? Isn't it sufficient to >> only have scope control on a per-client? >> >> For example say there's 3 clients in a group of clients: >> * service - user and admin roles >> * user console >> * admin console >> >> You don't want the user console to have scope on the admin console just >> because it's in the same group. Also, you don't want the service to have >> any scope. >> >> Can anyone come up with an example where scope on the client template >> would be useful? >> >> On 16 December 2015 at 14:22, Marek Posolda > > wrote: >> >> On 15/12/15 18:34, Bill Burke wrote: >> > So, what to do about scope and client templates? Client templates >> could >> > have "full scope allowed" or define a scope. A client would either >> > click "full scope allowed" or it can add additional scoped roles. >> > >> > Sound ok? >> > >> yes to me. I suppose each client will still automatically receives his >> own client roles to the scope like it's now. >> >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151217/9cc305a7/attachment.html From bburke at redhat.com Thu Dec 17 08:48:29 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 17 Dec 2015 08:48:29 -0500 Subject: [keycloak-dev] Themes per client In-Reply-To: References: <567028F6.20706@redhat.com> <5672B9C1.5070406@redhat.com> Message-ID: <5672BD2D.5010701@redhat.com> On 12/17/2015 8:43 AM, Stian Thorgersen wrote: > > > On 17 December 2015 at 14:33, Bill Burke > wrote: > > Makes sense so long as User-Agent headers are accurate. You still > would want to create themes per User-Agent. > > > Having separate websites for desktop, mobile, tablet, etc.. is so old > school. These days folks do a responsive design that works well for all > user-agents. > I really don't have the experience to argue with you, but are you sure? Are you sure this "responsive design" isn't just a fad? I can definitely see somebody wanting a very minimal login screen for mobile, and maybe something very different for browser. > > > On 12/17/2015 3:37 AM, Stian Thorgersen wrote: > > It doesn't make sense to add this. For mobile phones responsive > design > should be used, instead of designing completely different > themes. If you > want to go further with different branding, etc.. then we'd also > need a > way to have different SSO "domains" or something within a realm. It > doesn't make sense to have SSO with different logins to the same SSO > "domain". > > On 15 December 2015 at 15:51, Bill Burke > >> wrote: > > Not until sometime next year unless somebody wants to > contribute it. > Feature freeze in about 3-4 weeks as we prepare for > productization. > > On 12/15/2015 7:02 AM, Jorge M. wrote: > > Is there any chance to configure login themes per > client, instead > of per > > realm? > > Basically I need to set a different login page for a > mobile app > client. > > The app client is not directly related with the other > clients of my > > realm (different branding, name, logo, colors, etc), but it > shares the > > user accounts. > > > > Thank you. > > > > > > > > _______________________________________________ > > 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 > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Thu Dec 17 08:50:12 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 14:50:12 +0100 Subject: [keycloak-dev] client templates and default mappers In-Reply-To: <5672BA89.1060603@redhat.com> References: <56704D39.6000600@redhat.com> <567164E8.2090604@redhat.com> <5672BA89.1060603@redhat.com> Message-ID: On 17 December 2015 at 14:37, Bill Burke wrote: > > > On 12/17/2015 3:54 AM, Stian Thorgersen wrote: > >> >> >> On 16 December 2015 at 14:19, Marek Posolda > > wrote: >> >> On 15/12/15 18:26, Bill Burke wrote: >> > What to do with default mappers and clients and client templates? >> > >> > When you create a client, it automatically adds default mappers for >> each >> > protocol. Now with client teampltes, if you create a client and >> specify >> > a client template when you create it, it will not add default >> mappers to >> > the client. Sound like right behavior? >> IMO yes. This also adds possibility that your client will be created >> with some builtin mappers removed by default. >> > >> > When creating a client template, should efault mappers be added to >> the >> > temaplte automatically? Or should the user have to manually add >> them? >> IMO it's better if he needs to manually add them. He can already add >> builtin mappers very easily if he wants to, so doesn't sound like >> usability issue that default mappers are not there. >> > >> > The mappers tab of a client will have a link "view template mappers" >> > which will bring you to the template's mapper page. You will be >> able to >> > add additional mappers to your client, but you will not be able to >> > override a template's mappers. >> > >> > Sound cool enough? >> > >> I think yes. >> >> Another possibility is that on client setup, there will be list of >> checkboxes with mappers inherited from the parent. And all the >> checkboxes (mappers) will be checked by default. Admin has possibility >> to uncheck some inherited mappers. That adds possibility for admin to >> remove some inherited mappers. >> >> Is it sufficient to support just one client template for client? I >> guess >> yes, but not sure... >> >> >> Client templates would be useful when there's a set of standard claims >> that a group of clients expects in a token. Allowing individual clients >> to add/remove/override those standard claims makes little sense. I also >> don't think there's a need for a client to be able to inherit from >> multiple templates. >> >> > Certainly makes sense for a client to be able to add additional claims. > Removal and override are just too complicated to model in a UI and > datamodel IMO. It *would* make things easier if a Client Template is > specified for a client the client cannot change config, add scopes, or add > mappers. I wrote that a bit quick. I didn't mean a client shouldn't be able to add, that's the only thing it should be able to do IMO. It should not be able to change/remove, not just from the complexity of modelling it, but also don't think it's going to be the wanted behavior. If you add a claim to a group of clients you expect it to be there for all clients. > > > -- > 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/20151217/0cbcdb44/attachment-0001.html From bburke at redhat.com Thu Dec 17 08:54:34 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 17 Dec 2015 08:54:34 -0500 Subject: [keycloak-dev] scope and client templates In-Reply-To: References: <56704F39.507@redhat.com> <56716584.8060502@redhat.com> <5672BAFE.9060903@redhat.com> Message-ID: <5672BE9A.3080608@redhat.com> On 12/17/2015 8:47 AM, Stian Thorgersen wrote: > > > On 17 December 2015 at 14:39, Bill Burke > wrote: > > I don't think you've thought this through. Of course you would want > scope on a client template. > > Client Template allows scope for Service A, Service B, and Service C. > > Client 1, Client 2, and Client 3 all need to access Service A, B, > and C. You'd have to define scope in each client when it would be > easier to define it in the client template. > > > I have thought it through - I just think that it's a lot more likely > that Client 1 will invoke Service A, Client 2 will invoke Service B. > Even if all clients invoke all services they will not have the same > scope, but different scope. > An argument of "I don't think people will use this" is just as valid as my argument that I think people will want to use it. The template would define the scope that is shared between multiple clients, then each client would add their own additional scope for the other services they need to use. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Thu Dec 17 08:56:43 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 14:56:43 +0100 Subject: [keycloak-dev] Themes per client In-Reply-To: <5672BD2D.5010701@redhat.com> References: <567028F6.20706@redhat.com> <5672B9C1.5070406@redhat.com> <5672BD2D.5010701@redhat.com> Message-ID: On 17 December 2015 at 14:48, Bill Burke wrote: > > > On 12/17/2015 8:43 AM, Stian Thorgersen wrote: > >> >> >> On 17 December 2015 at 14:33, Bill Burke > > wrote: >> >> Makes sense so long as User-Agent headers are accurate. You still >> would want to create themes per User-Agent. >> >> >> Having separate websites for desktop, mobile, tablet, etc.. is so old >> school. These days folks do a responsive design that works well for all >> user-agents. >> >> > I really don't have the experience to argue with you, but are you sure? > Are you sure this "responsive design" isn't just a fad? I can definitely > see somebody wanting a very minimal login screen for mobile, and maybe > something very different for browser. > It's definitively best practice these days and not a fad. The problem with designing per user-agent is that there's simply to many different devices and resolutions to worry about. Laptops range from 10" to 17". Desktops from 20" to 40". Mobile phones from 4" screens to 7" screens. Tablets from 8" to 14". All with different resolutions etc.. Even if you did a specific design for a type of device it'd still have to be responsive. Responsive design is the correct solution, but if it's really something that folks want to be able to do to have a different variant of a theme depending on the type of device then it's something we should bake into themes rather than add support for a theme per-client. It should be a type of device using a client, not the client itself. It seems to me that what people are actually asking for is a completely different theme per-client, not a variant of a theme. In that case users should be shared, but not the SSO session. > > >> >> On 12/17/2015 3:37 AM, Stian Thorgersen wrote: >> >> It doesn't make sense to add this. For mobile phones responsive >> design >> should be used, instead of designing completely different >> themes. If you >> want to go further with different branding, etc.. then we'd also >> need a >> way to have different SSO "domains" or something within a realm. >> It >> doesn't make sense to have SSO with different logins to the same >> SSO >> "domain". >> >> On 15 December 2015 at 15:51, Bill Burke > >> >> wrote: >> >> Not until sometime next year unless somebody wants to >> contribute it. >> Feature freeze in about 3-4 weeks as we prepare for >> productization. >> >> On 12/15/2015 7:02 AM, Jorge M. wrote: >> > Is there any chance to configure login themes per >> client, instead >> of per >> > realm? >> > Basically I need to set a different login page for a >> mobile app >> client. >> > The app client is not directly related with the other >> clients of my >> > realm (different branding, name, logo, colors, etc), but >> it >> shares the >> > user accounts. >> > >> > Thank you. >> > >> > >> > >> > _______________________________________________ >> > 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 >> >> >> > -- > 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/20151217/7f00b179/attachment.html From sthorger at redhat.com Thu Dec 17 10:40:08 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 16:40:08 +0100 Subject: [keycloak-dev] Need Help In-Reply-To: References: Message-ID: If you'd like to contribute to the Keycloak project the best place to start would be to fix some bugs. That gives you a good place to learn the code base before you get started on features. On 15 December 2015 at 20:16, Bheemanagouda A wrote: > Hi All, > > I would like to contribute to the keycloack project, can someone please > guide me. > > > -- > Regards, > Bheeman > > _______________________________________________ > 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/20151217/6a1160ca/attachment.html From sthorger at redhat.com Thu Dec 17 10:47:50 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Dec 2015 16:47:50 +0100 Subject: [keycloak-dev] scope and client templates In-Reply-To: <5672BE9A.3080608@redhat.com> References: <56704F39.507@redhat.com> <56716584.8060502@redhat.com> <5672BAFE.9060903@redhat.com> <5672BE9A.3080608@redhat.com> Message-ID: I don't have a strong disagreement to adding it. Just wondering whether it's really needed. If you guys think it's going to be used, let's add it. On 17 December 2015 at 14:54, Bill Burke wrote: > > > On 12/17/2015 8:47 AM, Stian Thorgersen wrote: > >> >> >> On 17 December 2015 at 14:39, Bill Burke > > wrote: >> >> I don't think you've thought this through. Of course you would want >> scope on a client template. >> >> Client Template allows scope for Service A, Service B, and Service C. >> >> Client 1, Client 2, and Client 3 all need to access Service A, B, >> and C. You'd have to define scope in each client when it would be >> easier to define it in the client template. >> >> >> I have thought it through - I just think that it's a lot more likely >> that Client 1 will invoke Service A, Client 2 will invoke Service B. >> Even if all clients invoke all services they will not have the same >> scope, but different scope. >> >> > An argument of "I don't think people will use this" is just as valid as my > argument that I think people will want to use it. The template would > define the scope that is shared between multiple clients, then each client > would add their own additional scope for the other services they need to > use. > > > -- > 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/20151217/f523bac8/attachment-0001.html From jm85martins at gmail.com Thu Dec 17 12:20:37 2015 From: jm85martins at gmail.com (Jorge M.) Date: Thu, 17 Dec 2015 17:20:37 +0000 Subject: [keycloak-dev] Themes per client In-Reply-To: References: <567028F6.20706@redhat.com> <5672B9C1.5070406@redhat.com> <5672BD2D.5010701@redhat.com> Message-ID: I'm not asking for mobile specific themes. I can manage that with responsive layouts. As Stian said, my request was: "It seems to me that what people are actually asking for is a completely different theme per-client, not a variant of a theme. In that case users should be shared, but not the SSO session." I agree that this may not make much sense. Probably users can get confused about the owner of their accounts if that is not explicity at login/register page. I will try to do the job with another approach. Thank you! And congrats. Keycloak is a awesome tool! 2015-12-17 13:56 GMT+00:00 Stian Thorgersen : > > > On 17 December 2015 at 14:48, Bill Burke wrote: > >> >> >> On 12/17/2015 8:43 AM, Stian Thorgersen wrote: >> >>> >>> >>> On 17 December 2015 at 14:33, Bill Burke >> > wrote: >>> >>> Makes sense so long as User-Agent headers are accurate. You still >>> would want to create themes per User-Agent. >>> >>> >>> Having separate websites for desktop, mobile, tablet, etc.. is so old >>> school. These days folks do a responsive design that works well for all >>> user-agents. >>> >>> >> I really don't have the experience to argue with you, but are you sure? >> Are you sure this "responsive design" isn't just a fad? I can definitely >> see somebody wanting a very minimal login screen for mobile, and maybe >> something very different for browser. >> > > It's definitively best practice these days and not a fad. > > The problem with designing per user-agent is that there's simply to many > different devices and resolutions to worry about. Laptops range from 10" to > 17". Desktops from 20" to 40". Mobile phones from 4" screens to 7" screens. > Tablets from 8" to 14". All with different resolutions etc.. Even if you > did a specific design for a type of device it'd still have to be responsive. > > Responsive design is the correct solution, but if it's really something > that folks want to be able to do to have a different variant of a theme > depending on the type of device then it's something we should bake into > themes rather than add support for a theme per-client. It should be a type > of device using a client, not the client itself. > > It seems to me that what people are actually asking for is a completely > different theme per-client, not a variant of a theme. In that case users > should be shared, but not the SSO session. > > >> >> >>> >>> On 12/17/2015 3:37 AM, Stian Thorgersen wrote: >>> >>> It doesn't make sense to add this. For mobile phones responsive >>> design >>> should be used, instead of designing completely different >>> themes. If you >>> want to go further with different branding, etc.. then we'd also >>> need a >>> way to have different SSO "domains" or something within a realm. >>> It >>> doesn't make sense to have SSO with different logins to the same >>> SSO >>> "domain". >>> >>> On 15 December 2015 at 15:51, Bill Burke >> >>> >> wrote: >>> >>> Not until sometime next year unless somebody wants to >>> contribute it. >>> Feature freeze in about 3-4 weeks as we prepare for >>> productization. >>> >>> On 12/15/2015 7:02 AM, Jorge M. wrote: >>> > Is there any chance to configure login themes per >>> client, instead >>> of per >>> > realm? >>> > Basically I need to set a different login page for a >>> mobile app >>> client. >>> > The app client is not directly related with the other >>> clients of my >>> > realm (different branding, name, logo, colors, etc), but >>> it >>> shares the >>> > user accounts. >>> > >>> > Thank you. >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> >>> >>> >> -- >> 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/20151217/3c7a9dd7/attachment.html From sthorger at redhat.com Fri Dec 18 03:00:45 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 18 Dec 2015 09:00:45 +0100 Subject: [keycloak-dev] keycloak authentication with session id instead of the token In-Reply-To: References: Message-ID: Once you've authenticated with Keycloak the application can setup its own HTTP session that contains the token details. Keycloak uses its own session cookie to maintain the SSO session. Keycloak won't authenticate with a application cookie though. On 13 December 2015 at 20:30, sabir wrote: > > Hello, > > I am working on integration keycloak authentication and setting up > authorization on endpoints in Dropwizard application. > > I've looked into existing project here: > https://github.com/ahus1/keycloak-dropwizard-integration/ > Also, I looked into > https://github.com/keycloak/keycloak/blob/c9e0a7a97dd98b31836195df167684a42dae4d3c/services/src/main/java/org/keycloak/authentication/authenticators/browser/CookieAuthenticator.java > > I am able to authenticate by username/password or passing keycloak token. > It is crucial for us to authenticate existing session without credentials > or keycloak token. > > Does keycloak expose endpoints to authenticate via Cookie like: > > KEYCLOAK_SESSION, KEYCLOAK_IDENTITY and/or KEYCLOAK_STATE_CHECKER > > I'm not sure if this is the correct place for questions like these. Please > direct me otherwise. > > 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/20151218/04de665f/attachment.html From sthorger at redhat.com Fri Dec 18 03:37:26 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 18 Dec 2015 09:37:26 +0100 Subject: [keycloak-dev] Issue with salt value while importing user json In-Reply-To: References: Message-ID: I tried with an export then import here and it works just fine, so I suspect the issue has to do with the json file you're using. I assume you're creating your own with external users rather than exporting from Keycloak. Maybe try to export from Keycloak to compare the format? On 14 December 2015 at 18:08, Kunal Kerkar wrote: > Hi Bruno, > > I'm trying out master. > > *KUNAL *| PRODUCT ENGINEER > Plivo, Inc. 340 Pine St, San Francisco - 94104, USA > > > > On Dec 14, 2015, at 22:35, Bruno Oliveira wrote: > > Hi Kunal, could you please tell me which version are you trying? I > would to try it locally here and see if I can reproduce the issue. > > On Mon, Dec 14, 2015 at 2:16 PM, Kunal K wrote: > > Hi, > > > I'm using the migration script to import my users with a new hash algorithm > > with the following command - > > > bin/standalone.sh -Dkeycloak.migration.action=import > > -Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=keycloak-data > > > However all my salt values get changed mid way during the whole operation > > and are stored (in the database) differently than what they should be. I > > checked the code and saw that the script expects the salt values to be > > base64 encoded. I tried encoding the salt to base64, but the same issue > > persists. > > > Lastly I tried to update the salt in the database (postgres) directly using > > an UPDATE statement, which worked well. Another observation I made is that > > salt is a 'bytea' data type in postgres and is stored as a hex value. > > > Is there some issue with the import script? I'll be happy to fix it if > > anyone points me in the right direction. > > > > -- > > KUNAL KERKAR | PRODUCT ENGINEER > > Plivo, Inc. 340 Pine St, San Francisco - 94104, USA > > Web: www.plivo.com | Twitter: @plivo, @tsudot > > > Free Incoming SMS for All US Short Codes ? Get One Today!? > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > - abstractj > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151218/04bd0cea/attachment-0001.html From bburke at redhat.com Mon Dec 21 10:31:52 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 21 Dec 2015 10:31:52 -0500 Subject: [keycloak-dev] simplfying client creation Message-ID: <56781B68.7080004@redhat.com> The last phase of client templates would be to allow defining configuration items in the client template that the client inherits. I was going to implement it as an either or. There will be a switch "Inherit Template Configuration" If this is off, then config items are taken from the client, otherwise they are taken from the template. There would be no mix and match. FYI, I"m not sure I'll be able to finish this prior to our deadline of early January. There's still a lot of JIRAs to do beyond this. This week though, I think I want to rework and simplify client creation a bit more. Create client on the admin console would only require must needed config attributes: OIDC: Client ID Root URL Choose Client Template if wanted These would be the defaults: * Access type: public (pretty much covers any use) * enabled true * Redirect URIs would default to Root/* * Standard Flow true * Direct Grants false * Service Accounts false SAML: Client Entity ID: SAML SP Endpoint (not required, can make it more fine grained) Choose client template if wanted * Sign Docs: true * Sign Assertions: false * Client Signature Required: true * Force POST BInding true * Front Channel logout: true * Force Name ID Format: false * Name ID Format username * Valid Redirect URIS renamed to Valid Assertion Consumer Service URIs * certs would be generated by default I'm also going to add a method to LoginProtocolFactory: setupDefaults(ClientModel). When a client is created, this method would be called, then the defaults would be overriden if they are set in the ClientRepresentation. Right now, all this default logic is in the admin console and I don't think it should be there. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Dec 21 16:00:17 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 21 Dec 2015 16:00:17 -0500 Subject: [keycloak-dev] ClientInitialAccessTest.org.keycloak.testsuite.admin.ClientInitialAccessTest Message-ID: <56786861.3010306@redhat.com> This fails for me. Can't figure out why. It passes if I just go into testsuite/integration and run mvn clean install, doesn't pass on a full build. I get BindAddress failures in startup. Not sure how this test is different than others other than it being the very last test that is run. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Dec 21 16:54:58 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 21 Dec 2015 16:54:58 -0500 Subject: [keycloak-dev] simplfying client creation In-Reply-To: <56781B68.7080004@redhat.com> References: <56781B68.7080004@redhat.com> Message-ID: <56787532.9060309@redhat.com> PR sent. New method on LoginProtocolFactory created for default settings. On 12/21/2015 10:31 AM, Bill Burke wrote: > The last phase of client templates would be to allow defining > configuration items in the client template that the client inherits. I > was going to implement it as an either or. There will be a switch > "Inherit Template Configuration" If this is off, then config items are > taken from the client, otherwise they are taken from the template. > There would be no mix and match. > > FYI, I"m not sure I'll be able to finish this prior to our deadline of > early January. There's still a lot of JIRAs to do beyond this. > > This week though, I think I want to rework and simplify client creation > a bit more. Create client on the admin console would only require must > needed config attributes: > > OIDC: > Client ID > Root URL > Choose Client Template if wanted > > These would be the defaults: > * Access type: public (pretty much covers any use) > * enabled true > * Redirect URIs would default to Root/* > * Standard Flow true > * Direct Grants false > * Service Accounts false > > SAML: > Client Entity ID: > SAML SP Endpoint (not required, can make it more fine grained) > Choose client template if wanted > > * Sign Docs: true > * Sign Assertions: false > * Client Signature Required: true > * Force POST BInding true > * Front Channel logout: true > * Force Name ID Format: false > * Name ID Format username > * Valid Redirect URIS renamed to Valid Assertion Consumer Service URIs > * certs would be generated by default > > I'm also going to add a method to LoginProtocolFactory: > > setupDefaults(ClientModel). When a client is created, this method would > be called, then the defaults would be overriden if they are set in the > ClientRepresentation. Right now, all this default logic is in the admin > console and I don't think it should be there. > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sthorger at redhat.com Tue Dec 22 02:35:35 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 22 Dec 2015 08:35:35 +0100 Subject: [keycloak-dev] simplfying client creation In-Reply-To: <56781B68.7080004@redhat.com> References: <56781B68.7080004@redhat.com> Message-ID: On 21 December 2015 at 16:31, Bill Burke wrote: > The last phase of client templates would be to allow defining > configuration items in the client template that the client inherits. I > was going to implement it as an either or. There will be a switch > "Inherit Template Configuration" If this is off, then config items are > taken from the client, otherwise they are taken from the template. > There would be no mix and match. > What's the point in that? I can't see anyone wanting to create multiple clients with the same config. > > FYI, I"m not sure I'll be able to finish this prior to our deadline of > early January. There's still a lot of JIRAs to do beyond this. > > This week though, I think I want to rework and simplify client creation > a bit more. Create client on the admin console would only require must > needed config attributes: > > OIDC: > Client ID > Root URL > Choose Client Template if wanted > > These would be the defaults: > * Access type: public (pretty much covers any use) > * enabled true > * Redirect URIs would default to Root/* > * Standard Flow true > * Direct Grants false > * Service Accounts false > > SAML: > Client Entity ID: > SAML SP Endpoint (not required, can make it more fine grained) > Choose client template if wanted > > * Sign Docs: true > * Sign Assertions: false > * Client Signature Required: true > * Force POST BInding true > * Front Channel logout: true > * Force Name ID Format: false > * Name ID Format username > * Valid Redirect URIS renamed to Valid Assertion Consumer Service URIs > * certs would be generated by default > So you are proposing that create client and edit client screens are different? IMO that's not good. Instead we should use tabs to split the settings into multiple sections. From what you are proposing above I see that most folks would have to first create the client then immediately edit the client afterwards. I'd like refactoring and UX changes to be discussed properly prior to doing them. > > I'm also going to add a method to LoginProtocolFactory: > > setupDefaults(ClientModel). When a client is created, this method would > be called, then the defaults would be overriden if they are set in the > ClientRepresentation. Right now, all this default logic is in the admin > console and I don't think it should be there. > > -- > 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/20151222/281bd316/attachment.html From thomas.raehalme at aitiofinland.com Tue Dec 22 02:42:35 2015 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Tue, 22 Dec 2015 09:42:35 +0200 Subject: [keycloak-dev] simplfying client creation In-Reply-To: References: <56781B68.7080004@redhat.com> Message-ID: On Dec 22, 2015 09:35, "Stian Thorgersen" wrote: > On 21 December 2015 at 16:31, Bill Burke wrote: >> >> The last phase of client templates would be to allow defining >> configuration items in the client template that the client inherits. I >> was going to implement it as an either or. There will be a switch >> "Inherit Template Configuration" If this is off, then config items are >> taken from the client, otherwise they are taken from the template. >> There would be no mix and match. > > > What's the point in that? I can't see anyone wanting to create multiple clients with the same config. I think it depends how you would like to implement multitenancy. With a single realm, client for each tenant, wouldn't it simplify configuration a great deal? Best regards, Thomas > >> >> >> FYI, I"m not sure I'll be able to finish this prior to our deadline of >> early January. There's still a lot of JIRAs to do beyond this. >> >> This week though, I think I want to rework and simplify client creation >> a bit more. Create client on the admin console would only require must >> needed config attributes: >> >> OIDC: >> Client ID >> Root URL >> Choose Client Template if wanted >> >> These would be the defaults: >> * Access type: public (pretty much covers any use) >> * enabled true >> * Redirect URIs would default to Root/* >> * Standard Flow true >> * Direct Grants false >> * Service Accounts false > > >> >> SAML: >> Client Entity ID: >> SAML SP Endpoint (not required, can make it more fine grained) >> Choose client template if wanted >> >> * Sign Docs: true >> * Sign Assertions: false >> * Client Signature Required: true >> * Force POST BInding true >> * Front Channel logout: true >> * Force Name ID Format: false >> * Name ID Format username >> * Valid Redirect URIS renamed to Valid Assertion Consumer Service URIs >> * certs would be generated by default > > > So you are proposing that create client and edit client screens are different? IMO that's not good. Instead we should use tabs to split the settings into multiple sections. From what you are proposing above I see that most folks would have to first create the client then immediately edit the client afterwards. > > I'd like refactoring and UX changes to be discussed properly prior to doing them. > >> >> >> I'm also going to add a method to LoginProtocolFactory: >> >> setupDefaults(ClientModel). When a client is created, this method would >> be called, then the defaults would be overriden if they are set in the >> ClientRepresentation. Right now, all this default logic is in the admin >> console and I don't think it should be there. >> >> -- >> 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/20151222/2b1968cd/attachment.html From sthorger at redhat.com Tue Dec 22 02:59:27 2015 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 22 Dec 2015 08:59:27 +0100 Subject: [keycloak-dev] ClientInitialAccessTest.org.keycloak.testsuite.admin.ClientInitialAccessTest In-Reply-To: <56786861.3010306@redhat.com> References: <56786861.3010306@redhat.com> Message-ID: Works fine here and on Travis. Maybe something Windows specific? Bind address failure sounds like it's actually the previous test that's not cleaning up properly rather than ClientInitialAccessTest actually failing. Maybe try to put an @Ignore on the test that runs before and see if it works then? On 21 December 2015 at 22:00, Bill Burke wrote: > This fails for me. Can't figure out why. It passes if I just go into > testsuite/integration and run mvn clean install, doesn't pass on a full > build. I get BindAddress failures in startup. Not sure how this test > is different than others other than it being the very last test that is > run. > -- > 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/20151222/6bf3b21e/attachment-0001.html From jm85martins at gmail.com Tue Dec 22 05:43:22 2015 From: jm85martins at gmail.com (Jorge M.) Date: Tue, 22 Dec 2015 10:43:22 +0000 Subject: [keycloak-dev] Custom federation - webservice In-Reply-To: References: <5668755C.6040500@redhat.com> <566A9C53.1080401@redhat.com> <566AB137.3050107@redhat.com> <566ABE50.8020606@redhat.com> <566F24AC.4020904@redhat.com> Message-ID: Hi, "I think I'm in the right track now. I'm being able to call the webservice before commit. However, when the user is sucessfully created by the webservice, I need to update my local user to add a property with the external user id. How can I do that in the same transaction? I'm trying to set the property on the managed delegate user model, but it has no effect." Is there any workaround for this? Basically, after the webservice call (I'm doing the job with an approach based on TxAwareLDAPUserModelDelegate) I need to get the previously saved userStorage user, set an attribute and save it again. At UserProvider interface I can't see any update method. Thanks 2015-12-17 8:50 GMT+00:00 Stian Thorgersen : > I guess in certain situations this can be helpful. It doesn't solve the > problem though so we need something smarter at some point, but we don't > have the time to do it right now so would have to be for 2.x. > > On 14 December 2015 at 21:21, Marek Posolda wrote: > >> I think yes. It should be quite easy to change the signature of >> KeycloakTransactionManager methods. Just waiting if other team members >> agree and then we can possibly change fix version of >> https://issues.jboss.org/browse/KEYCLOAK-1075 to 1.8 and do it for this >> release. >> >> Marek >> >> >> On 14/12/15 17:15, Jorge M. wrote: >> >> I agree. I think that could solve these issues. Is that something that >> can go on a near release? >> >> Thank yoy >> On 11 Dec 2015 12:15, "Vlastimil Elias" wrote: >> >>> >>> >>> On 11.12.2015 12:19, Marek Posolda wrote: >>> >>> I think what we can possibly do is: >>> >>> 1) Improve KeycloakTransactionManager to allow enlist with "priority" . >>> Instead of methods: >>> >>> void enlist(KeycloakTransaction transaction); >>> void enlistAfterCompletion(KeycloakTransaction transaction); >>> >>> we will have single method: >>> >>> void enlist(KeycloakTransaction transaction, int priority); >>> >>> By default, JPA will enlist transaction with priority 10 and infinispan >>> with priority 20 or something like that. >>> >>> This change will allow to enlist your transaction in your >>> FederationProvider with exact priority. So you can choose whether the >>> commit will happen before JPA commit, or after JPA commit or even after >>> infinispan commit etc. >>> >>> >>> +1, this may help to resolve current problems >>> >>> 2) Make TxAwareLDAPUserModelDelegate class more generic and reusable for >>> other federation providers >>> >>> >>> may also help, but point 1 with correct documentation is main what we >>> have to do >>> >>> Thanks >>> >>> Vlastimil >>> >>> >>> Marek >>> >>> On 11/12/15 10:50, Vlastimil Elias wrote: >>> >>> Hi, >>> >>> I use similar approach and problem is (at least I think) that local DB >>> transaction is already commited when our code runs. It has two negative >>> effects: >>> - if remote service call is successful you are not able to write >>> anything locally as Jorge mentioned >>> - if remote service call fails local DB record is commited already and >>> it is hard to implement correct error handling >>> >>> So I think User Federation SPI should be extended by exact method which >>> allows atomic call of backend during user creation or update before local >>> transaction is commited. I already created issue for it but not resolved >>> yet https://issues.jboss.org/browse/KEYCLOAK-1075 >>> >>> Vlastimil >>> >>> On 10.12.2015 18:49, Jorge M. wrote: >>> >>> Hi, >>> >>> I think I'm in the right track now. I'm being able to call the >>> webservice before commit. However, when the user is sucessfully created by >>> the webservice, I need to update my local user to add a property with the >>> external user id. How can I do that in the same transaction? >>> I'm trying to set the property on the managed delegate user model, but >>> it has no effect. >>> >>> Thank you! >>> On 9 Dec 2015 18:39, "Marek Posolda" wrote: >>> >>>> On 09/12/15 19:33, Jorge M. wrote: >>>> >>>> I'm developing a custom federation that communicates with my user >>>> repository via webservices. >>>> Probably this is a very strange scenario for a federation but that's >>>> the unique way that I have to communicate with the repository. >>>> >>>> My problem is that, as the webservices only exposes methods such as >>>> createUser and updateUser, I'm having problems with registrations and user >>>> profile updates because I'm not being able to do atomic calls to the >>>> webservice methods, with all the information that I need. >>>> >>>> As far as I know, from the properties file example and from the ldap >>>> federation source (probably I'm missing something) it seems that the >>>> federation api is intended to update and sync attribute by attribute >>>> (Keycloak <-> Federation). >>>> Am i wrong? Do you suggest another approach? Should I give up from >>>> having a federation that uses a webservice? >>>> >>>> You can use "transaction wrapper", which will allow you to store all >>>> the updates to user locally, but send the UPDATE request to your webservice >>>> later at transaction commit time. You may need to create custom transaction >>>> and enlist it with Keycloak TransactionManager. >>>> >>>> This is what we have for LDAP federation provider right now. See >>>> TxAwareLDAPUserModelDelegate. >>>> >>>> Marek >>>> >>>> Thank you. >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> -- >>> Vlastimil Elias >>> Principal Software Engineer >>> Developer Portal Engineering Team >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> -- >>> Vlastimil Elias >>> Principal Software Engineer >>> Developer Portal Engineering Team >>> >>> >>> _______________________________________________ >>> 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/20151222/1ad638f2/attachment.html From mposolda at redhat.com Tue Dec 22 15:15:49 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 22 Dec 2015 21:15:49 +0100 Subject: [keycloak-dev] Custom federation - webservice In-Reply-To: References: <5668755C.6040500@redhat.com> <566A9C53.1080401@redhat.com> <566AB137.3050107@redhat.com> <566ABE50.8020606@redhat.com> <566F24AC.4020904@redhat.com> Message-ID: <5679AF75.2000600@redhat.com> On 22/12/15 11:43, Jorge M. wrote: > Hi, > > "I think I'm in the right track now. I'm being able to call the > webservice before commit. However, when the user is sucessfully > created by the webservice, I need to update my local user to add a > property with the external user id. How can I do that in the same > transaction? > I'm trying to set the property on the managed delegate user model, but > it has no effect." > > Is there any workaround for this? Basically, after the webservice call > (I'm doing the job with an approach based on > TxAwareLDAPUserModelDelegate) I need to get the previously saved > userStorage user, set an attribute and save it again. At UserProvider > interface I can't see any update method. Yes, there is no any update method. It's because data of UserModel are automatically persistent and attached with DB. For example if you call: UserModel john = session.users().getUserByUsername("john"); The "john" instance is persistent. So then if you call: john.setFirstName("Johnnn"); the firstName is updated automatically in DB. No reason to call any additional update method. So if you are really able to call your webservice before commit, then you can just do something like: Object wsOutput = callYourWebService(...); john.setFirstName(wsOutput.getSomethingFromWSOutput); john.setAttribute("foo", wsOutput.getSomethingElseFromWSOutput); and it should work. If it doesn't work, then you're probably calling your web service after DB commit (this is what TxAwareLDAPUserModelDelegate is also doing btv. LDAP commit is send after DB commit). We will likely improve that for 1.8 by allow enlist transaction with priorities, which will allow to specify if your federationProvider commit should be called before or after JPA commit (See my previous email). Marek > > Thanks > > 2015-12-17 8:50 GMT+00:00 Stian Thorgersen >: > > I guess in certain situations this can be helpful. It doesn't > solve the problem though so we need something smarter at some > point, but we don't have the time to do it right now so would have > to be for 2.x. > > On 14 December 2015 at 21:21, Marek Posolda > wrote: > > I think yes. It should be quite easy to change the signature > of KeycloakTransactionManager methods. Just waiting if other > team members agree and then we can possibly change fix version > of https://issues.jboss.org/browse/KEYCLOAK-1075 to 1.8 and do > it for this release. > > Marek > > > On 14/12/15 17:15, Jorge M. wrote: >> >> I agree. I think that could solve these issues. Is that >> something that can go on a near release? >> >> Thank yoy >> >> On 11 Dec 2015 12:15, "Vlastimil Elias" > > wrote: >> >> >> >> On 11.12.2015 12:19, Marek Posolda wrote: >>> I think what we can possibly do is: >>> >>> 1) Improve KeycloakTransactionManager to allow enlist >>> with "priority" . Instead of methods: >>> >>> void enlist(KeycloakTransaction transaction); >>> void enlistAfterCompletion(KeycloakTransaction transaction); >>> >>> we will have single method: >>> >>> void enlist(KeycloakTransaction transaction, int priority); >>> >>> By default, JPA will enlist transaction with priority 10 >>> and infinispan with priority 20 or something like that. >>> >>> This change will allow to enlist your transaction in >>> your FederationProvider with exact priority. So you can >>> choose whether the commit will happen before JPA commit, >>> or after JPA commit or even after infinispan commit etc. >>> >> >> +1, this may help to resolve current problems >> >>> 2) Make TxAwareLDAPUserModelDelegate class more generic >>> and reusable for other federation providers >> >> may also help, but point 1 with correct documentation is >> main what we have to do >> >> Thanks >> >> Vlastimil >> >>> >>> Marek >>> >>> On 11/12/15 10:50, Vlastimil Elias wrote: >>>> Hi, >>>> >>>> I use similar approach and problem is (at least I >>>> think) that local DB transaction is already commited >>>> when our code runs. It has two negative effects: >>>> - if remote service call is successful you are not able >>>> to write anything locally as Jorge mentioned >>>> - if remote service call fails local DB record is >>>> commited already and it is hard to implement correct >>>> error handling >>>> >>>> So I think User Federation SPI should be extended by >>>> exact method which allows atomic call of backend during >>>> user creation or update before local transaction is >>>> commited. I already created issue for it but not >>>> resolved yet https://issues.jboss.org/browse/KEYCLOAK-1075 >>>> >>>> Vlastimil >>>> >>>> On 10.12.2015 18:49, Jorge M. wrote: >>>>> >>>>> Hi, >>>>> >>>>> I think I'm in the right track now. I'm being able to >>>>> call the webservice before commit. However, when the >>>>> user is sucessfully created by the webservice, I need >>>>> to update my local user to add a property with the >>>>> external user id. How can I do that in the same >>>>> transaction? >>>>> I'm trying to set the property on the managed delegate >>>>> user model, but it has no effect. >>>>> >>>>> Thank you! >>>>> >>>>> On 9 Dec 2015 18:39, "Marek Posolda" >>>>> > wrote: >>>>> >>>>> On 09/12/15 19:33, Jorge M. wrote: >>>>>> >>>>>> I'm developing a custom federation that >>>>>> communicates with my user repository via >>>>>> webservices. >>>>>> Probably this is a very strange scenario for a >>>>>> federation but that's the unique way that I have >>>>>> to communicate with the repository. >>>>>> >>>>>> My problem is that, as the webservices only >>>>>> exposes methods such as createUser and >>>>>> updateUser, I'm having problems with >>>>>> registrations and user profile updates because >>>>>> I'm not being able to do atomic calls to the >>>>>> webservice methods, with all the information that >>>>>> I need. >>>>>> >>>>>> As far as I know, from the properties file >>>>>> example and from the ldap federation source >>>>>> (probably I'm missing something) it seems that >>>>>> the federation api is intended to update and sync >>>>>> attribute by attribute (Keycloak <-> Federation). >>>>>> Am i wrong? Do you suggest another approach? >>>>>> Should I give up from having a federation that >>>>>> uses a webservice? >>>>>> >>>>> You can use "transaction wrapper", which will >>>>> allow you to store all the updates to user >>>>> locally, but send the UPDATE request to your >>>>> webservice later at transaction commit time. You >>>>> may need to create custom transaction and enlist >>>>> it with Keycloak TransactionManager. >>>>> >>>>> This is what we have for LDAP federation provider >>>>> right now. See TxAwareLDAPUserModelDelegate. >>>>> >>>>> Marek >>>>>> >>>>>> Thank you. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> Developer Portal Engineering Team >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -- >> Vlastimil Elias >> Principal Software Engineer >> Developer Portal Engineering Team >> >> >> _______________________________________________ >> 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/20151222/7cd236ec/attachment-0001.html From gerbermichi at me.com Mon Dec 28 03:23:57 2015 From: gerbermichi at me.com (Michael Gerber) Date: Mon, 28 Dec 2015 08:23:57 +0000 (GMT) Subject: [keycloak-dev] WildFly 10.0.0.CR5 not working Message-ID: <659244fe-2379-415b-a609-aa495438ba0f@me.com> Hi all Have everyone tried the newest WildFly version yet? I receive the following error: Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) ... 6 more Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000380: Distributed Executors Framework is not supported in simple cache at org.infinispan.distexec.DefaultExecutorService.ensureFullCache(DefaultExecutorService.java:665) at org.infinispan.distexec.DefaultExecutorService.(DefaultExecutorService.java:181) at org.infinispan.distexec.DefaultExecutorService.(DefaultExecutorService.java:143) at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.startLoading(InfinispanUserSessionInitializer.java:154) at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.loadPersistentSessions(InfinispanUserSessionInitializer.java:78) at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$3.run(InfinispanUserSessionProviderFactory.java:111) at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:264) at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory.loadPersistentSessions(InfinispanUserSessionProviderFactory.java:102) at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$2.onEvent(InfinispanUserSessionProviderFactory.java:86) at org.keycloak.services.DefaultKeycloakSessionFactory.publish(DefaultKeycloakSessionFactory.java:47) at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:84) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_51] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_51] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_51] at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_51] at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) ... 19 more I guess the problem could be the new infinispan?version (8.1.0). Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151228/339a01c1/attachment.html From mstrukel at redhat.com Mon Dec 28 11:57:05 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 28 Dec 2015 17:57:05 +0100 Subject: [keycloak-dev] WildFly 10.0.0.CR5 not working In-Reply-To: <659244fe-2379-415b-a609-aa495438ba0f@me.com> References: <659244fe-2379-415b-a609-aa495438ba0f@me.com> Message-ID: I can confirm the error. I'll investigate. On Mon, Dec 28, 2015 at 9:23 AM, Michael Gerber wrote: > Hi all > > Have everyone tried the newest WildFly version yet? > > I receive the following error: > > Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct > public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000380: > Distributed Executors Framework is not supported in simple cache > at > org.infinispan.distexec.DefaultExecutorService.ensureFullCache(DefaultExecutorService.java:665) > at > org.infinispan.distexec.DefaultExecutorService.(DefaultExecutorService.java:181) > at > org.infinispan.distexec.DefaultExecutorService.(DefaultExecutorService.java:143) > at > org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.startLoading(InfinispanUserSessionInitializer.java:154) > at > org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.loadPersistentSessions(InfinispanUserSessionInitializer.java:78) > at > org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$3.run(InfinispanUserSessionProviderFactory.java:111) > at > org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:264) > at > org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory.loadPersistentSessions(InfinispanUserSessionProviderFactory.java:102) > at > org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$2.onEvent(InfinispanUserSessionProviderFactory.java:86) > at > org.keycloak.services.DefaultKeycloakSessionFactory.publish(DefaultKeycloakSessionFactory.java:47) > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:84) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > [rt.jar:1.8.0_51] > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > [rt.jar:1.8.0_51] > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > [rt.jar:1.8.0_51] > at java.lang.reflect.Constructor.newInstance(Constructor.java:422) > [rt.jar:1.8.0_51] > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) > ... 19 more > > I guess the problem could be the new infinispan version (8.1.0). > > 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/20151228/b4a71292/attachment.html From satyajit.das at spire2grow.com Tue Dec 29 04:13:30 2015 From: satyajit.das at spire2grow.com (Satyajit Das) Date: Tue, 29 Dec 2015 14:43:30 +0530 Subject: [keycloak-dev] Login Rest Service Service Delay Message-ID: Hi Team, We are using login restful service of 1.4.0 final version. Sometimes the login takes quite some time(around 15 secs) to fetch the token id given back by login service. On subsequent call for login rest service takes very less time(75 milisecs) This is a complete random behavior. Kindly let me know how to overcome this issue. below is the snap of Token timeouts. [image: Inline image 1] Regards, Satya. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151229/427669ed/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 23676 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151229/427669ed/attachment-0001.png From csnyder at iland.com Wed Dec 30 09:05:39 2015 From: csnyder at iland.com (Cory Snyder) Date: Wed, 30 Dec 2015 14:05:39 +0000 Subject: [keycloak-dev] Allow TOTP issuer name to be set in the admin console? Message-ID: <399F82CA-7785-4147-AAC0-80CDE7D177C7@iland.com> Hey guys, Currently the TOTP issuer is just set to the name of the realm. Since the issuer name is the heading of the entry that appears in the Google Authenticator app, we?d love to be able to customize the issuer name in the admin console. Would this be reasonable? Can I create a ticket? Thanks, Cory Snyder -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151230/6c2886d3/attachment.html From erik.mulder at docdatapayments.com Thu Dec 31 06:42:43 2015 From: erik.mulder at docdatapayments.com (Erik Mulder) Date: Thu, 31 Dec 2015 12:42:43 +0100 Subject: [keycloak-dev] Control over audience parameter in JWT token Message-ID: <9A5619B792BBA041AE094585791BB71C013B9D4BE4AC@DDPEX01.DDP.dcloud.local> In the JWT token there is a field 'aud', or audience, which function is to state for which client(s) that token is intended. Currently (TokenManager:433) this is set to the client id: token.audience(client.getClientId()); This seems fine in general, but we would like to have a token with multiple entries in the audience field. This is possible and an array value is even claimed to be the 'general case': https://tools.ietf.org/html/rfc7519#section-4.1.3 (where one single value is the 'special case') Background is that we have a Keycloak running for a login of a frontend that talks to multiple different resource servers. We'd prefer to use one token for all of those resource servers. The resource servers use Spring Security, which explicitly checks that the 'name' you give to your Spring service is matched by (a value of) the audience field of the JWT token. So now we have to give all resource servers the same 'name', which doesn't feel right. So we need some way to influence the value of the audience field. This could be achieved by following this RFC: https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 which suggests to include a parameter to the request for the token. But that RFC does not consider multiple values for the audience. Another option would be to add an audience field in the settings of a Client in Keycloak. Which would, if set, define the audience field of the JWT token. This could be a comma separated string value that would translate to a JSON array. A question about this could be: 'then where to leave the client id?'. As suggested by this: https://stackoverflow.com/questions/32013835/client-id-or-multiple-audiences-in-json-web-token the best place to put the client id is in the 'azp' field (authorized party). Does the KeyCloak team see this as a valuable addition? Will it be implemented somewhere in the future? Or can we make a pull request ourselves that will be merged? Thanks, Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151231/d519a122/attachment.html