As part of the wider transition project the subject of Data Security has regularly cropped up. Users now have the capability to access data from a variety of sources outside of the normal ITAS Applications. Since the introduction of Entity Framework to the ITAS technology stack, the ITAS Database tables have been exposed to the API, DQS, DMS as well as standard Trader Desktop applications. Heritage applications contain restricting conditions (filters) within their code, meaning this will only apply to data accessed within them. To tackle Data Security on a wider scope we have introduced the concept of a User Claim; simply put, a user is given the right to access a range of data at the Entity Framework level.
Claims are a standard of contemporary authorisation across software platforms. They are attached to a user (including service accounts) and can be passed/accessed across different applications and even platforms. They require a unique ID (and therefore lend themselves to a tree structure), are compatible with roles and can be added to authentication tokens (such as those used in ITAS API).
Claims are agnostic of data source and so very useful when dealing with scenarios such as a platform migration where two very similar claims can be saved in very different locations. ITAS Claims have been architected so that the initial node determines the function, therefore the data source is not relevant to the Claims function. This structure means new functional areas (e.g. role: user, admin, finance, trader etc.) can be added later.
More information on Claims: https://www.future-processing.pl/blog/introduction-to-claims-based-authentication-and-authorization-in-net/
User Bob Smith has a CMP-maintained department restriction in place to only allow him to see data associated with department 'XYZ'. This value is held in prv40_trade_dept and is enforced within the applications that refer to department-based data, the main one being TRADE. As a result of code built into the recall and edit features in TRADE, Bob can only see contracts where the department is set as 'XYZ'.
If Bob had access to the underlying data via any application that did not apply this user restriction, the data provider would not prevent him seeing all contracts. This is fine in practice as ITAS does apply this logic universally, however it does mean that all future methods of accessing contract data will need to both identify Bob's profile and enforce the policy. Additionally if a new policy was required, for example to restrict by currency or commodity, then the infrastructure would need to be implemented on both the user profile and all of the applications that expose the contract data.
To consider this by taking a Claims approach, the key difference is that the policy is held at the data level (Entity Framework). In this case the Claim is an Entity Filter based on the Department Data Entity with a value of 'XYZ'. Simply put, wherever the Department Data Entity is referenced, anyone with this specific Claim will automatically be restricted to data where the DepartmentId is 'XYZ'.
Note: This is a very simplistic overview as a Claim can be applied across all or selected Trading Entities, can include properties or associated properties on the table (Data Filters) and even refer to non-data based privileges (i.e. functions).
The following shows the construction of the URL-based pattern for identifying the two type of Claims discussed in this article:
| Entity Filter | /EntityFilter/ {EntityName} / {TradingEntity} / {Value} |
| Data Filter | /DataFilter/ {EntityName} / {PropertyName} / {TradingEntity} / {Value} |
Note: {TradingEntity} can be set to '*' to denote all Trading Entities, or a specific code