Tuesday Mar 04, 2008

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:

    http\*://\*:\*/\*.html
  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:

About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today