Role Based Access Control (RBAC)

RBAC in Benevia Core controls what each user can see and do by combining role assignments with responsibility definitions. You can define permissions at these levels:

• Entity (Table)
• Property or Method (Column)
• Record (Row)

Summary

These entities are used in RBAC.

• User: User has a list of roles. In many companies, a person wears multiple hats. In this case, the user will have multiple roles.
• Personal Access Tokens (PAT): A user can generate a PAT. This PAT will not have more permissions than the user. PATs do not have roles. Their permissions are determined by the responsibilities that are selected by the user.
• Role: A role defines a position in the company that a user has such as sales person, sales manager, administrator, purchaser, controller, etc. The role has a list of responsibilities.
• Supervisor role: A role can have a SupervisorId — the supervisor automatically inherits all permissions of the roles it supervises.
• Responsibility: A responsibility is a single function or work that a user can do in the software. For example, "Create sales orders", "View customer accounts", "Create customer accounts", "Manage accounts receivable", etc. Permissions are defined in a responsibility.

Resolution rules with overlapping roles and responsibilities

All responsibilities from the roles attached to a user will be used to determine permissions of Hide, Read, Write, etc.

Most permissive wins: Responsibilities such as View customer accounts and Create customer accounts will have permission settings for the same properties. View customer accounts will allow viewing the customer name, but Create customer accounts will allow editing the customer name. The most permissive setting is used. Therefore, if the user contains these two responsibilities, then he will be able to edit the customer name.

Default permissions: Entities, properties, and methods are restricted by default - you must grant access. Therefore if the user does not have a responsibility to view or edit the customer, then the user will not be able to see customers.

Example that adds responsibilities and sets permissions

[Logic]
public class ContactBL(Contact.Logic contact, IResponsibilityRegistry access)
{
    [RegisterLogic]
    public void CreateContactResponsibilities()
    {
        access.AddResponsibility("Enter individual", "Limited permissions for creating individual contacts", grant =>
        {
            grant.Entity<Contact>() 
                .CreateAndDelete()
                .Write(c => new {c.FirstName, c.LastName, c.PrimaryEmail, c.PrimaryPhone, c.MailingAddress})
                .Read(c => new {c.Website, c.Note});
            grant.Entity<Address>() 
                .View()
                .Write(c => new {c.StreetAddress, c.City, c.State, c.PostalCode});
        });
        access.AddResponsibility("View contacts", "View all contact information", grant =>
        {
            //...
        });
    }
    //...
}

Entity permission levels

Order is from least to most permissive. Giving view, create, or delete permissions does not grant permissions to properties except for Guid, Title, and the natural key.

• Hide: (Default) The entity and its properties cannot be viewed.
• ViewReference: The Guid, Title, and natural key property can be viewed. However, the user cannot view a list of this entity. The API fails when returning the list of all entities. This does not fail if a method is returning a list.
• ViewList: The full list of entities can be accessed.
• Create: The entity can be created and viewed in a list
• CreateAndDelete: The entity can be created, deleted, and viewed in a list

Property permission levels

Order is from least to most permissive:

• Hide: (Default) not visible in UI. The API rejects returning this value and filtering by this value.
• Read: visible, but not writable
• Write: full read and write access

Automatic entity permissions based on reference property permissions:

• When a reference property is set to Read, then the referenced entity is automatically set to ViewReference

  grant.Entity<Customer>()
    .CreateAndDelete()
    .Read(c => c.PrimaryContact); //Sets permission to ViewReference because the user needs to be able to see the contact
  

• When a reference property is set to Write then the referenced entity is automatically set to ViewList

  grant.Entity<Contact>()
    .View(); //Sets permission to ViewList
  

  grant.Entity<Customer>()
      .CreateAndDelete()
      .Write(c => c.PrimaryContact); //Contact entity is ViewList since the user has Write permissions to a Contact reference and therefore needs to be able to select a contact from a list.
  

Method permission levels

• Deny: (Default) The method cannot be executed.
• Allow: The method can be executed.

Learning path

#	Document	Description
1	End-to-end walkthrough	Complete example: define responsibilities, create roles, assign to users
2	Defining responsibilities in business logic	How to declare entity, property, and method permissions
3	Managing roles and assignments	How to create roles, assign responsibilities, and assign roles to users

<< Back to home page