I have tracked down where the problem is; whether it's by design or a flaw, I don't know: org.keycloak.authorization.policy.evaluation.DefaultEvaluation.getDecisionCache() - Map<Policy, Map<Object, Effect>> The key to the decision cache Map is a Policy object, so when more than one resource in the same request match on the same Policy, only one result ends up in the cache-the first permission that is evaluated. A solution would be to change the Map key to some kind of wrapper around the Policy that contains the permission object on which the Policy matched, e.g. the resource. This would result in what I expect, which is a decision on each permission sent in the request. Does this make sense? Thanks, Dave From: David Erie (US) Sent: Thursday, October 11, 2018 4:30 PM To: keycloak-user(a)lists.jboss.org Subject: Probable bug in permissions evaluation Hello, I believe I found a bug in the permissions evaluation engine, and I didn't see anything in JIRA about this. I am running Keycloak 4.3.0.Final. I configured some permissions such that a user would have access to the read scope on one resource, but not on another. When I evaluate permissions on each of the resources and read scope by themselves, they are properly granted and denied, as expected. However, when I evaluate both resources at the same time, the result is wrong, and it depends on the order in which I add the resources. If I add the allowed resource first, then they are both granted, but if I add the forbidden resource first, then they are both denied. What I expected is that one is allowed and the other is denied, regardless of the order I add them to the request. I have verified this in the admin console and the REST and Java APIs, and it produces the same broken result. Unless I'm missing something, this is a critical bug that would impact our planned usage of Keycloak. Thank you, Dave