Authorization rules

An authorization rule policy specifies which security policy applies to an object based on various conditions, such as context and environment.

Each authorization rule policy has a unique name and can be applied to multiple objects within a domain.

You define authorization rules in a way similar to definitions of ACL policies and POPs. You specify conditions that must be met before access to a protected object is permitted. We create an authorization rule with a number of conditions. These conditions are based on data supplied to the authorization engine in the user credential from several sources. The conditions can be based on data from the resource manager application and from the encompassing business environment. These conditions are evaluated as a Boolean expression to determine whether access to the object must be granted or denied.

We can work with complex, structured data using the language of an authorization rule. We can examine values in the rule data and make informed access decisions. We can define the data for an access decision statically within the system or during a business process. Authorization rules provide the flexibility of a policy defined by an external authorization service. Unlike an external authorization service, we do not have to build an external authorization service into a shared library plug-in to use the authorization rules.

How authorization rules differ

ACL policies use a predefined set of operations to control which users and groups have permission to do operations on a protected object. Rules decide Whether to grant access based on the attributes of a user or object and the context and environment.

For example, the ability of a user to read data associated with an object is either granted or denied by an ACL policy. POPs apply to all users and groups and control conditions specific to a particular protected object. For example, time-of-day access excludes all users and groups from accessing an object outside of the times set in the time-of-day policy.

Unlike ACL policies, authorization rules determine whether to allow access based on the attributes of a person or object. The authorization rules also take into account the context and environment that surrounds the access decision. For example, we can use a rule to implement a time-of-day policy that depends on the user or group. We can use an authentication rule to extend the controls provided by the ACL policies to implement a more advanced policy. For example, we can develop a policy based on quotas.

An ACL policy can grant a group permission to write to a resource. A rule can extend the policy. For example, a rule can evaluate Whether a group exceeds a specified quota before it permits the group to write to a resource.

When to use authorization rules

In the authorization process, the entire security policy (ACL policies, POPs, and authorization rules) must permit access to the protected object before access is granted. Authorization rules provide the flexibility to extend an ACL policy or POP by tailoring the security policy to your needs.

Authorization rules can extend a policy implemented by other IBM ISAM policy types. These rules are not merely extensions of the existing policy types. An authorization rule is a policy type that is robust enough to replace the ACL policy and POP. Using ACL policies and POPs generally provides better performance. Use an authorization rule to complement these policies instead of replacing them.

Parent topic: Security Verify Access administration