Tymly RBAC overview

The core Tymly package ships with built-in Role-Based Access Control (RBAC) (via the core RBAC service). Within Tymly, RBAC is used predominantly to limit user-access to state machines.

Concepts

Tymly uses standard RBAC concepts...

Role-based access control (RBAC) is a method of regulating access based on the roles of individual users within an application. In this context, access is the ability of an individual user to perform a specific task, such as view, create, or modify information. Roles are defined based on job competency, authority, responsibility or any other established condition.

Role

A Role is nothing more than a unique name (and other metadata such as label, description etc.) to which zero-or-more related Permissions can be associated.

Example Roles

Role Name	Label	Description
ceo	Chief Executive Officer	Top of the tree!
tymlyHr.manger	HR Manager	For the person in charge of the Human Resources department.
tymlyHr.teamLeader	HR Team Leader	For people in the HR department with a team to call thier own.

Internally, Tymly persists roles via its usual storage service - as such, organizations are free to create/maintain their roles to best suit their circumstances...

Template Roles

That said, it's possible to bundle pre-canned roles within a blueprint. While designing a blueprint, it may become evident that there are natural/common roles that any organisation might like to adopt to sensibly structure access to its forms/state machines - this is where Template Roles are useful.

For example if you look at the tests:

  /website-blueprint
  /template-roles
    /boss.json
    /team-leader.json
    /developer.json
    /tymly-test-admin.json
    /tymy-test-read-only.json
  blueprint.json

Here we can see the website-blueprint contains 5 template role files

• To better avoid name conflicts, Tymly will prefix a template role with the blueprint's namespace, and a . character.... hence the role names tymlyHr.manger and tymlyHr.teamLeader.
• Naming template roles like this allows multiple blueprints that share a namespace to supply common template roles.

The expected configuration for the template roles example:

{
  "label": "Team leader",
  "roleMemberships": [
    "developer"
  ],
  "grants": [
    {
      "stateMachineName": "deletePost",
      "allows": [
        "create"
      ]
    }
  ]
}

The roleMemberships is optional array. Elements in this array are Strings. They should be names of other template roles. The grants of the roles in the rolememberships are inherited by the template-role defined.

The grants attribute must have the stateMachineName and allows properties. • stateMachineName must be a string and must match the permitted state machine name. • allows is an array of permitted actions.

The properties can use * character as a glob match to match everything.

Rbac Methods

After booting up the rbac service, you can use the checkRoleAuthorization method to check if the user is allowed to trigger the action on the resource name.

It checks the supplied credentials against the internal RBAC index and indicates if the provided credentials allow the specified action to be applied to the named resource

rbac.checkRoleAuthorization(
  'userId', 
  tymlyContext, 
  [roles, roles, …],
  'resourceType', 
  'resourceName', 
  'action'
)

@param {string} userId: userId to be authenticated. (optional)
@param {Object} tymlyContext: A Tymly context (optional)
@param {Array<string>} roles: An array of roleIds (optional)
@param {string} 'resourceType': The type of resource to authorize against (e.g. `flow`)
@param {string} 'resourceName': The name of the resource that the credentials are being checked against (e.g. `flow tymlyTest_cat_1_0 `)
@param {string} 'action': the name of action this user is wanting to perform (e.g.`startNewTymly`)

Dynamic Roles in Tymly Rbac

Three dynamic roles are defined within tymly

•	$everyone – accessible by everyone
•	$authenticated – accessible by the user who is authenticated by his roles
•	$owner – accessible only by the owner