Ebase Security System

Documentation home

 

Introduction. 1

Authorization fundamentals 1

Basic check using the role name. 1

Advanced check using authorizations 2

Rules for evaluating security authorizations 2

Built in advanced authorization checks 2

Form execution authorization check 2

Workflow Authorizations 4

 

 

See also:        

 

Introduction

This page describes the built-in security system shipped with Verj.io. The system provides:

 

·         Users: user properties include password, roles and groups

·         Roles: roles provide a simple authorization mechanism and can also be used for workflow assignment

·         Groups: groups can be linked with roles and this provides a quick way of linking users with multiple roles

 

The built-in security system is maintained using the Server Administration Application.

 

Authorization fundamentals

Each user is associated with one or more security roles where each role can optionally contain any number of individual authorizations. The association between a user and their related roles is made when the user signs on. Roles can be used in two ways:

 

·         Basic role check

·         Advanced authorization check

Basic check using the role name

A program can check whether a user is associated with a certain role:

 

Javascript:

if (system.securityManager.hasRole("Admin") )

..

 

FPL:

if [ hasrole('Admin') ]

..

 

Role names can also be used as the basis for workflow assignment i.e. a task can be assigned to a user if the user is linked with a certain role.

 

Advanced check using authorizations

This provides the ability to perform more detailed security authorization checks. Each authorization contains three basic attributes: type, name and function and these attributes are matched against the corresponding attributes when a security authorization is checked e.g.

 

Javascript:

if (system.securityManager,isAuthorized("Accounts", accountName, "Read") )

..

FPL:

if [ isauthorized('Accounts', accountName, 'Read') ]

..

 

The name part of each authorization can be configured as a list or range of values. Click here for details.

Rules for evaluating security authorizations

The following rules are used to determine whether an authorization check is allowed:

 

1.      A range is less specific than a character string or a list

2.      For character strings (either in a list or as a simple string) containing a masking character (*), the character string with the highest number of characters preceding the * is most specific. e.g. ABCD* is more specific than AB*, which in turn is more specific than *.  A value with no masking characters is always the most specific, and a single masking character * is always the least specific. This logic is applied first to the authorization type, then name, then function to determine which of any two applicable authorizations should be applied.

3.      If the authorization type, name and function are all equal for any two authorizations being compared, an authorization specifying prevent takes precedence over an authorization specifying allow.

4.      If no authorization applies, the request is denied.

5.      Some functions are implied by other functions as follows:

 

Function

Implies

Read

View, Export

Write

Read , View, Export, Import

 

 

Built in advanced authorization checks

The advanced authorization check mechanism described above is used internally by the Verj.io system itself for two purposes:

 

·         Form execution authorization check

·         Workflow authorizations

 

Form execution authorization check

This authorization is used to determine whether a user is authorised to run a form. The authorization has the format:

 

Authorization:

 

Type

Form

Name

See below

Function

Execute

 

where Name is the value supplied in the Security authorization field of the form’s properties. In the following example, the authorization name is HIGH:

 

 

 

..and access to this form can be controlled with an authorization like this:

 

Authorization:

 

Type

Form

Name

HIGH

Function

Execute

Prevent

 

 

In this example, access is denied as the authorization action is set to prevent.

 

If no security authorization name is specified, all users are granted access to the form.

If a security authorization name is specified and an authenticated userid does not exist, access is denied.

In all other circumstances, the security system is checked to determine whether or not a user has the required authorization.

 

When access is denied, form execution is aborted. If a form on error event is not specified, this results in the display of the system abort page with message:

 

********************************************
* Access denied to run form XXXXX       
  *
********************************************

 

If an on error event is specified, it receives control and system variable $ABORT_MESSAGE is set with the message displayed above.

 

Workflow Authorizations

All calls to the workflow API are secured using a Type of WORKFLOW. In addition to this, API calls that return a table of information e.g. getTasks, getJobs etc include additional checks that each item is viewable by the caller.

 

The Name part of the security authorization is taken from the security expression for the task or job to which the API call applies as shown in the following diagram. For task related commands, the security expression from the process will be used if no value is specified at task level. API calls that are not specific to a task or job e.g. getTasks() use the name CLIENT.

 

 

For example, the following rule could be used to grant access to high security (security expression = HIGH) workflow elements:

 

Type

WORKFLOW

Name

HIGH

Function

*

Allow

 

 

The Verj.io workflow system is supplied with two security handlers – this is implemented with Server Administration – Workflow Properties:

 

·         com.ebasetech.ufs.workflow.security.example.EbaseSecurityHandler: most read only functions are allowed, security is checked only when a security expression has been implemented

·         com.ebasetech.ufs.workflow.security.example.EbaseStrictSecurityHandler: only the minimum functions are allowed and security is always checked

 

The details of what is checked by these two security handlers is shown in the table below: 

 

Type

Name

Supported Functions

EbaseSecurityHandler

EbaseStrictSecurityHandler

WORKFLOW

CLIENT

getTasksForActor

Allowed

Checked

 WORKFLOW

CLIENT

getFailedTasks

Allowed

Checked

 WORKFLOW

CLIENT

getTasksForRole

Allowed

Checked

 WORKFLOW

Security Expression

assign

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

openTask

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

descriptorFor

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

unassign

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

setWaiting

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

pause

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

unpause

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

cancel

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

setPriority

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

reexecute

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

open

Allowed

Allowed

 WORKFLOW

Security Expression

openJobAndCompleteFirstTask

Allowed

Allowed

 WORKFLOW

Security Expression

getProcessInParameters

Allowed

Checked

 WORKFLOW

CLIENT

openedJobs

Allowed

Checked

 WORKFLOW

CLIENT

getAuditRecords

Allowed

Checked

 WORKFLOW

CLIENT

getJobs

Allowed

Checked

 WORKFLOW

CLIENT

getJobsForOwner

Allowed

Checked

 WORKFLOW

CLIENT

getTasks

Allowed

Checked

 WORKFLOW

CLIENT

getProcesses

Allowed

Checked

 WORKFLOW

Security Expression

cancelJob

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

complete

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

stateOf

Allowed

Checked

 WORKFLOW

Security Expression

descriptionOf

Allowed

Checked

 WORKFLOW

Security Expression

getCandidateActors

Allowed

Checked

 WORKFLOW

Security Expression

setOutputParameter

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

getProcessAttributeValue

Allowed

Checked

 WORKFLOW

Security Expression

setProcessAttributeValue

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

getProcessDescription

Allowed

Checked

 WORKFLOW

Security Expression

activateProcess

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

quiesceProcess

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

unsetJobOwner

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

forceCompletion

Checked only when security expression is specified

Checked

 WORKFLOW

Security Expression

forceAssign

Checked only when security expression is specified

Checked

WORKFLOW

Security Expression

VIEW1

Checked only when security expression is specified

Checked

 

Note 1: Used to control visibility of individual line items within API calls that return a table of information e.g. getTasks, getJobs etc.