Permissioning Concepts

Let’s take a look at some of the permissioning concepts that allow Liberator to enforce security constraints on the end-users of a client application:

Products

A product is an entity on which users may be assigned permissions. You define products when you write the Permissioning Adapter. Examples of products are:

  • "All FI Instruments"

  • "FX Instrument GBPUSD"

  • "LIBOR based swaps"

  • "The Blotter"

Actions

An action defines the interaction that a user can have with a product. You define product actions when you write the Permissioning Adapter. Examples of product actions are:

  • "Viewing"

  • "RFQ trading"

  • "One-Click trading"

Permissions

A permission determines whether an action on a product will be allowed or denied. When you define a permission you can also define a namespace. A namespace allows client applications to query related permissions, such as all permissions in the "tenor" namespace. If you do not define a namespace, then the permission will reside in the default namespace. Permissions are assigned to Users and Groups when you write the Permissioning Adapter. Examples of product permissions (each row in the table defines a permission):

Action Product Namespace Authorisation

Viewing

LIBOR based swaps

Allow

RFQ Trading

All FI Instruments

Allow

One-Click Trading

FX Instrument GBPUSD

Quick Trades

Deny

One month settlement

All Instruments

Tenor

Allow

Users

A user represents an end-user of a client application. A user can only log in to a client application if permissioning data to authenticate the user has been supplied to Liberator. Users can also be assigned permissions for the products streamed by Liberator. Users are defined when you write the Permissioning Adapter. Data for constructing each user would typically be read from a configuration file or persistent permissioning system.

Groups

Users can be arranged in groups, where every member of a group has the same permissions. A user can be a member of more than one group, and groups can be members of other groups. This allows an inheritance tree of permissions to be created. In the example below, user X is a member of two groups:

  • Group "FI Traders". This group is permitted "RFQ trading" on "All FI Instruments"

  • Group "FX Traders". This group is permitted "RFQ trading" on "All FX Instruments"

As user X is a member of "FI Traders" and "FX Traders", they will be able to trade both FX and FI instruments. You will find another example of an inheritance tree in Example permissioning hierarchy. When permissions in an inheritance tree are in conflict, conventions are used to determine the permission that is assigned to the user. These conventions are described in Permissioning hierarchy conventions. Groups are defined when you write the Permissioning Adapter. Data for constructing each group would typically be read from a configuration file or persistent permissioning system.

Rules

In addition to defining permissions, you must also define permissioning rules. Rules link permissions to user interactions, and are used by Liberator to decide which of the many permissions that have been defined will apply when a user attempts to interact with a product.

When a client application requests data from Liberator, or tries to publish data to Liberator, the Permissioning Auth Module inspects the content of the associated RTTP message and tries to match it with one or more of the defined rules. If a match is found then the rule will identify the permission that must be checked to determine whether this interaction with Liberator is to be allowed or denied.

If more than one rule matches an RTTP message, then every one of the identified permissions will be checked. If any one of these permissions denies access, then access to the product will be denied.

Rules must be defined for every interaction that involves a client application publishing data to Liberator, such as when a user attempts to trade a product. If a rule has not been defined for such an interaction, then the default permission is to deny the interaction.

Rules cannot be defined for interactions that involve a client application requesting data, such as when a user attempts to view a product. With this type of interaction a default rule is implemented, and the permission that has been defined for the "VIEW" action in the default namespace will be checked to see if the interaction is to be allowed or denied.

Simple example of a matching rule

The following example shows a typical RTTP message that would be sent to Liberator when a user tries to spot trade a product.

Message to /FT/TRADE
Field Value

MsgType

Execute

Trading-Type

SPOT

Amount

1000000

Instrument

/FX/GBPUSD

An example of a rule that would match this type of trade is: "Check the user permission for the action "spot-trade" when the subject of the RTTP message to Liberator is "/FT/TRADE" and the "Trading-Type" is "SPOT". The product name to be checked is given by the "Instrument" field of the RTTP message."

Rule
Field Value

Subject match

/FT/TRADE

Field match criteria

Trading-Type=SPOT

Product reference field

Instrument

Action

spot-trade

Namespace

In this case the permission that has been defined for the action "spot-trade" in the default (undefined) namespace will be checked to see if the user is to be allowed or denied access to the product. The permission must also match the product that is identified by the "Instrument" field of the RTTP message, which in this case is "/FX/GBPUSD".

An example of a permission that would apply to this type of trade is shown below:

Permission
Field Value

Action

spot-trade

Product

/FX/GBP.*

Namespace

Authorisation

Allow

The permission in the default (undefined) namespace is checked since a namespace was not defined by the matching rule. In this case "spot-trade" action on all "/FX/GBP" products will be allowed. The .* characters following "GBP" are meta characters in a Java regular expression, such that /FX/GBP.* will match all GBP currency pairs.

For more information on the syntax supported by the Java regular expression engine, see the documentation for the java.util.regex.Pattern class.

Rules are defined when you write the Permissioning Adapter. Data for constructing each rule would typically be read from a configuration file or persistent permissioning system.

Roles

Roles determine whether a Permissioning Adapter has been designated as the master or slave.

PermissioningArchitecture MultiplePDS

Multiple Permissioning Adapters connected to Liberator (showing one master and one slave)

Liberator can be configured to accept permissioning data from multiple Permissioning Adapters. This allows permissions from different permissioning systems to be provided by different Permissioning Adapters. For example, one Permissioning Adapter could provide permissions for FX products and another permissions for FI products, with each Permissioning Adapter being administered by a different department.

When permissioning data is sent to Liberator from more than one Permissioning Adapter, one Permissioning Adapter is designated the master and each of the other Permissioning Adapters are designated as slaves. A slave Permissioning Adapter can only send a limited a set of permissioning data to Liberator and there can only be one master. The tutorial here describes how to set the master and slave roles, and defines the limited set of permissioning data that a slave can send to Liberator.

Permissioning hierarchy conventions

Single Inheritance

A user can be assigned their own permissions in addition to inheriting group permissions.

PermissioningHierarchyComplex 1

In this case, User 1 is assigned permissions and also inherits the permissions of Group 1, while User 2 is not assigned any permissions but inherits the permissions of Group 1.

Inheritance Masking

A permission assigned to a user or group masks permissions for the same action and product in parent groups.

PermissioningHierarchyComplex 2

In this case, the "Deny" permission assigned to User 3 for Action 1 masks the "Allow" permission for Action 1 in Group 2. The matching permission closest to the user in the permissioning hierarchy is always used to determine whether an action will be allowed or denied.

Multiple Inheritance Conflicts

If a user is a member of more than one group and any of the inherited permissions deny an action, then this permission will override any inherited permissions that allow the action.

PermissioningHierarchyComplex 3

In this case, the "Deny" permission for Action 1 that User 4 inherits from Group 3 overrides the "Allow" permission for Action 1 that User 4 inherits from Group 4.

Multiple Inheritance Conflicts in a Complex Hierarchy

"Deny" permissions also override "Allow" permissions in more complex hierarchies.

PermissioningHierarchyComplex 4

In this case, the "Deny" permission that User 5 inherits from Group 7 overrides the "Allow" permission that User 5 inherits from Group 5. Group 5 was compared to Group 7 because Group 6 had no permission to compare.

Permissions from Multiple Permissioning Adapters

"Deny" permissions also override "Allow" permissions when permissions are set in the master and slave Permissioning Adapters.

PermissioningHierarchyComplex 5a

In this case:

  • The "Deny" permission assigned to User 1 for Action 2 in the master overrides the "Allow" permission assigned to User 1 for Action 2 in the slave.

  • The "Deny permission assigned to User 1 for Action 4 in the slave overrides the "Allow" permission for Action 4 that User 1 inherits from Group 2 in the master.

  • Because permissions for Action 5 are not defined in the master or slave, the permission for Action 5 is, by default, "Deny".

To summarise, when permissions for an action are sent to Liberator from master and slave Permissioning Adapters, permissioning conflicts are resolved as shown in the following table.

Master/Slave permissioning conflicts

Master permission Slave permission Combined permission

"Allow"

"Allow"

"Allow"

"Allow"

Undefined

"Allow"

Undefined

"Allow"

"Allow"

"Allow"

"Deny"

"Deny"

"Deny"

"Allow"

"Deny"

Undefined

Undefined

"Deny"

Example permissioning hierarchy

The diagram below shows a permissioning hierarchy that uses the permissioning concepts introduced in this section. In this example, all permissions reside in the default namespace.

PermissioningHierarchy

From this diagram you will see that users have been assigned permissions through inheritance.

User 1 is a view only user

  • Allowed to view all FX and FI prices (inherited from "All Users")

User 2 is an experienced trader

  • Allowed to view all FX and FI prices (inherited from "All Users")

  • Allowed to view a blotter of previous trades (inherited from "Trading")

  • Allowed to RFQ trade FI Instruments (inherited from "FI Trading")

  • Allowed to RFQ trade FX Instruments (inherited from "FX Trading")

User 3 and User 4 are novice traders with the same product permissions

  • Allowed to view all FX and FI prices (inherited from "All Users")

  • Allowed to view a blotter of previous trades (inherited from "Trading")

  • Allowed to RFQ trade FX Instruments that are not Volatile Currencies (FX Instruments inherited from "FX Trading", but Volatile Currencies denied by "Novice")


See also: