Security Design Best Practices

Follow these best practices to design a security model that effectively serves all combinations of your products and personas.

A well-designed security model is scalable, adaptable, and requires minimal maintenance. To avoid major security overhauls as your solution grows, design a flexible security model that supports various user roles and product tiers.

Future proof your security model design ahead of any configuration

Carefully consider your user personas before configuring the security model. Go over as many use cases as possible, including personas that are relevant to your initial solution and those you may target in the future. We recommend that you divide users into functional user groups based on your planned Visier deployments, such as general users, managers, executives, and recruiters. This minimizes future redesigns and the changes to your initial setup in the future. By defining personas, you can figure out what data and content they need to access how many permutations of each may be required.

Security should always be inherited from the parent administering tenant

Remember to define security at the overall administrating tenant level and push it down to all external customers. Doing so allows scalable security across all customers. Defining security for each customer individually creates maintenance, troubleshooting, and editing challenges. To simplify maintenance, we recommend that you design your security model and permissions so they can be reused across all customers.

While inheriting permissions from the parent tenant is best practice, you might need to create separate permissions to secure attributes that are unique to the child tenant, like custom attributes. If security access is required on these attributes, you can design child-level permissions for those attributes on the child tenant exclusively.

Dynamically look up a matching employee record against the user’s profile

Make use of dynamic look-up to automatically assign users to user groups and population access. Dynamic look-up matches an attribute on the user's profile to an employee record. For more information, see Set up Dynamic Look-Up. This option appends the Employee ID to the user profile, making it possible to dynamically assign users into User Groups on the basis of the user’s employee attributes. Furthermore, this creates the possibility of dynamically assigning population access based on the Employee ID. For example, giving supervisors access to their own reports.

Segment your users into distinct user groups

Again, when creating user groups it is important to understand all of the possible user personas. Data held by the employee, such as the employee ID or the employee’s email address can be used to determine a user’s membership in that group. This eliminates the need for manually provisioning users into a user group. Multiple permissions can be added to groups which further reduces the need to manually assign permissions to users.

Onboard attributes that can be used to segment users into groups

Consider loading data that will help you dynamically assign users to user groups. This data may not be apart of the standard set of employee attributes and is likely to reside within the security model that your human resources information system (HRIS) uses. Append these attributes to employee profiles so you can use them in user group security filters.

Set up permissions for use in multiple user groups

Define generic permissions for maximum reusability. Limit the number of permissions that require access to the same set of subjects, events and related objects. Avoid creating permissions filtered to specific organizations or locations. If filtering is required for specific data access, it should be defined dynamically, where possible.

Always define data access sets and security filters outside of permissions

Data access sets should always be referenced and not exclusive to a specific permission. Update data access sets globally so changes are automatically applied to any permission the data access set is used in. This means you only have to make the change once. For example, create a data access set that will be reused across products. If premium tier access to data attributes is shared across products, maintaining one data access set ensures alignment across all permissions referencing the data access set. You can also apply this best practice when defining security filters.

Create a baseline data access permission for use by all active users

Create a baseline data access permission for an All Users group. This allows you to enable users quickly with minimal access to the solution. When defining a standard baseline data access permission, it is important to safeguard sensitive attributes. A common example of this is to create a baseline simplified HR permission, which only grants access to basic attributes, such as Organization and Location. The best practice is to only grant access at the aggregate level to this permission. The addition of detailed view, sensitive attributes should be gated by a detailed permission which would need to be additionally assigned to the user.

Create separate permissions for data access, content packages, and capabilities

Creating separate data access permissions, as well as capability permissions enables the reusability of the permissions across multiple user groups. How you define each permutation will need to be closely aligned to your user personas, content, and tiering strategy for your products. You may need multiple data access permissions and capability permissions if you have multiple permutations of products and tiers. The key is to minimize the need for replicating permissions that combine all these pieces together ensuring the singular permissions can be reused for different groups of users.

Onboard hierarchy head data into organizational hierarchies

Onboard hierarchy head information for all your organizational hierarchies whenever feasible. The Organization Head attribute is an Employee ID that would head up an Organization ID within an Organization Hierarchy. This attribute can be leveraged by the security model, dynamically, to assign population sets to users that head up specific organizations or cost centers.

Leverage dynamic security for assigning users into groups

Never manually assign users to groups. Users should always be dynamically assigned to user groups through security attributes held by the employee via API or via HRIS attributes held by the employee. Manual assignment will lead to human error and can have serious consequences if not maintained.

Define inclusion security filters instead of exclusion

When defining security filters and population access, use inclusion when filtering. This also applies when defining user assignment in user groups. Inclusion ensures users get access to the intended population and assigned to the correct user group. Exclusion can lead to unintentional data access. For example, you could potentially grant users access to future departments that users shouldn't have access to.