November 2016 - keycloak-dev - Jboss List Archives

session.userLocalStorage() needs to be fronted by cache

by Bill Burke

I think I made a mistake when User Storage Providers are importing into local cache. Currently KeycloakSession.userLocalStorage() does not have a cache in front of it. The LDAP and Kerberos providers call this to determine if the user has been imported or not. The thing is, the user may already be cached and I think there is a possibility of updating the user (on demand resync) and getting stale cache entries. Also, we don't want a database hit every time there is validation happening. So, I'm going to figure out a way to have the cache front the userLocalStorage() method too like we do for userStorage(). This will require some refactoring of UserCacheSession. Not sure if that will conflict with Marek's work. Bill

8 years, 1 month

3
4
0 / 0

APIs to manage authorization policies and permissions

by Muein Muzamil

Hi all, I am trying to integrate KeyCloak with our application, For that purpose, I need to be able to call KeyCloak APIs to manage authorization information. I came across protection API which allows you to manage resource and scopes. I am wondering, do we also have any APIs available to manage authorization policies and permissions? Regards, Muein

8 years, 1 month

2
1
0 / 0

Keycloak 2.4.0.CR1 released

by Stian Thorgersen

We've just released Keycloak 2.4.0.CR1. This release is mainly a maintenance release and we've done a lot of minor improvements and bug fixes. For the full list of issues resolved check out JIRA <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fix...> and to download the release go to the Keycloak homepage <http://www.keycloak.org/downloads>.

8 years, 1 month

2
1
0 / 0

Bug with Users and Groups Using Mongo in v2.30

by Morse, Alexander (US - Newton)

Hi, Have run into a bug where assigning a user to a group when using Mongo DB does not work in version 2.3.0. Am using the base jboss/keycloak-mongo:2.3.0.Final docker image to run Keycloak. Simply create a group, then a user. Attempting to change the user's group membership to be part of the group yields an error message and no change. Everything seems to work fine when using the plain image with an internal user store. This is not a problem in version 2.2.1 either. Seems to be a regression specific to MongoDB in this version. I have copied the stack trace of the error below. Has this already been reported as a bug? I did not see it. This is the same issue reported by Jitendra Chouhan on the user list. Let me know if you need any more information. Thanks, Alex 21:12:05,078 ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /auth/admin/realms/master/users/56e5eecc-85c3-4af5-84f2-84ad59c2c745/groups/a682283f-fd8e-4ce8-ad52-d928fec1d685: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException at org.keycloak.models.mongo.keycloak.adapters.UserAdapter.isMemberOf(UserAdapter.java:263) at org.keycloak.models.cache.infinispan.UserAdapter.isMemberOf(UserAdapter.java:368) at org.keycloak.services.resources.admin.UsersResource.joinGroup(UsersResource.java:992) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) ... 37 more This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. v.E.1

8 years, 1 month

2
1
0 / 0

A probable bug in read-only mode for LDAP Federation Provider

by Bruno Oliveira

Good morning, I believe I found a bug while playing with LDAP Federation provider. But before file any Jira, I would like to confirm. Steps to reproduce: 1. Just follow all the steps described here https://github.com/keycloak/keycloak/tree/master/examples/ldap 2. Change the federation provider to read-only mode 3. Synchronize all users 4. Delete all the roles associated with LDAP (For example: ldap-user, ldap-admin) 5. Now go to "Users" > "Edit" 6. Click on "Role Mappings" You might get an exception like this: https://gist.github.com/abstractj/19eb8e5f25fee3b469110246066ecd08 Is this a bug? -- abstractj PGP: 0x84DC9914

8 years, 1 month

3
7
0 / 0

Issues with clustered invalidation caches

by Marek Posolda

I was looking at the cache issue reported by customer. I found the cause of it and couple of other related issues: KEYCLOAK-3857 - Bad performance with clustered invalidation cache when updating object KEYCLOAK-3858 - Removing model object send lots of invalidation messages across cluster KEYCLOAK-3859 - Lots of userCache invalidation messages when invalidating realm KEYCLOAK-3860 - All realm users are invalidated from cache when removing some realm object In shortcut, our cache works fine in local mode. But in cluster, there are issues with the invalidation caches . We don't have issues with stale entries, but this is purchased but lots of various performance issues like: - There are lots of invalidation messages sent across the cluster - Eviction on the node, which received invalidation event, is also very uneffective. For example evicting realm with 1000 roles needs to call 1000 predicates, which iterates the cache 1000 times. - Invalidation cache doesn't allow to differ between the context why the object was invalidated. For example when I update realm settings on node1, I need to invalidate just the CachedRealm object, but not all the other objects dependent on the realm. However the invalidation event received on node2 doesn't know, if I invalidated CachedRealm because of realm update or because of realm removal. So for more safety, it assumes removal, which evicts all realm objects! See https://issues.jboss.org/browse/KEYCLOAK-3857 for details. - Finally we have the workaround with the "invalidation.key" objects in our invalidation caches. This is currently needed because when invalidating object on node1, the invalidation event is NOT received on node2 unless the object is there. Hence the workaround with the "invalidation.key" records just to avoid this limitation of invalidation cache. For solve all these issues, I propose: - Instead of relying on invalidation caches, we will send notification across cluster what happened (eg. message "realm XY was updated"). All the nodes will receive this notification and will evict all their locally cached objects accordingly and bump their revisions locally. This would be much more stable, performant and will allow us to remove some workarounds. Some details: - The caches "realms" and "users" won't be "invalidation" caches, but they will be "local" caches. - When any object needs to be removed from cache because of some reason (eg. updating realm), the notification message will be sent from node1 to all other cluster nodes. We will use the replicated cache for that. Node1 will send the notification message like "realm XY was updated" . - Other cluster nodes will receive this message and they will locally trigger evictions of all the objects dependent on particular realm. In case of realm update, it's just the CachedRealm object itself. In case of realm removal, it is all realm objects etc. - Note message will contain also context "realm XY was updated" or "realm XY was removed" . Not just "invalidate realm XY". This allows much more flexibility and in particular avoid the issues like https://issues.jboss.org/browse/KEYCLOAK-3857 . - We already have replicated cache called "work", which we are using to notify other cluster nodes about various events. So we will just use this one. No need to add another replicated cache, we will probably just need to configure LRU eviction for the existing one. - Also note that messages will be always received. We won't need workaround with "invalidation.key" objects anymore. - Also we don't need recursive evictions (which has very poor performance. See https://issues.jboss.org/browse/KEYCLOAK-3857 ), because receiving node will know exactly what happened. It will remove objects just the same way like the "sender" node. - Finally the amount of traffic sent across the cluster will be much lower. This sounds like the big step, but IMO it's not that bad :) Note that we already have all the predicates in place for individual objects. The only change will be about sending/receiving notifications across cluster. I think I am able to prototype something by tomorrow to doublecheck this approach working and then finish it somewhen middle next week. WDYT? Marek

8 years, 1 month

3
9
0 / 0

Realm role to see groups and roles (only)

by Erik Berdonces Bonelo

Hello everyone, I’m checking the different realm roles (listed here: https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/ad...). I’m trying to allow a user to only view the list of groups and roles available in the realm. I’d like not to allow him to list all the users, as this would be a bit too dangerous. Is there any combination for this? Mostly because with the `view-realm` role I can see the realm roles. However I need to enable `view-users`role to also see the groups, and that enables all the users as well. Otherwise I’ll open a feature request to Jira… The idea is that I want to allow a client in the admin API to fetch this information (roles and groups only), so I’d give to the Client’s Service Account the minimum roles, so it can fetch the data. This way, I’d fill up an autocomplete form so the users can setup easily a role mapping between Keycloak and my local website. We have lots of roles, and remembering them by memory it’s not a case! Thanks a lot in advance! — Best Regards, Erik Berdonces Bonelo

8 years, 1 month

1
0
0 / 0

Keycloak is now OpenID Connect certified

by Stian Thorgersen

I'm pleased to announce that Keycloak is now OpenID Connect certified for all 5 conformance profiles. For details check out http://openid.net/certification/.

8 years, 1 month

6
5
0 / 0

OrientDB Support

by Sena Gbeckor-Kove

Hi, If nobody has implemented it yet. I'd be interested in adding OrientDB support. That way we can avoid having to manage Mongo as well. Cheers -- ----- Sena Gbeckor-Kove Founder & CEO ananse 19-09, 1 North Bridge Road Singapore 179094 m: +65 3163 5466 e: sena(a)ananse.im w: www.ananse.im

8 years, 1 month

2
2
0 / 0

OTP API

by gambol

Hiya Does the latest version of Keycloak provide any means of verifying a user's TOTP?. Our use-case at the moment, we have an application which once the user is authenticated we issue a token of sorts ... however, we wish to provide a popup that requests a user's TOPT every few hours which we "could" verify via service account ... I can't see any access at the moment via the rest api Rohith

8 years, 1 month

5
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

keycloak-dev November 2016