[OPENAM-12338] policies?_action=evaluate checks all policy sets Created: 18/Jan/18  Updated: 04/Sep/19  Resolved: 05/Jun/18

Status: Resolved
Project: OpenAM
Component/s: policy
Affects Version/s: 13.5.0, 13.5.1, 14.0.0, 14.1.0, 14.1.1, 14.5.0, 14.5.1
Fix Version/s: 13.5.3, 14.1.2,, 6.5.0, 6.0.1, 5.5.2

Type: Bug Priority: Major
Reporter: Aaron Haskins Assignee: Lawrence Yarham
Resolution: Fixed Votes: 0
Labels: EDISON
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is duplicated by OPENAM-13550 Incorrect policy condition script run... Closed
relates to OPENAM-14419 Policy evaluation returns search resu... Resolved
Target Version/s:
Sprint: AM Sustaining Sprint 48, AM Sustaining Sprint 49, AM Sustaining Sprint 50, AM Sustaining Sprint 51
Story Points: 3
Support Ticket IDs:
Verified Version/s:
Needs QA verification:


Bug description

policies?_action=evaluate appears to check all policy sets even though application is set in the request. Should application be a required field if AM is checking all of them regardless?

How to reproduce the issue

  1. Create two policy sets, each protecting a different resource e.g. Pattern1 and Pattern2
  2. Set one policy set to require AuthLevel 1 and the other to AuthLevel 2
  3. Evaluate application PolicyA and PolicyB with the wrong resource (if Pattern1 is a resource protected in PolicyA, put it in the request with PolicyB for example)
  4. AuthLevelConditionAdvice in the response indicates the resource is protected by the application not defined in the request 
Expected behaviour
Not sure but if we are evaluating a particular application / policy set, and the resource we are evaluating is not found, I don't think AM should return advice for another application / policy set where the resource is found.
Current behaviour
Returns advice for application / policy set not defined in the request


Comment by Andrew Forrest [ 14/May/18 ]

Apologies for the delay looking into this, it's a good find and potentially quite a problematic bug! I'd suggest this has nothing to do with the index tree cache rather it looks to be a problem with late filtering on the policies returned. This does point to a bigger issue around how policies are stored in DJ and the filtering used to query these. For now I'd suggest the following fix:

diff --git a/openam-core/src/main/java/com/sun/identity/entitlement/Entitlement.java b/openam-core/src/main/java/com/sun/identity/entitlement/Entitlement.java
index 2b2f9c6f71..eb34ec8e4c 100644
--- a/openam-core/src/main/java/com/sun/identity/entitlement/Entitlement.java
+++ b/openam-core/src/main/java/com/sun/identity/entitlement/Entitlement.java
@@ -470,10 +470,6 @@ public class Entitlement {
             return Collections.EMPTY_SET;
-        if (!this.applicationName.endsWith(applicationName)) {
-            return Collections.EMPTY_SET;
-        }
         ResourceName resComparator = getResourceComparator(adminSubject, realm);
         Set<String> matched = new HashSet<String>();
diff --git a/openam-core/src/main/java/com/sun/identity/entitlement/opensso/OpenSSOPrivilege.java b/openam-core/src/main/java/com/sun/identity/entitlement/opensso/OpenSSOPrivilege.java
index 5b375bfd24..62b8e724e0 100644
--- a/openam-core/src/main/java/com/sun/identity/entitlement/opensso/OpenSSOPrivilege.java
+++ b/openam-core/src/main/java/com/sun/identity/entitlement/opensso/OpenSSOPrivilege.java
@@ -136,6 +136,12 @@ public class OpenSSOPrivilege extends Privilege {
             return Arrays.asList(entitlement);
+        if (!originalEntitlement.getApplicationName().equals(applicationName)) {
+            Entitlement entitlement = new Entitlement(originalEntitlement.getApplicationName(),
+                    originalEntitlement.getResourceName(), Collections.<String>emptySet());
+            return Collections.singletonList(entitlement);
+        }
         // First evaluate subject conditions.
         SubjectDecision subjectDecision = doesSubjectMatch(adminSubject, realm, subject, resourceName, environment);
Comment by Filip Kubáň [X] (Inactive) [ 17/Jul/18 ]

verified in ForgeRock Access Management Build 6b8d8d357c (2018-July-15 21:12)

Comment by Ľubomír Mlích [ 04/Sep/19 ]

Reproduced in ForgeRock Access Management 5.5.1 Build 96b47ad4f1 (2017-October-26 15:41), I could see policy advice as described in Lawrence's comment

Verified as fixed in ForgeRock Access Management 5.5.2-M7 Build 965200a558 (2019-August-20 08:11), there was access denied as a result of same policy evaluation

Generated at Fri Nov 27 17:21:23 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.