Permissioning
This topic describes how to grant users permission to interact with the subjects published by the Barracuda Order Adapter.
Permissioning
Users typically require the following permissions to interact with the Barracuda Order Adapter.
Client User | Sales User | |
---|---|---|
Order messaging channel |
Read and write |
Read and write |
Order details |
Read |
Read |
Sales order details |
- |
Read |
Order blotter |
Read |
- |
Sales order-blotter |
- |
Read |
Client order-blotter |
- |
Read access to the order blotter of each client user that the sales user trades on behalf of. |
Order notifications |
The two sections that follow describe how the above permissions can be implemented using the Caplin Permissioning Service and the Permissioning Integration API. If your deployment uses a custom Liberator auth module, then refer to your auth module’s documentation for guidance on how to grant the above permissions.
For a user’s interaction with Liberator to be permitted, the following statement must be true: the user’s interaction must be identifiable as a defined action on a product or a set of products, and the user must have been granted permission to perform that action on that product or that set of products. The Caplin Permissioning Service models this in two types of permissioning instruction:
-
Rules: define a user interaction as an action on a product or a set of products. Liberator implicitly defines rules for reading a subject; you must explicility define rules for writing (contributing) to a subject.
-
Permissions: allow or disallow an action on a product or a set of products. Permissions can be granted to a user or a group of users.
Rules
Define the following rule for all contributions to the order messaging-channel. To define a more fine-grained access model, with different actions defined for individual operations such as order submission, order amendment, and order cancellation, see Field-match criteria in Complex Permissioning Rules.
The permission namespace and the action name in the rule below are arbitrary. You may change them to suit your own naming conventions, with the caveat that you must also change the namespace and the action of the corresponding permission.
Message Subject | Rule Type | Permission Namespace | Action | Action ref | Product Ref |
---|---|---|---|---|---|
|
WRITE |
ORDERS_CHANNEL |
ORDER_ACTION |
- |
ALL_PRODUCTS |
Permissions
Grant users the following permissions.
Product Set | Permission Namespace | Action | Authorisation |
---|---|---|---|
|
ORDERS_CHANNEL |
ORDER_ACTION |
ALLOW |
|
- |
VIEW |
ALLOW |
|
- |
VIEW |
ALLOW |
|
- |
VIEW |
ALLOW |
|
- |
VIEW |
ALLOW |
|
- |
VIEW |
ALLOW |
|
- |
VIEW |
ALLOW |
|
- |
VIEW |
ALLOW |
Blotter items are not explicitly permissioned. Users are subscribed to blotter items in the context of a blotter container, and the Barracuda Order Adapter sets the auto-permit flag on all the blotter containers it publishes. If a user is permitted to view a blotter container, they are automatically permitted to view the items in the container.
The above table does not include permissions for client order-blotters in Caplin FX Sales. Because client order-blotters are accessed by users other than the owner of the blotter, the username in the permissioning product-set cannot be a '%u' placeholder and permissions for client order blotters must be defined individually.
For each client order-blotter:
-
Define a permission for the blotter container.
-
Define a permission for the filtered blotter container.
-
Grant the above permissions to only those sales users who are permitted to trade on behalf of the client whose blotter it is.
For example, the table below shows the permissions to define for the client order-blotter of client user user1@exampleclient.com
. These permissions must be assigned only to sales users permitted to trade on behalf of user1@exampleclient.com
.
Product Set | Permission Namespace | Action | Authorisation |
---|---|---|---|
|
- |
VIEW |
ALLOW |
|
- |
VIEW |
ALLOW |
See also: