Security

This chapter explains the Demantra security mechanisms.

This chapter covers the following topics:

• Data Security
• Feature Security
• Other Security Features
• Program Groups
• Configuration Notes
• Password Policy

Data Security

Demantra data is secured as follows:

• The data is partitioned into components, which generally correspond to organizational roles, which can overlap. Each component has an owner, who acts as the administrator and who can create additional users. (See “Creating or Modifying a Component”.)

• Each user is authorized for one component. In addition, you can further restrict a specific user's access to data by applying filters so that the user can see only specific level members as well as only certain series.

• Users can belong to groups, and group members can collaborate, inside or outside of workflows. When a user creates a note, he or she can control access to that note by user or by group.

The following table summarizes how Demantra controls access to data elements.

Data Element	Options	Controlled by Component	Controlled by User Group	Controlled by User ID
Series	Visible or not visible	Yes	No	Yes
Series indicators (which indicate the presence of a note or promotion within the worksheet table.)	Visible or not visible	Yes	No	No
Levels	Visible or not visible	Yes	No	No
Level members	Full control, including ability to delete members Read/write existing members Read existing members No access	Yes	No	Yes
Units of measure	Visible or not visible	Yes	No	No
Indexes and exchange rates	Visible or not visible	Yes	No	No
Notes	Similar to level member options	No	As specified by creator of note

It is useful to remember that each user of a component sees a subset of the data associated with that component. You cannot give user access to data that is not contained in the component.

Components

For more information about components see: Creating or Modifying a Component

Each component has the following properties:

• Series, levels, units of measure, indexes, and exchange rates. For each level, you define permissions that the users have for the members of that level. The choices are as follows:

  • Full control, including ability to delete members

  • Read/write existing members

  • Read existing members

  • No access

• An owner. This owner acts as the administrator of the component.

• Possible additional users, created by the owner. The owner can also further restrict data access for particular users.

Users

User details are defined using the Business Modeler (Security > Create/Modify User). For more information about users see: Creating or Modifying a User

For users, you can specify the following details:

• Overall permission level, which can enable the user to log onto Demantra administrative tools and modify the component.

• Series that the user can access, generally a subset of the series included in the component.

• Optional permissions to control which level members the user can see and edit. The choices are as follows:

  • Full control, including ability to delete members

  • Read/write existing members

  • Read existing members

  • No access (the members are filtered out entirely for this user)

• Group or groups to which the user belongs.

User Groups

For user groups, you can specify the following details:

• Which users are in the group.

• Whether this user group is also a collaboration group (for use by the Workflow Engine).

• Whether users of this group can log into the Workflow Editor.

Security for Deleting Members

Most level members are created by integration and it would generally be undesirable to delete them. Most users, therefore, do not have delete access to these members. The exception is a user with System Manager permission; see “Permission Levels”.

Level members can be created directly within Demantra (through Member Management). For any these members, the user who created the member has permission to delete it.

Data Security at Higher Levels

When a user views data at an aggregation level that is higher than where the permissions are set, it is necessary to resolve how to aggregate editable members and uneditable members. Demantra uses the following rules:

• If all lower-level members are editable (either as read/write or full control), the member is editable.

• If some of the lower-level members are visible but read-only, the member is not editable.

• If some of the lower-level members are not visible, those members are filtered out and do not affect the aggregation. The upper-level member may or may not be editable, depending on the preceding rules.

Feature Security

Demantra features are secured as follows:

• Permission levels control access to administrative tools and to menu items. Demantra provides four predefined permission levels that you can customize. You can control access to all of the Demantra menus:

  • Menus on the Collaborator Workbench menu bar

  • Menus on the DSM menu bar

  • Menus on the Promotion Effectiveness menu bar

  • Menus on the Demand Management menu bar

  • Right-click menus associated with each level in your system

• You can also control access to all the same menu items at the group and user ID level.

For convenience, you control access to individual menu items, to predefined collections of menu items, or to your own collections of menu items (your own program groups).

Permission Levels

Demantra defines four permission levels, as follows:

• System Manager

• Supervisor

• Power user

• Casual user

The table below shows the default rights for these four permission levels. Note that only the System Manager has a different set of permissions from the other three. However, users with the System Manager permission level can utilize the Collaborator Workbench Administration tool to modify the access restrictions for specific menu items, or sets of menu items, thereby changing these defaults. See the section Specifying Permissions for Menu Items.

Permission Level	Business Modeler – login / change pwd	Business Modeler – All Menus	Collaborator Workbench Administration tool	Collaborator Workbench - view public and own worksheets	Collaborator Workbench - view all worksheets	Demand Planner - System menu
System Manager	X	X	X	X	X	X
Supervisor	X	-	-	X	-	-
Power User	X	-	-	X	-	-
Casual Supervisor	X	-	-	X	-	-

Permission Hierarchies

In order to understand how Demantra determines a given user's access to a given menu item, it is necessary to understand the permission hierarchies and how Demantra combines them.

Demantra has two independent permission hierarchies. In the first hierarchy, each component includes groups, and each group includes users. A user can belong to multiple groups, provided that all those groups belong to the same component. In the second hierarchy, each component includes four permission levels, and each user has one permission level.

Explicit and Implicit Permissions

In Collaborator Workbench you can display or hide any menu item. You can also display but disable a menu item, which can provide a useful clue about advanced features that are available to other users. Each permission is either explicit or implicit (inherited).

Note: For more information see:Logging into the Collaborator Workbench Administrator.

You define permissions in an expandable hierarchy like the following. For now, let's focus on the three check boxes:

The following table describes how to use these check boxes:

Desired outcome	Hidden	Disabled	Inherited Permission
Menu option is explicitly hidden	Checked	Irrelevant	Unchecked
Menu option is explicitly displayed but disabled	Unchecked	Checked	Unchecked
Menu option is explicitly displayed and enabled	Unchecked	Unchecked	Unchecked
Use implicit permissions for this menu item	Unchecked	Unchecked	Checked

How Demantra Combines Multiple Permissions

For a given user and a given menu item, Demantra checks for all the following permission descriptions:

• For the component

• For each group to which the user belongs

• For the permission level that the user has

• For the user ID

• For each program group to which the menu item belongs

To determine whether a user has access to a given menu item, Demantra searches for and combines the permission descriptions as follows.

1. Demantra checks to see if the user has an explicit permission setting (for a given menu item). If so, that setting is used, and all others are disregarded.

2. If the user does not have an explicit permission setting for a given menu item, then Demantra looks at the settings for the groups to which the user belongs, the permission level that the user has, and each program group that the menu item is in. Here, the following rules apply:

   • An explicit permission takes precedence over an implicit permission.

   • Among explicit permissions, the most liberal permission takes precedence.

   • Among implicit permissions, the most liberal permission takes precedence.

3. If no explicit permission setting for the menu item has been found so far, then Demantra uses the permission setting at the component level, if any.

4. If there is no setting at the component level, Demantra displays and enables the menu item.

See Also

“Data Security”

“Specifying Permissions for Menu Items”

Other Security Features

Note the following additional security features:

• Assigning a user to a user group that is flagged as a 'Collaboration Group' provides access to the Workflow Manager.

• After adding a user to a Collaboration Group, the Web server must be restarted before that user can access the Workflow Manager. For more information about User Groups see: Creating of Modifying a User Group

• A user with the System Manager permission level can see all public worksheets and all private worksheets. Users with lower permission levels can see all public worksheets and all private worksheets created by themselves.

• A user with the System Manager permission level can see the System menu in the desktop Demand Planner, in addition to the other menus.

• Any user can log onto the Business Modeler. If the user's permission level is lower than System Manager, the user can only change his or her own password, as documented in the user guides.

Program Groups

For more information about Program Groups see: Defining a Program Group

Redefining a Program Group

Deleting a Program Group

A program group is a collection of menu items, typically related to each other in some way. You create program groups so that you can easily control access to all the menu items in the group.

Demantra provides several predefined program groups, for convenience. These program groups contain only menu items from the right-click menus.

Program group	Menu items in this group, by default
Add	New member right-click menu option for every level in the system.
Edit	Edit member right-click menu option for every level in the system.
Delete	Delete member right-click menu option for every level in the system.
View	View member right-click menu option for every level in the system.
Copy	Copy, Paste, and Paste from Clipboard right-click menu options for every applicable level in the system. (Note that this option is available only for promotional-type levels.)
Open	Open and Open With right-click menu options for every level in the system.

Configuration Notes

The following table summarizes the Demantra security tools.

Tool	Purpose/Notes
Components > Open/Create Component option*	Creates components, which are usually created as part of basic implementation.
Security > Create/Modify User option*	Creates users and configures all information except for access to menu items.
Security > Create/Modify Group option*	Creates user groups and configures all information except for access to menu items.
Collaborator Workbench Administrator	Controls access to menu items; defines program groups.
*These options are in the Business Modeler.

Password Policy

You can set up Demantra to enforce password policies and ensure that passwords are well-formed and are changed frequently. By default, password policies are not enforced. To enable password policy verification, an administrator must modify the system parameter PasswordRulesEnforcedGlobal (see System Parameters).

Once enabled, the password polices are:

• Password length must be 8 to 12 characters.

• At least one character must be in UPPER CASE.

• At least one digit or special character must be used in the password.

• At least one digit or special character must be used in the password.

• Password should NOT be a Security Dictionary Word (please contact your administrator for details).

• Password should NOT be the same as User name.

• Password should NOT be the same as current password.

If a user attempts to create a new password that does not follow these policies, a message notifies the user of the password policies.

If the user attempts to login and fails, a message similar to the following appears:

The number of tries allowed by the password policy is determined by the system parameter “AccountLockoutThreshold”. (see System Parameters).

If the user is locked out because of too many failed attempts, the following message appears:

An administrator can unlock the user’s account by logging into Business Modeler, navigating to Security > Create/Modify User, and then deselecting the Locked check box.

If an administrator explicitly locks a user’s account, a different message appears, saying that the account is locked and to please contact your system administrator.

Note that this locking applies to Collaborator Workbench, Workflow Manager, Administrator Login, Demand Planner Web, Dynamic Open Link (DOL) , Demantra Anywhere.Locking does not apply to the Business Modeler, Member Management, or Chaining Management.

When a user’s password expiration date is within 10 days, a message displays prompting the user to change his password.

For more information see these system parameters:

• PasswordHistoryCount

• PasswordRulesEnforcedGlobal

• AccountLockoutThreshold

• AccountLockoutDuration

• PasswordResetTime