KBI 311123 Added Access Privileges For Active Directory Users To Obtain Product Security In Argent WorldView
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
Note:
The Administration section is available only to the users with System Administrator privilege
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
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
Note:
- Only one GSO can be assigned to an object at a time
- If a GSO is set on an object, the security set for the explicit users/groups will be overridden
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
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