Important: With version 1.6.0 we are introducing a new security mechanism to Vizlib Server called Security Rules Management. It's going to completely replace the current mechanism, so please read this article carefully.
Changes to Vizlib Server security
In previous versions of Vizlib Server, security was based on custom properties.
Streams - which were used with Teamwork (Collaboration) or Finance - had three levels of access: read, write and admin. Access levels were represented by a specific Custom Property value.
For example, if your write access custom property was named VZB_StreamAccess user, you had to set the value of that custom property equal to the stream you needed to access. These values could be configured using the Vizlib Management Console (VMC), rather than setting them up manually in QMC.
There was one huge limitation to that solution - if you wanted to fully control your access, and your users changed frequently, then your admins had to continually update VMC as well. And that was the key factor leading to the introduction of Vizlib Security Rules.
How to create new Security Rules
Security Rules can be defined in the VMC - there is a separate tab in the main menu (Figure 1).
Figure 1: Security Rules Menu
In order to create new security rules, click on the New Rule button. Security Rules consists of the following items:
- Description - User-friendly information allowing you to distinguish one security rule from another.
- Resource Type - Either Stream or Workflow.
- Resource ID - ID corresponding to either Stream or a Workflow
- Access Level - For Streams - Read, Write or Admin. For Workflows - Approver.
- Condition(s) - Logical condition describing when the security rule should be met.
Each condition consists of:
- Attribute Type
- Operator
- Value
Below, you can find a few examples of security rules.
Figure 2 shows a rule where Write access for a stream Access for Vizlib is only granted to users from the VlZLIB user directory.
Figure 2: Write Access
Figure 3 shows a security rule where Write access for a stream Sample Security Rule is only granted to users from the VlZLIB user directory or the userid administrator.
Figure 3: Sample Security Rule
Figure 4 creates a Group of conditions where Write access is granted to the users with the userid administrator or a user with the domain @vizlib.com.
Figure 4: Condition Group
Conditions
Each Security Rule may contain one or more conditions. By default, the security rule is created with only one condition but you can easily add more. There are several actions you can perform on a condition to group them in unlimited ways (Figure 5).
Figure 5: Conditions Menu
- Create Child Group - Creates condition group one level below. Imagine that you have condition A and B. Creating a child group on condition A would result in creating brackets around it (A) and B
- Move to Child Group - Considering condition (A) and B, the operation performed on condition B would result in (A and B)
- Move to parent group - Performing this operation while having (A and B) on condition A would result in A and (B)
- Move group up - Considering conditions (A and B) or (C and D), performing this operation on C would result in (A and B and C) or (D)
- Move group down - Works similar to the Move group up option, but in the other direction
What attributes are supported?
Conditions can be defined on following user attributes
- user id
- user directory
- name
- role
- custom property
- user attributes (stored within QRS)
User attributes which are dynamic and available only per session are not supported.
Where to inspect user access levels
Users with access to Vizlib Management Console can inspect user accesses as they did previously, inside either the Stream or Workflows tabs (Figure 6). One difference is that these screens are now read only - you can no longer assign access there.
Figure 6: Stream User Access
Migration from previous versions of Vizlib Server
If you had an earlier version of the Vizlib Server installed, a migration will occur during the upgrade. The migration will automatically create certain security rules for you, based on existing custom properties. This will allow you to safely upgrade without the need to take instant action - at the end of the migration all user accesses will remain intact. These security rules will look like the example below (Figure 7).
Figure 7: Update Security Rule
You will most likely want to review your security policies and replace automatically generated security rules with more flexible ones that suit your setup.