This article continues our series on best practices and tips for App Developers and Administrators. The previous articles in this series can be found here:
This is a general reference article. For security questions specific to your environment, contact your Onit representative or ask a question on our forum.
Custom Roles
Custom roles are an easy way to grant users permissions on a Record. Below is a reference table for all roles in the Onit system and an explanation of their permissions. Creating a custom role allows App Builders to grant the exact permissions users should have on a Record.
NOTE: The "Create Transaction" checkbox has a somewhat misleading label. This box covers a particular use case: if you have an app where the Authentication Level is set to Restricted (so regular users can't launch it) and you want a user group whose users can launch the app but don't want them to see every transaction in the app, you can create a custom rule to use in the user group with this box checked.
Note that checking this box is not required to allow users with this role to launch an ordinary app.
| Role Name | Role Permissions |
|---|---|
| Administrator: A participant who needs admin privileges on the Record. |
|
| Approver: A participant who needs to take action on the Record. |
|
| Requester: The participant requesting/submitting the Record. |
|
| Read Only Approver: A participant who needs to take action on the Record, such as approve or reject, but does not need to edit the details, change the Phase, or edit or remove a participant. |
|
| Read Only Requester: The participant requesting/submitting the Record. They can access the Record and view its details, but cannot edit details, change the phase, add participants, see comments, make comments, or view the history. |
|
| Read Only Reviewer: A participant who will need to review the Record but does not need to approve, reject, or change the Phase. |
|
| Reviewer: A participant who will need to review the Record but does not need to approve or reject it. |
|
| Requester (Limited): The participant requesting/submitting the Record. However, they will not have access to the transaction after submission. This user can still receive email notifications but cannot view the transaction details in the application. Note that the Requester will still be added to the corporate user list even though they never access the transaction. | |
| Custom: An App builder can configure a custom role to use in their App. The custom role can have any of the previously discussed permissions (e.g., admin rights, edit rights, read-only rights, etc.). |
Inherited Roles (Security Chains)
For instructions on how to create an inherited role, see the Crash Course on Security Tutorial.
Inherited roles allow for an organic evolution of user access based on related Records in a "controller" App.
For example, Acme Corp. created a new Record named Coyote Injury Waiver. Using the related Acme-Legal-Teams "controller," App Onit can grant appropriate permission without manually assigning permission to users.
The related Acme-Legal-Teams "controller" App works to determine which users should have access to each Record through inherited roles.
When the Coyote Injury Waiver Record is created, a Business Rule relates it to the Coyote Legal Team Record in the Acme-Legal-Teams App. Once the Record is related, all Coyote Legal Team Record users are granted access to the new Record.
NOTE: Inherited roles start to struggle around 50,000+ Records, so keep an eye on how large your environment becomes.
How do User Groups relate to Inherited Roles?
Imagine two Apps, App 1 and App 2.
App 2 has a relation to App 1 with an inherited role. So, if John participates in a Record in App 1, he will also see any related Records in App 2.
So far, so basic. Now, imagine that App 1 has a user group. John isn't a participant in the App 1 Record; he sees it because of the user group. Does John get permission to see the related App 2 Record via the inherited role?
Yes. Anyone with permission to view the App 1 Record also gets to partake of the inheritance.
Known Private User Group Bug: We are aware of a bug that could prevent access to private Records for users in multiple private user groups.
Consider a user who belongs to Private Groups A and B. Group A cannot access private Records, but B does. If Private Group A was created first, the user would not have access to any private Records. If Group B was created first, the user would have appropriate access to private Records.
User Groups vs. Group Preference vs. Security Groups
We often see confusion between the items mentioned below, which are frequently used interchangeably due to their overlapping terminology. To clear up any confusion, here is a definition and use of each:
- User Group - At the /admin level, User Groups provide role-based access control (RBAC) to records. Users are added to User Groups, which are then associated with Apps under the Security section on the App’s Advanced Designer page. User Groups grant users access to all Records in an App, provided that the Records are not marked as private. If there are Records marked as private, they will only be accessible to participants of that Record and to users associated with a User Group that has Private Access. Private Access User Groups are created the same way as regular User Groups
- Group Preference - a Group Preference object controls what users see on the landing page (called a Suite) when they log into Onit. It spells out the main Suite and Dashboard they see, as well as defines the sidebar items and plus button items they have access to in the Suite. Though this is not considered security, it provides a small bit of view-layer security in that users who cannot see certain Apps in the sidebar or cannot add records through the plus button items do not know they exist.
NOTE: Users can gain access to other Suites if they are given the link to them. This is why Group Preferences is not directly considered security.
- Security Groups—This App manages Record access through Inherited Role chaining. Security Groups are usually set up based on the system's taxonomy of Records (for example, the area of law and matter type of Matter Records), and users are added as participants in these Security Group records. Because they inherit access to the Matter Records to which these Security Groups are linked, this provides a finer-grained control of Record access than User Groups.
Limit Users to a Single User Group
Users should be limited to one User Group to ensure maximum effectiveness and legibility in your build. Stacking User Group permissions can make it hard to debug security issues in your environment. Instead of creating and assigning new groups, consider how an existing user group could be modified.
Tab Level Security
Tab-level security is an effective and inexpensive way of preventing users from seeing tabs based on their Role. When designing an App, assign a Role to a specific Tab within the App Builder, and only that Role can view the Tab. The tab will not show in the DOM of users with incorrect roles.
NOTE: Remember, a Field whose Show on Dashboard property is selected will still be viewable by anyone accessing the Record on the dashboard.
Tab Level Security and Hidden Conditions
Suppose you have two Fields, field_a and field_b; field_b has a Hidden Condition that relies on a value in field_a.
On the Launch screen, both Fields are displayed together, and when the correct value is in field_a, field_b appears.
However, on the View screen, field_a is on a Tab that some users cannot access. Even though the value in field_a that would make field_b appear exists, those users who do not have access to that Tab can no longer see field_b, as though field_a did not exist.
This is due to Tab-level security. Since the user does not have access to the information on the Tab, the hidden condition will no longer evaluate properly, even though it worked on the Launch screen.
If you ever encounter a case where your hidden condition works on one screen but not the other, this would be a good troubleshooting point. The general fix is to move field_a to a Tab that all users can access.
Think About Security Early and Often
Before starting your project, consider the security of your environment. Some security requirements, such as read-only security, are possible in other platforms that are not possible in Onit.
Often, security will fall by the wayside, and a very brittle ad hoc security system will develop over time. For example, Company A decides that simply restricting Record access to participants will be enough security to keep their Records safe. However, when an employee leaves Company A, they now have a participant who should no longer have access to sensitive Records. The old user must be manually removed from hundreds of Records and replaced with another user.
Could you counter this by planning your security strategy? A good place to start is with our Crash Course on Security tutorial.
Test with Real Size Data Loads
Always test your environment's security with real-size data loads. A security system could work perfectly with only a few Records but might have trouble with thousands of Records and users.
Work with your Onit representative to simulate a large number of Records to test with.