July 13, 2017 at 4:56 pm #18127skillerParticipant
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!July 14, 2017 at 4:02 pm #18143Peter MajorModerator
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.July 17, 2017 at 9:30 am #18149skillerParticipant
Can I (and how) define a policy with an action DENY for all except specified subjects which are allowed?July 18, 2017 at 4:07 pm #18169Peter MajorModerator
Not sure I understand your question… It is possible to use logical operators in the subjects view.
You must be logged in to reply to this topic.