Unexpected policy evaluation result on nested directories.

Tagged: , ,

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

  • Author
    Posts
  • #18127
     skiller 
    Participant

    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!

    #18143
     Peter Major 
    Moderator

    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.

    #18149
     skiller 
    Participant

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

    #18169
     Peter Major 
    Moderator

    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.

©2017 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?