KBI 311786 Enhancement: Added Access Privileges For Active Directory Users To Obtain Product Security In Argent WorldView


Argent WorldView 7.0A-R3 and above


Thursday, 14 November 2019


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

Security for each engine can be defined either explicitly or implicitly

If security is not defined for a specific engine, the product’s default policy will be used

Technical Background

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

To alleviate any security concerns, Argent WorldView 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 and groups

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

Denied No access: the object will not be displayed to the user
Read-Only The object will be shown but can’t be modified
Execute-Only (No Admin Access) User may view all Scheduling and Queue Engines, as well as submit Jobs, hold or release Jobs, and rerun ended Jobs
But the user will be denied write access to administrative sections like Job Templates, Control Panel, and Security
Full Access Has read and write access to all functions

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

Active Directory users and groups can be assigned as the ‘System Administrator’ for Argent WorldView

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

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

These users can set different access privileges for other Active Directory users and groups

A ‘Default Policy’ for the product can also be set on this screen with one of the four following options available:

  1. Full Access
  2. Read-Only
  3. Execute-Only (No Admin Access)
  4. Denied


The Administration section is available only to the users with System Administrator privilege

Customers can use the following methods to set permission on an object:

  1. Pre-defined Global Security Object (GSO) policies
  2. Explicitly defined access rights for specific users or groups

Setting Security Using A GSO

Assume, for example, 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 Read-Only access on that engine

A GSO can be created with Full Access for the Payroll department users and Read-Only access for Sales department users, as shown below

On assigning this GSO to an object, the Payroll department users will have Full Access and Sales department users will have Read-Only access on this object

Security can also be set on Queue Engines to provide or restrict a user’s 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


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 or groups will be overridden

Setting Access Rights For Explicit Users/Groups

Access rights can be explicitly set for Active Directory users or groups

Using the above example, the two user groups can be added to the Scheduling Engine security screen, giving the Payroll users Full Access and the Sales department users Read-Only access

How The Security Mechanism Works

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

If no policy is explicitly specified for a Scheduling Engine or Queue Engine, then the default policy of the product will take effect

Let’s look at how security works for a particular user based on the security set for him explicitly on a Scheduling Engine or Queue Engine

For this example, we’ll use a Scheduling Engine with three Queue Engines and have the Default Policy of the product 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 the user will have Read-Only access on this Scheduling Engine

The three Queue Engines will inherit the Read-Only access permission from the parent Scheduling Engine, giving the user Read-Only access to the Queue Engines

If Full Access permission is set for one Queue Engine, then the user will have Full Access on that Queue Engine and the other two Queue Engines will still be Read-Only as they inherit the parent’s Scheduling Engine policy

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

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

    If not, check the security for the parent Scheduling Engine

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


Upgrade to Argent WorldView 7.0A-R3 or above