Additional Permissioning Capabilities
This page looks at some additional permissioning capabilities, namely.
Subject mapping
When a user attempts to view data, a default rule is implemented (see Rules). This default rule states that the Permissioning Auth Module must check the user’s permission in the default namespace for "VIEW" action on the product identified by the subject of the RTTP message. If the action is permitted, then Liberator will stream data to the user for the requested product. Subject mapping allows the subject of an RTTP message to be modified by Liberator. Subject mapping is transparent to the user and could be used, for example, to provide preferential data to selected users.
The Default Subject Mapper
A default subject mapper is provided with the Permissioning software that allows you to add subject mappings for a user. A mapping specifies a regex subject pattern and a subject suffix. If the user attempts to view data where the subject of the RTTP message matches a mapping’s subject pattern, then the subject suffix will be appended to the subject of the RTTP message when Liberator requests the data from the Pricing Adapter.
To view the data, the user must be permitted "VIEW" action in the default namespace for the product identified by the modified subject of the RTTP message.
When Liberator streams the data to the user, the data will be streamed using the original RTTP message subject, but for the product identified by the modified RTTP message subject.
Multiple subject mappings can be added for each user by a Permissioning Adapter using the default subject mapper. The subject mappings are added by calling the User.addSubjectMapping() method of the Caplin Permissioning Integration API.
| For a description of how to crate a Caplin Permissioning Integration API, please refer to the Permissioning Integration API section of the Caplin Integration Suite for Java API Documentation. |
Creating a Custom Subject Mapper
If you want to calculate a subject mapping based on customized mapping logic, then you must create a custom subject mapper. The custom subject mapper must implement the SubjectMapper interface of the Caplin Permissioning Integration API and be deployed in the Permissioning Auth Module.
Simple Example of Subject Mapping using the Default Subject Mapper
The following example shows how subject mapping can be applied to a user when Liberator supports price tiering. In this example the subject pattern is the regular expression "/PRICES/FX/.*" and the subject suffix is "-tier2".
Applied subject mapping
| Subject Pattern | Subject Suffix |
|---|---|
/PRICES/FX/.* |
-tier2 |
If the user attempts to view "/PRICES/FX/GBPUSD", Liberator requests the data from the Pricing Adapter that provides "/PRICES/FX/GBPUSD-tier2". When Liberator streams the data to the user, it will be streamed from "/PRICES/FX/GBPUSD-tier2" but using the original RTTP message subject "/PRICES/FX/GBPUSD". An example of a permission that would apply to this type of data request is shown below.
Permission that would apply
| Action | Message Subject | Namespace | Authorisation |
|---|---|---|---|
VIEW |
/PRICES/FX/.*-tier2 |
Allow |
In this case VIEW action on "/PRICES/FX/GBPUSD-tier2" will be allowed, since "/PRICES/FX/.*-tier2" matches all "-tier2" currency pairs in "/PRICES/FX" and the authorization is "Allow". Note that the permission matches the modified message subject, and not the original message subject.
Global context data
The global context is an object at the Permissioning Auth module. This object allows custom subject mappers to access data that is common to all subject mappers and users. In this way a custom subject mapper can map subjects using logic based on this common data, and not just on subject mappings defined for the user. For example, if a custom subject mapper uses FX rates to map a subject, it is more efficient to add these rates to the global context than to the subject mappings of every user.
A default global context class is provided with the Permissioning software, but you can also create a custom global context class that provides specialised methods to subject mappers.
User attributes
A user can be assigned any number of attributes in the form of name/value pairs. User attributes are not processed by the Permissioning Auth Module, and therefore do not affect permissioning directly, but they can be accessed by the client application to provide miscellaneous contextual information about the currently logged in user.
A typical use would be to send information to a client application about the maximum tradable amount that users are permitted to trade.
Defining and Retrieving User Attributes
In the Permissioning Adapter, user attributes are defined in Java using the com.caplin.permissioning.User.setAttribute() method of the Caplin Permissioning Integration API. In the following example, the maximum tradable amount for a user is set to 5 million USD.
/* create new user with login name trader1 */ User maxTradeUser = new User(trader1); ... /* set the max tradable USD (millions) */ maxTradeUser.setAttribute(maxTradeUSD, 5);
In a client application that is based on Caplin Trader, user attributes are retrieved in JavaScript using the caplin.security.permissioning.PermissionService.getUserAttribute() method of the Caplin Trader Permissioning API. In the following example, the maximum tradable amount in USD is retrieved for the currently logged in user.
/* get the max tradable USD (millions) */ maxTradableUSD = caplin.security.permissioning.PermissionService.getUserAttribute(maxTradeUSD);
See also: