WAAE EEM as-group Policy Usage Example
Article ID: 36614
Updated On:
Products
Issue/Introduction
When WAAE jobs contain a group attribute, as-group EEM policies can be used in conjunction with as-job policies to control access to the jobs. In this example, there is a large group of jobs where the names all begin with the characters HR that are divided into subgroups using the group attribute. The requirement is for user "joe" to have read-only access for all of the HR jobs while also having execute access for HR jobs that have the group attribute set to "HR_group1". We will use the WAAE instance name "ACE" for this example.
Resolution
Instructions:
When an EEM authorization request is sent for access to a job that has a group attribute, both as-job and as-group policies are checked before granting the requested access. This type of authorization check can be diagrammed like this...
The first policy check that is performed is against the as-job resource class. There must be an as-job policy in place the grants the requested access to the user before the request will move on to the as-group check. If there is no as-job policy that allows the requested access, the request is rejected. Since user 'joe' needs read access to all HR jobs and will also need execute access to one subgroup of the HR jobs, the as-job policy will need to grant both read and execute to user 'joe' for resource 'ACE.HR*'.
With the above as-job policy in place, the request will be allowed to move on to an as-group policy check. This is where the access can be fine tuned to only allow execute on jobs belonging to group 'HR_group1'. There will need to be a separate policy for each of the subgroups defined within the set of HR jobs. The resource for each policy would be "ACE.<group_name>". The user "joe" will need to have read access granted in all of the subgroup policies to maintain the read access established at the as-job level. Without this, a read request would be denied at the as-group level. In addition, user "joe" will also need to be granted execute access in the policy containing the resource "ACE.HR_group1". User "joe" will now have read-only access to all HR jobs but also have execute access to jobs in subgroup HR_group1.
Notes:
WAAE resource classes are set to use a "best match" evaluation algorithm. This means that the policy that ultimately dictates access to a requested resource will be one that most closely matches the resource name in the request. Because of that, the default policies created during the install become obsolete once new policies are created that have more detail in the resource. In order to maintain users that have full access to all jobs, it is best practice to include any admin-level WAAE users in all new policies and grant full access for these users to the resource in that policy. In the above example, an admin user would need to be given full access in the as-job policy and all of the as-group policies. By doing this, inadvertent denials to admin-level users can be avoided as new policies are created over time.
Also, the example above focuses on a specific user. However, the identities can also be set to groups instead of individual users. The logic remains the same.
Feedback
