Version

Argent WorldView 1.0A-1412-A And Later

Date

Monday, 1 Dec 2014

Summary

Argent WorldView implements product security by setting access privileges on Scheduling Engines and Queue Engines, for Active Directory users/groups

Security can be defined either explicitly or implicitly

If security is not defined anywhere, the product’s default policy is assumed

For a detailed description on how to set Argent WorldView security, see:

How To Set Security In Argent WorldView

Technical Background

As Argent WorldView integrates multiple Scheduling Engines and Queue Engines, the users who are logged in, can access the Jobs of all integrated Scheduling Engines and Queue Engines

To avoid such security concerns, Argent WoldView 1.0A-1412-A implements a security mechanism that allows setting different levels of access rights on the objects (Scheduling Engines and Queue Engines) for the Active directory users/groups

The three levels of access rights that can be set are:

On clicking the ‘Security’ button, from left panel,the ‘Security’ screen (JW12) loads

Active Directory Users/Groups can be assigned as the ‘System Administrator’ for Argent WorldView

The user who installs Argent WorldView will be the default System Administrator

The users set as System Administrators will have ‘Full Access’ on the product; regardless of any security set for that user explicitly

The users listed as System Administrators can set different access privileges for other users/groups of the Active Directory

A ‘Default Policy’ for the product can also be set here with one among the three options (Full Access, Read-Only or Denied) available

Click For Full Size

To set permission on an object, customers can use either pre-defined GSO policies or define access rights for explicit users or groups

a) Setting Security Using GSO

Assume a situation that the Payroll department users need to have Full Access permission on the Jobs under a Scheduling Engine SE_1, but the Sales department users should have only the Read Only access on it

Now, a GSO can be created with Full Access for the Payroll department users and Read-Only access for Sales department users

Click For Full Size

On assigning this GSO to an object, the Payroll department users will get full access and Sales department users will get read-only access on this object

Security can also be set on Queue Engines, so as to provide/restrict the user access permission to access that Queue Engine

The main advantage of creating a GSO is that, it acts as a security macro that can be reused anywhere in the Argent WorldView Web GUI

Click For Full Size

b) Setting Access Rights For Explicit Users/Groups

Access rights can be set for explicit users or user groups in Active Directory

In the above example, the two user groups can be added to set the Scheduling Engine security; one for the Payroll users with Full Access and other for Sales department users with Read-Only access

Click For Full Size

How Security Mechanism Works

All child objects will inherit permissions from its immediate parent object, unless overridden at the child level

If no policy is specified for any Scheduling Engine or Queue Engine explicitly, then the default policy of the product is assumed

Let us check how security works for a particular user, based on the security sets for him explicitly on a Scheduling Engine or Queue Engine

Consider a Scheduling Engine with three Queue Engines and the Default Policy of the product is set as Denied

In this case, the Scheduling Engine and all three Queue Engines will be denied by default for this user

Suppose, a Read-Only policy is set on the Scheduling Engine explicitly for this user, the default policy will be overridden and he gets Read-Only access on this Scheduling Engine

Also, all the three Queue Engines inherit the Read-Only access permission from the parent Scheduling Engine

If a Full Access permission is set for one Queue Engine, then, the user gets Full Access on this Queue Engine and the other two Queue Engines are Read-Only as they inherit the parent Scheduling Engine policy

The basic idea behind the working of a security on an object for a user/group can be generalized as follows:

• If the Queue Engine security is explicitly defined, use it

  If not, check the parent Scheduling Engine

• If the parent Scheduling Engine security is explicitly defined, use it
• If security is not defined anywhere, use the product default policy

Resolution

N/A