Complex Permissioning Rules

The following example shows an RTTP message that has a username ("Bob") in the subject of the message.

An example of a rule that matches this message is:

Because the matching rule contains the %u substitution token, the Permissioning Auth Module compares the username of the logged in user with the username in the requested subject.

If the logged in user is "Bob", the rule is applied and the permission defined for the action "ONE-CLICK" in the default namespace is checked to see if the request from Bob is to be allowed or denied. If the logged in user is "John" and not "Bob", the Permissioning Auth Module immediately denies the request.

The substitution tokens %u, %U, and %t can also be used when you define a permission. When a user attempts to view a product a default rule is implemented, and the permission that has been defined for "VIEW" action in the default namespace is checked to see if the interaction is to be allowed or denied. The following example shows a typical RTTP message for this type of request, in which the user attempts to view a product, and the username of the logged in user ("Bob") is in the subject of the message.

Because the user is attempting to view a product, the default rule is implemented. An example of a permission that would apply to this type of request is shown below (it is for the VIEW action and is in the default namespace, so it matches the default rule).

n this example, the Permissioning Auth module replaces the %u token in Product with the username of the logged in user, and compares this modified Product with the requested subject.

If the logged in user is "Bob", the modified Product in the permission is /PRIVATE/Bob/FX/USDGBP, which matches the requested subject, so the request from Bob is allowed, provided no other VIEW permissions with Deny authorization match the subject. If the logged in user is "John" and not "Bob", the modified Product in the permission does not match the requested subject, so it has no effect on the permission for the requested subject, as the request from "John" is neither allowed nor denied by this permission.

Substitution tokens are most effective when applied to permissions in Groups that multiple users inherit from. Without the token you would have to define a specific permission for each user, containing the user’s name.

For information about using the %t substitution token in permissions, see Using the %t substitution token.

From version 7 of the Permissioning Auth Module, you can reference the StreamLink application ID and KeyMaster token values when specifying field-match criteria for a permissioning rule. These values are exposed as virtual fields. These virtual fields are not part of the RTTP message and can only be referenced in field-match criteria.

The Product Reference Field can be given the special value "ALL_PRODUCTS" (equivalent to the Java regular expression ".*"), in which case all product permissions for the action are checked to see if the action is allowed or denied. We will now look at an example RTTP message and a matching rule that uses this special value.

An example of a rule that matches this type of trade is shown below:

In this case all product permissions for "ONE-CLICK" action in the default namespace are checked to see if the user is to be allowed or denied access. If any of these permissions deny "ONE-CLICK" action, access to "/FX/EURGBP" is denied. An example of a permission that applies to this type of trade is shown below.

Although this permission is for "/FX/EURGBP", it also applies to "/FX/USDGBP", since the rule specifies that all product permissions for "ONE-CLICK" action in the default (undefined) namespace must be checked to see if the action is allowed or denied.

The Product Reference Field can be a Java regular expression, in which case every field of the RTTP message that matches the regular expression will be considered to contain the name of a product. Java regular expressions can be used to define rules for multi-leg trading, as shown in the following example.

An example of a rule that would match this type of trade is shown below.

The "\d" in the regular expression of the Product Reference Field will match any digit. In this case the permission that has been defined for the "TRADE" action in the "TRADER" namespace will be checked to see if the user is to be allowed or denied access to the products identified by fields "L1_" and "L2_". An example of the permissions that would apply to this type of multi-leg trade is shown below.

In this case "TRADE" action on the products "/FX/GBPUSD" and "/FX/USDJPY" will be allowed, since the rule states that the permission applies to each of these products. If the user did not have "Allow" permission for each of these products, then the multi-leg trade would be denied.