Section 12.1    Password Policy

A password policy is a set of rules designed to enhance computer security by encouraging users to employ strong passwords and use them properly. The computer system will force users to follow the password policy. WIB™ Review has a strict password policy that is NIST compliant. For more information regarding the Password Policy please contact support@radixdata.com.

Section 12.2   Organizational Chart of Users, Groups and Roles

 

Section 12.3   Groups

A group of users are given access to work areas (projects/collections) that all need access to the same resources. Groups can be created based on individual users that all need access to certain resources, they can be created based on global groups (such as departments: accounting), business function (accounts payable or accounts receivable), or workflow process function (invoice approval).

Section 12.3.1                  Create a New Group

Using the Navigation Tree, select Users>Groups>Roles. Tabs for Users, Groups, and Roles contain tables that show the information related to each security level. Select the Groups tab to view a list of groups and the associated users and roles assigned to the Group. Select Add New to create a New Group. You can edit, delete, or view the group settings by highlighting the group and selecting edit, delete, or details, respectively.

Section 12.3.2                 Group Properties

Section 12.3.2.1            Access to PPI/PII

By default, access to PPI/PII is turned off for users, groups, and roles. To allow a group of users to access PPI/PII turn on the access.

Section 12.3.2.2           Group Name

Give the Group a name that is descriptive. A department (Operations), business function (Accounts Payable) or processing function (Reviewers) are examples of good group names.

Section 12.3.2.3           Group Role(s)

Roles define permissions (actions) that users assigned to that role can perform. A Role is defined at the workspace level and is restricted to performing actions when assigned to a group for work areas that fall under the umbrella of the group permissions.

Section 12.3.2.4           Group User(s)

Users can be assigned directly to a group. The user will keep the permissions granted to the user or the role the user is assigned to. The user will then be granted access to work areas under the group data policy. Users can belong to multiple groups. Users that are assigned to a role will also appear as members of a group when the role is added to the group.

Section 12.3.2.5           Group Security Policy

A group level security policy defines which work areas those roles or users assigned to the group have access to. Permissions for actions are defined at the Role or User level.

Section 12.3.2.5.1                Data Policy

A Group Data Policy grants access to work areas in the workspace. Roles can be inherited in the group policy OR can be defined separately. If a Role has a data policy defined the Role Data Policy overrides the Group Data Policy.

Section 12.4   Roles

A security role is a collection of privileges in a workspace. Users can be assigned to a role and inherit the permissions defined in the role. Roles can be added to groups and will be restricted to performing the actions defined by the role in the specific work area(s) defined by the group data policy. Roles can have overriding data policies. Refer to Security Policy for instructions on setting up a Role level data policy.

Section 12.4.1                  Creating a New Role

Using the Navigation Tree, select Users>Groups>Roles. Tabs for Users, Groups, and Roles have tables that show the information related to each security level. Select the Roles tab to view a list of roles and the associated users assigned to the role and the groups the role is assigned to. Select Add New to create a New Role. You can edit, delete, or view the role settings by highlighting the group and selecting edit, delete, or details, respectively.

Section 12.4.1.1             Access to PPI/PII

By default, access to PPI/PII is turned off for users, groups, and roles. To allow a group of users to access PPI/PII turn on the access.

Section 12.4.1.2            Role Name

Give the Role a name that is descriptive. A Role is like a job title. Examples include Administrator, Project Manager, Reviewer, Approver.

Section 12.4.1.3            Groups

You can assign a role to a group from the New Role or Edit Role Menu(s). The Role will inherit the data policy of the Group it is assigned to unless you configure the data policy for the Role. A Role Data Policy will override a Group Data Policy. Refer to Creating a Security Policy for instructions on setting up a Role level data policy.

Section 12.4.1.4           Users

Assign Users to the Role. This allows you to set the policy one time for many users. You can set up a separate policy for users. Refer to Security Policy for instructions on setting up a User Level Policy.

Section 12.5   Users

A user is associated with an access license (UAL). They are not shared by Users; each User must have their own UAL. Once a User has their own UAL, it does not matter how many machines they log in from. Users are assigned a Role and are part of a Group. Users can have a separate Security Policy that limits or grants added privileges beyond their defined Role or Group.

Section 12.6  Creating a Security Policy

Administrators can create a security policy for a user or a role. Components of a Policy include the level (user/role), accessibility settings (group/user/role), and action settings. Each Security Policy must address all areas of WIB Review: who can access each area, what actions are allowed and to whom or which role/user the policy applies.

Section 12.6.1                  Policy Name

Name the policy in such a way that it describes either the role or an individual user’s job function. It is suggested the Policy Name is Different than the Role or Username as staff and responsibilities change over time and you want the Policy to reflect the functionality of the policy which will persist over time. You can change the name of the policy.

Section 12.6.2                 Assign the Policy

You must assign the Policy to a specific user or a role. If you access the Policy from a Role or User, the Policy Summary will populate with the User or Role the Policy is assigned to.

Section 12.6.3                 Security Policy Stepper (Roadmap)

The Security Policy Stepper guides the administrator through the process of defining a Security Policy.

Section 12.6.4                 Security Policy Definition (SPD) (Roadmap)

The Security Policy must define which actions roles and/or users are allowed to perform for all the features.

Section 12.6.4.1           Dashboard SPD

Section 12.6.4.1.1                Dashboard Page Accessibility

You can restrict access to the Dashboard. If you do not want the user or a set of users, referred to as “users”, with a particular role to access the Dashboard in its entirety, then turn off Page Access. If they have access, you must define what actions they (the users) are allowed to perform.

Section 12.6.4.1.2               Dashboard Page Actions

Each Page in WIB Review has actions that can be performed that are specific to the page or a section of the page.

Section 12.6.4.1.2.1    View

Users are only allowed to view the dashboard. They cannot customize the dashboard.

Section 12.6.4.1.2.2    Design

Allows the user to customize the dashboard. Report Tiles can be added to the dashboard, resized, and organized to the user’s preference. Refer to Reports to create and save a report. Users can add private or public reports to the dashboard.

Section 12.6.4.1.2.3    Print

Users can print a dashboard to a PDF for sharing.

Section 12.6.4.1.2.4   Export

Users can export a dashboard to a PDF or to an excel spreadsheet. The report metadata and the chart can be exported. The chart is exported as a picture and will no longer dynamically update if any metadata supporting the report is changed.