Policy Logic in OpenSSO

Here's some information that, thanks to a comment from a member of the OpenSSO community, I found missing from our doc set. We wrote a great deal about policy but not a heck of a lot about policy logic.

NOTE: If you'd like an overview of policy and authorization take a look at the Authorization and Policy Service chapter in the Sun Java System Access Manager 7.1 Technical overview or the OpenSSO Policy Service Architecture document. I'll wait.

Done? OK. Now that you know everything there is to know about policy, here is the last piece. All of the following should be satisfied for a policy to be applicable to a request.

  1. The Resource Name defined in a policy's Rules should match that of the protected, requested resource. The match can be an exact literal match or one due to the presence of wild cards. Currently, policy agents only support http:// and https:// URLs as a Resource Name; they do not support IP addresses in place of the host name. Wild cards are supported as a substitution for a protocol, a host name, a port number, or a resource - as in:

  2. The requesting user should satisfy at least one of the Subject(s) defined by the policy. For example, if the Subject type is defined as Access Manager Identity Subject, the requesting user should be a member of the role selected in the policy.
  3. At least one Condition in EACH selected Condition Type defined in a policy should be satisfied by the requesting user, resource and/or environment parameters. For example, if the policy is defined with two Time conditions and two IP Address/DNS Name conditions, the request should satisfy at least one Time condition and at least one IP Address/DNS Name condition.

And sometimes policies collide; when this happens, the following rules take effect:
  1. When multiple policies are applicable to a particular resource, the order in which the policies are evaluated is not deterministic.
  2. If a policy decision for a requested action is boolean, a value of false overrides one of true. For example, when deciding authorization for a web URL, deny overrides allow.
  3. If a policy decision for a requested action is boolean and the request is determined to be false based on policies evaluated thus far, no further policies will be evaluated for the requested action. This behavior can be changed by toggling the Continue Evaluation On Deny Decision attribute in the Policy Configuration Service.

So, in conclusion, sometimes musical styles collide also. When this happens there are no rules. You might get Sammy Davis, Jr. (smokin' a ciggy butt) and Cass Elliot singing their Las Vegas-style version of the Peter, Paul and Mary classic, I Dig Rock and Roll Music.

Or you get Mary dancing like she's in a mosh pit to an acoustic version of the same song.

UPDATE: For more information on policy logic and wildcards see the following entries:


You might also want to note the sharp and pointy bits around what constitutes the URL. Some agents pass through query arguments, some (I believe) don't, and some treat a trailing \* as matching the query arguments; definitely others don't.

So a URL of "http\*://\*:\*/foobar/\*" may or may not match "http://my:80/foobar/page?arguments", depending on the agent.

Posted by michael robinson on March 04, 2008 at 04:35 AM PST #

Here's to you, Mr. Robinson. Maybe today's entry will help: http://blogs.sun.com/docteger/entry/wildcard_matches_in_policy_agents

Posted by DocTeger on March 04, 2008 at 11:31 PM PST #

Dear DocTeger,

I have 2 policies, both match the subject, one evaluates to true (allow) another to false (deny). The resulting policy decision is 'allow', which is quite opposite to 2. And this is AM7.1U1.

Posted by Alex on August 07, 2008 at 09:51 AM PDT #

Alex, I'm not sure what you are asking. Why does it go to 'allow' when one policy is 'deny'? I would need some more information (what are you trying to do, how are policies configured, etc.) and post it here or send it on to users@opensso.dev.java.net. Although it is 7.1, your question might still be applicable to OpenSSO users.

Posted by DocTeger on August 08, 2008 at 12:24 AM PDT #

Thanks, Michael. I am implementing 2FA as a policy which requires additional authentication module (chain, auth level - all the same). I have several policies which apply to different subject groups (selected by filtered roles). I do not want to add authentication condition to the existing policies, I just want to have one special policy with subject=some filtered role and condition=auth module|authlevel|authchain. All protected resources are the same for all policies: <myapp>/\*.\*. When AM evaluates policy I see that my both policies chosen by user's subject: '2FA policy' says: 'deny' and provides advices to authenticate, but another policy says 'allow'. The result of policy evaluation becomes 'allow' (+ advices) so when it is returned to the policy agent the latter does not redirect me to login page.

Posted by Alex on August 08, 2008 at 03:02 AM PDT #

To clarify: both policies are 'allow' policies. But 1st one is evaluated to true and 2nd one - to false, since it is supposed to force me to authenticate against particular module. But overall decision is allow=true.

Posted by Alex on August 08, 2008 at 03:58 AM PDT #

Alex got an answer for his question on the users@opensso.dev.java.net email alias.

You are seeing the expected behavior for the policies that are defined. If you want a subset of users to be allowed only if they authenticate to level 2, you would remove them from role 1 and add them to role 2. You would define policy 2 with subject as role 2.

Posted by DocTeger on August 12, 2008 at 11:21 PM PDT #

Post a Comment:
Comments are closed for this entry.



« April 2014