Security Context

Custom security context files can be used to define your own security rules and/or overload security rules provided in the shipping product.  The key to identifying if you are adding new privileges or modifying existing ones is based on matching the secure object type, name, and action.  If those match an existing entry, then you are overloading an existing privilege.

Custom Security Context

To customize the security context, you should:

1. Do NOT modify the default file inside the aveksa.ear. 
   Modifying the security context file inside the aveksa.ear is not supported and you will lose your changes on upgrades, moving to other systems, or within a cluster.  By following the steps below you will keep your changes, they will be included in upgrades, and all nodes involved will see the changes.
2. Take a copy of it to your PC (to use for reference later) so you have the header format and you can see existing entries.
3. Create a new SecurityContext.csv file with the Header and a line for each privilege you want to add or modify or delete.
4. Save and upload the custom security file to the UI under Admin > User Interface > Files > Security.

New Privilege

A new privilege is defined when it has a unique secure object type, name, and action.  The product has an internal fixed list of security object types and actions it supports so adding your own won't have an effect (only introduce unique names).

If the following privilege is defined, then I might introduce a similar privilege with a different name.  This has the effect of adding to the existing security privileges for the secure object and action:

SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER

Application,Business Owner,Manage,,scope,,t_applications,business_owner=${id} and resource_type='A' and is_deleted='FALSE'

Application,Custom Business Owner,Manage,,scope,,t_applications,cas1=${id} and resource_type='A' and is_deleted='FALSE'

In the example above, we defined a new privilege that is going to look in the custom attribute CAS1 to determine if the logged in user should have the Application:Manage privilege.  I named this new privilege 'Custom Business Owner'.

To use the new privilege, upload the custom security context file using the 'Custom Security Context' section above.

Modifying Default Privilege

To modify an existing privilege, following the steps in the 'Custom Security Context' section above. Find the line of the existing privilege. In this example:

Change Request,Affected,View,scope,,,t_av_change_requests,scope.id in (selectchange_requests_id from t_av_change_request_details where affected_user_id=${id})

Modify the scope filter for the privilege and upload the custom security context file on the UI under Admin > User Interface > Files > Security.

Disabling Default Privileges

Should you want to disable an existing privilege, then you should follow the exact same steps as in the modifying default privilege, but provide a scope filter that is never true (For example: 1=0).

SECURE_OBJECT_TYPE,NAME,ACTION,IMPLICIT_HAS_QUERY,IMPLICIT_BS_CHANGE,IMPLICIT_BU_CHANGE,SCOPE_TABLE,SCOPE_FILTER

Change Request,Affected,View,scope,,,t_av_change_requests,1=0

Many people have incorrectly tried to modify the default security context file instead removing the physical entry all together.