Security policy

Attaching a security policy to objects in the protected object space controls access to objects in a domain. After attaching a security policy to an object, any change to the security policy is reflected immediately throughout the domain. Each security policy can be defined with a combination of the following controls:

Access control list policies

Predefined actions that a set of users and groups can do on an object. For example, read access to an object.

Protected object policies

Access conditions associated with an object. A POP affects all users and groups. For example, a time-of-day restriction can be placed on an object that excludes all users and groups from accessing that object during the specified time.

Authorization rules

Condition evaluated to determine whether access is permitted. The data that determines whether access is permitted can be based on the context of the request, the current environment, or other external factors. For example, it can deny a request to modify an object more than five times in an eight-hour period.

A security policy can be explicitly applied to an object or can be inherited by an object that is above it in the hierarchy. Apply an explicit security policy in the protected object space only at those points in the hierarchy where the security policy must change. We can implement a security policy by strategically attaching ACL policies, POPs, and authorization rules to objects that require protection. The authorization service decides whether to allow or deny access to objects based on several criteria. One criterion is the credentials of the user that is making the request. Other criteria include the specific permissions and conditions specified in the ACL policies, POPs, and authorization rule. The authorization service uses the following algorithm to process the security policy attached to a protected object:

1. Check permissions in the ACL policy to determine whether the user can override the attached POP or authorization rule.

2. When there is an authorization rule attached and the user cannot override it, gather the Access Decision Information (ADI).

3. When there is a POP attached:
   1. Check the Internet Protocol (IP) endpoint authentication method policy.
   2. Check the time-of-day policy.
   3. Check the audit-level policy and audit the access decision.

4. When an authorization rule is attached and the user cannot override the authorization rule, check the authorization rule policy.

5. When an external authorization service (EAS) operation or a POP trigger applies to this access decision, call the EAS.

If any of the ACL policy, POP, or authorization rule evaluations fail, then the access request is denied. The EAS can override this decision on its own if it is configured to do so.

Parent topic: Security Verify Access administration