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