Unexpected policy evaluation result on nested directories.

Tagged: , ,

This topic has 3 replies, 2 voices, and was last updated 4 years, 11 months ago by Peter Major.

  • Author
  • #18127

    https://forum.forgerock.com/topic/nested-paths-access-misunderstanding/ is the example.

    I have a protected url http://sso-www.opendesign.com/odoutgoing just for authenticated users.
    http://sso-www.opendesign.com/odoutgoing/PastReleases for ldap group ‘admin’.
    http://sso-www.opendesign.com/odoutgoing/PastReleases/4.00.00_Production for ldap group ‘developers’.

    I can authenticate and enter to any path behind http://sso-www.opendesign.com/odoutgoing. Why?

    I see log records like:

    Matched index rules (resource:http://sso-www.opendesign.com:80/odoutgoing/pastreleases/4.00.00_production/, realm:/www): [*://*:*/odoutgoing/*, *://*:*/odoutgoing/pastreleases/*, *://*:*/odoutgoing/pastreleases/4*]
    IdentitySubject.isMember():got membership from SubjectEvaluationCache  for userDN = uid=skeler,ou=People,dc=opendesign,dc=com, subjectValue = id=developers,ou=group,o=www,ou=services,dc=openam,dc=forgerock,dc=org, result = false
    IdentitySubject.isMember(): user uid=skeler,ou=People,dc=opendesign,dc=com is not a member of this subject

    But access anyway is granted!

    OpenAM then evaluates those policies to make a decision based on the conditions matching those of the subject and environment. When multiple policies apply for a particular resource, the default logic for combining decisions is that the first evaluation resulting in a decision to deny access takes precedence over all other evaluations. OpenAM only allows access if all applicable policies evaluate to a decision to allow access.

    According this documentation any matched policy must block access to the resource but is does not!

     Peter Major

    Policy evaluation 101:
    * the policy framework finds all policies that match the requested resource, so this would mean that these policies would be returned: *://*:*/odoutgoing/*, *://*:*/odoutgoing/pastreleases/*, *://*:*/odoutgoing/pastreleases/4*

    * the policy framework will then check whether the end-user’s identity matches the subject defined in the policy. If a subject is not matched, then that policy is not applicable for this user.
    * the policy framework will then evaluate the conditions defined on the policies. If the condition evaluation fails (without a condition advice), then the policy is not applicable.

    For all applicable policies, the policy framework will determine the resulting action allow/deny values and return that as the user’s entitlement.

    If you want subpaths to be protected then you should define policies that prevents access. So you would have a policy for *://*:*/odoutgoing/* with all authenticated users. Then a policy *://*:*/odoutgoing/pastreleases/ that has actions on DENY for the subject that isn’t admin. Then a policy *://*:*/odoutgoing/pastreleases/4* with DENY actions for the subject that isn’t developers, but is admin.

    The thing you need to remember is that policy matching is all about determining which policies apply, and then the combination of the policy evaluation results is by default DENY override, meaning that an explicit DENY action will have a precedence over an explicit ALLOW result.


    Can I (and how) define a policy with an action DENY for all except specified subjects which are allowed?

     Peter Major

    Not sure I understand your question… It is possible to use logical operators in the subjects view.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?