Umbria Security Model

Umbria Security Model

The model was developed with professional services firms in mind

Umbria provides for a role role-based model that works with the structure of the common groups and roles found within those organizations. It’s a complex, yet powerful, security model that makes it possible to define security on different levels of security objects including entity, group and module.

Basic Security Objects

Umbria uses the following security objects:

      • Entity
      • User
      • Group
      • Permission
      • Role
      • Module
      • Access Control List (ACL) – list of rules used to determine allowed security level on entity.

 

Entity

An entity represents a target security object. This can be a user, employee profile, client profile, matter profile or invoice.

User

A user represents a physical person who has access to the system. User experience varies based on the rights assigned to that user for a particular entity. For example, there are some matters that user has access to and there are matters where that users is explicitly denied access.

Group

A group is a collection of entities. Group examples are clients, vendors, public matters, confidential matters, administrators, partners, among others.

Some groups, such as administrators or partners, hold user objects and these groups are called user groups. User groups are used heavily in the Umbria security model.

A special type of user group is a personal user group. For each user, a group is created with the same name and only that user as a member. If there is a user called John Doe, there will be John Doe group, too. This kind of group is used for granting or denying rights for particular users.

Permission

For example, the permission CLIENT_STATUS_CHANGE enables the user to change a client’s status. The permission itself does not say to which user or which client it relates to, it’s simply about the action of changing the client status.

Role

A role represents a logical set of permissions. Roles are given to the users to enable various access levels to different user types.

For example, the Administrator role may include a broad set of permissions and the Employee role may have only basic access permissions.

Permissions are never assigned to users directly; they are always assigned to roles first. If a user has two roles, permissions from both roles are granted to that user, unless one of the roles is pessimistic

Pessimistic Roles

Pessimistic roles are special type of roles which do not mix with optimistic roles. Pessimistic roles get precedence when combined with other roles.

An example of this type of role is the ethical wall role, which is given to a lawyer who has worked on the same matter in his previous engagement. Even if the target matter is public, that lawyer will have only permissions included by ethical wall role.

Module

Module-level security is used to define global user permissions on each of the modules within the Umbria platform. These include Umbria, Litigator and Administration.

Access Control List (ACL)

An Access Control List (ACL) is a special type of security object which brings together entity groups, user groups and roles.

The Access Control List is represented by a set of rules and can be attached to a certain entity or a group of entities.

Each access rule allows or denies a certain group of users. An allow rule also specifies a role (set of permissions) granted to the user group.

Example: Confidential Matters ACL

Action

Allow

Allow

Deny

User (Group)

Administrators

John Doe

Lawyer X

Role

Administrators

Accountant

N/A

Access control lists can be applied on an entity or group level. Entity ACL defines rules that apply to that entity only and the ACL defined on a group is applied to all members of the group (all confidential matters in this example).

Implicit and Explicit Access Control Lists

Explicit ACLs are created by the users in Umbria administration. They are used to define global security policies and add exceptions related to particular groups or users.

Besides explicitly assigning an ACL to an object, users are allowed to access based on some implicitly defined rules.

Implicit rule examples:

      • Matter team members get access to the matter object.
      • The user who created a matter gets Owner role implicitly.
      • A matter’s invoices inherit the same security model as for the matter.
      • A user gets Owner role on its own profile.

 

For example, to allow lawyer X to access all confidential matters, we would create an explicit access rule for that. If lawyer X joins a matter team, a rule for accessing that matter will be added implicitly and should not be created manually.

Combining Access Control Lists

Access control rules can be defined on the entity level, group level or implicitly. Rules defined in different places are combined and act as one comprehensive ACL.

For example, Matter X is set to be confidential, it belongs to the litigation practice group and lawyer X is the responsible lawyer. The resulting ACL would look like this:

Action

User (Group)

Role

Confidential Matters ACL

Allow

Allow

Administrators

John Doe

Administrators

Accountant

Litigation Matters ACL

Allow

Lawyer X

Lawyer

Matter X ACL

Allow

Lawyer X

Responsible Lawyer

In this example, Lawyer X gets two roles, Lawyer and Responsible Lawyer. This means that he gets permissions from both of these roles.

How Everything Works Together

After users are added to Umbria, they are assigned to different user groups, such as Everyone, HR, IT, Partners, Lawyers, Practice support groups, etc.

On the other side, all entities in Umbria are also assigned to groups, such as Public Matters, Litigation Matters, Employees, Clients, Vendors, Public Matters, Confidential Matters, etc.

Access to an entity by a particular user is determined by the available ACL for that entity and all user groups to which that user belongs. The resulting entity ACL is made up of the following:

      • ACL rules defined just for that entity (if such exists)
      • ACL rules defined on all groups to which that entity belongs

After the access control list is compiled, it is cross-checked with the list of groups to which that particular user belongs. If there is a rule denying any of the user’s groups, the user is denied. If there are no such rules, Umbria looks for a list of allowed user groups and corresponding roles. If there are no such groups, the user is denied, otherwise the user is granted one or more roles on the entity.

Security and Search

The integrated search feature in Umbria obeys these security rules, meaning users are able to find only objects which they are allowed to see. The obvious method to implement such search features would be a two step search. In the first step, all results matching user-given criteria would be found, and then, in the second step, these results would be filtered according to the security rules. The opposite order of filtering would also work. The problem with this approach is that potentially very large number of objects should be checked in order to get results. In Umbria, a different approach is used. Security data is collected in the indexing process and embedded to full-text search index. This approach has both advantages and disadvantages.

Advantages: 

      • Search is very fast
      • No third-party search engines are required, only SQL Server full-text search capabilities are used.

Disadvantages: 

      • Search performance decreases if the user belongs to a large number of groups.
      • There is an upper limit on number of groups that user can belong to, which is a SQL server limitation.
      • Group level ACL changes require security updates for large number of objects
      • Search is able to return only a yes or no answer for a particular object. A full security check is not performed for each result. The full security check occurs when the user clicks on the object.
      • SQL server full-text daemon is asynchronous and introduces an indexing delay (up to 4 seconds if server is not under load, or even more if server is under pressure.)

 

Advanced Topics

 

Auto-Generated Groups

Some groups are auto-generated, such as:

      • Each user gets its own user group.
      • Each matter type automatically gets its own group (Litigation, Transaction) and all matters of that type are implicitly joined to that group.
      • Each department and practice area gets its own group and all members are joined automatically.

 

Rule-Based Group Membership

The group concept is heavily used in the Umbria security model. To ensure that all entities belong to the groups to which they are supposed to belong, the concept of implicit group membership is introduced. Implicit group membership works by defining a set of rules for joining groups.

Some example rules include:

      • If the person is an Employee, add the Person to the All Employees group
      • If MatterType is set to Litigation, add the Matter to the Litigation Matters group.
      • If MatterType is set to Litigation, add the Matter to the Litigation Matters group.

 

Each rule is composed of three fields:

      • Condition (implemented using an integrated JavaScript checker)
      • Entity
      • Target Group

These checks are made when the entity is indexed.

Click this button to read or download the PDF file

Want to learn more about Umbria?

Read more about Umbria from our product page.

Learn more

Check our related articles

Share
Tags: