Resource Access Policies

A resource access policy is the authorisation policy that can be applied to resource servers and/or resources. The underlying resource access policy is represented by an ACL and/or a POP. There are 5 different types of resource access policy that can be applied to a resource server or resource:

Default Verify Access Policy

• No ACL or POP is attached to the protected object. Instead the parent object is used to check access.

• As stated in Authorization, protected objects exist in a new objectspace /WebSEAL_API. If both the resource and resource server have Default Verify Access Policy enabled, the authorization check reverts to use the standard /WebSEAL objectspace.

No Access Permitted

An ACL is created to not allow access to anyone.

Unauthenticated Access Allowed

An ACL is created to allow access to unauthenticated users.

Any Authenticated

An ACL is created to allow access to any authenticated users.

Custom

A custom ACL and/or POP is attached to the protected object.

API Access Control has the capability of defining a custom policy that can be used for resource server or resource access control. The custom policy can define:

• Groups allowed access.
• Credential attributes that are checked for access control.

Any groups specified are added to an ACL where:

• The format of the ACL name is “resource_access_control_policy_” + custom policy name.
• If the user is a member of any of the groups access is allowed.

The credential attributes are specified as part of an attribute check like:

<attribute_name> = <attribute_value> { OR <attribute_name> = <attribute_value>}

The attribute check is added to a POP where:

• The format of the POP name is “resource_access_control_policy_” + custom policy name.
• The POP has the attribute “eas-trigger” set to “trigger_attr_eas”. This enables the attribute check.
• The POP has one or more requires attributes set. These are used for credential attribute checks.
  • Multiple credential attributes can be specified in a single POP attribute. In this case only one of the specified attributes need to match. (OR condition).
  • Multiple POP attributes can be specified and in this case every POP attribute must evaluate to true (AND condition).

• If all of the attribute checks are true access is allowed

For example: A policy named "test" is created with the following groups:

• admin
• privileged

and the following attribute checks:

• scope=usr:write OR scope=usr:admin
• AuthenticationLevel=2

This results in the creation of the ACL and the POP:

resource_access_policy_test

  ACL Name: resource_access_control_policy_test
  Description: API Access Control Policy ACL- Do not modify
  Entries:
    Group admin T
    Group privileged T
    User sec_master TcmdbsvaBRl

resource_access_policy_test

  Protected object policy:
resource_access_control_policy_test
  eas-trigger
    trigger_attr_eas
  requires
    test='scope=usr:write OR scope=usr:admin'
  requires
    test='AuthenticationLevel=2'

When the policy is used in an authorisation check for access to be granted:

1. The user must be in at least one of the admin or privileged groups.
2. The credential attributes must include:
   • AuthenticationLevel=2; AND
   • scope set as either usr:write OR usr:admin

For a description of the POP requires attribute, see Use credential attributes in authorization decisions .

Parent topic: Overview of the API Access Control