This chapter explains the Demantra security mechanisms.
This chapter covers the following topics:
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.
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.
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.
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.
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.
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.
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.
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:
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 | - | - |
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.
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.
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.
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.
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”
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.
For more information about Program Groups see: Defining 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. |
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. |
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