An Introduction to the DACS Entitlement System for OpenDACS Developers

Refinitiv Real-Time Data Access Control System (DACS) allows organisations to reduce their data costs by introducing access control to this fee-liable data within Refinitiv Real-Time Distribution System (RTDS, formerly TREP), environment for each user.

Consuming applications developed using the Refinitiv Real-Time SDKs or Refinitiv Robust Foundtation APIs are required to submit user credentials to Refinitiv Real-Time Distribution System (RTDS, formerly TREP), which are then verified by DACS and are thereby subject to the same access control mechanism; for this use-case there is no requirement for OpenDACS.

The Use-case for OpenDACS

When a consumer application makes data available outside of the Refinitiv Real-Time Distribution System (RTDS, formerly TREP) environment, i.e. redistribution, it is no longer subject to DACS access control.

This is where OpenDACS API can help; by providing the developer with a programming interface that communicates with DACS, OpenDACS enables an application to verify users and their entitlement and thereby maintain data access control as defined by the DACS administrator.

OpenDACS Offerings

For the purposes of determining data entitlements the OpenDACS developer kit (DSDK) is available for Java, .NET and C++ on Windows, and Linux.

As an alternative, for example where the language or platform is not one of those offered by the OpenDACS developer kit, there is a server product available, the Open DACS Permission Server (ODPS) which uses the industry standard HTTP 1.1/REST protocol, thus allowing any environment that allows the use of http requests to perform DACS entitlement checks.

Whilst the ODPS provides much greater accessibility, the choice between using the developer kit and using ODPS will also depend on the application performance and scalability requirements. Without additional implementation when using the ODPS to provide caching of responses and the consequential maintenance of the cache values, the OpenDACS developer kit will have a performance advantage due to the fact that the API performs its own caching of entitlements and minimises network bound requests.

DACS Features

The various ways in which DACS provides entitlement control and how these features relate to an OpenDACS application;

User Verification

DACS will verify the user name, this name will be used to retrieve the correct entitlement profile, however DACS performs user authorisation not authentication; the authentication process is expected to be completed successfully before an application submits the user’s credentials for authorisation.

Concurrent Login Control

A user name is subject to a limit on the number of positions from which it is used concurrently, by default this is set to one but can be increased by the DACS administrator. This permission is then recorded for reporting so that it can be subject to any commercial policies of the venues to which the user has access. It does not restrict the number of times the same user performs a login provided all the requests are registered at the same position and this would be expected if a user requires multiple instances of an application. But in order to use a different position the user must first be logged out from the previous position.

It is essential that an OpenDACS application maintain and support the DACS concurrent login control, this requires the OpenDACS application to provide accurate position information for the user which is supplied during the login process, once logged in the user must remain in this state until a logout is explicitly requested or all data being consumed has been released. Once logged out a user must no longer consume data.

Application Entitlement

This allows the DACS administrator to control entitlement to use an application. DACS contains a mapping of application names to application identifiers. During the login process an application will provide an application identifier that can be checked against the user entitlement before allowing the login to proceed. This application identifier is recorded as part of the usage information generated by the login and any subsequent entitlement checks. Application entitlement is disabled by default.

Application identifiers in the range 1 to 256 are assigned by Refinitiv and preloaded into DACS, identifiers 257 to 65,535 are available to be assigned by the DACS administrator.

An OpenDACS application must have an application identifier registered in this way and it must use this for any login requests in order that application entitlements can function if it is enabled at any time but also to correctly report the application in the usage data reports.

Service Entitlement

The first and most basic user entitlement is authorisation to access a service. With this level of authorisation a user is either entitled to the service and therefore all the data available on that service or the user is not entitled to access the service at all.

Subject Based Entitlement

A DACS Administrator can define a service to use the subject name associated with the data request in order to determine if a user is entitled to the data. This can be done by granting access to the literal subject name, .e.g. “IBM” but in practice it is normally granted to a range of subjects by using wildcards as part of the subject specification. The OpenDACS interface does not require the application to know how a subject qualifies.

Content Based Entitlement

A service can be defined to use content based entitlements, this type of authorisation allows an administrator to grant access to an entity such as an exchange. The information that determines if the data belongs to a particular entity (e.g. Exchange) is contained in the data itself, sometimes referred to as a DACS lock, it defines the entitlements required to access the data. In order to access data from a Content Based Entitlement service a user must be granted access to the service and the entity. For the Refinitiv Real-Time APIs the DACS lock is available in the header of the Refresh/Image response message. If a DACS Lock is supplied in a response message then it is a content based entitlement service and the OpenDACS application must perform a permission check using that DACS Lock for all users requesting (or already consuming) the associated data; it is possible to receive an updated value for a DACS Lock but unless you are consuming NEWS this should be a rare occurrence.

For OpenDACS applications that cache or store the data, the DACS Lock must also be stored with the data so that entitlement checks can be performed at retrieval time.

Refinitiv real-time data feed products such as Refinitiv Real-Time (formerly ERT) all use content based entitlements because it provides the flexibility required to comply with all the different commercial policies of the data sources carried over these feeds.

For more information on the anatomy of DACS locks please see the DACSLOCK API Developers Guide, this is also supplied in the RFA developer kit documentation.

Usage reporting

DACS can record the following types of usage event:

• Successful user logon attempts
• Denied user logon attempts
• Successful user information opens
• Denied user information opens

Each entitlement check performed by any Refinitiv Real-Time Distribution System (RTDS, formerly TREP), or OpenACS application will generate a usage-record that is stored by DACS, this information is used to perform usage reporting and is an important cost-saving feature for DACS administration. As an OpenDACS developer it is important that you implement your application in such a way as to support this feature;  to do this follow the advice given in the OpenDACS C++ Developer Guide (this information is not included in the Java release) in relation to the control exercised over usage logging, the parameter values supplied during the entitlement check should be complete and accurate, in particular ensure that all entitlement checks include the item name - even where the service uses content based entitlements.

One type of use-case which does not trigger a usage record of any form is where the OpenDACS application extracts the user profile information (e.g. using the getPEList() method) and this is used to determine if the user is entitled. This is a specialised use-case, normally involving integration challenges with cached or stored items (it is not to provide any significant performance benefit on the entitlement check because the user profiles are already held within the OpenDACS memory space). In order to generate the usage records, use the resulting data set yielded by applying the user profile information to retrospectively make the discreet entitlement checks.

DACS On Demand

The On-Demand feature provides access to selected exchange data automatically on the initial request for data from the exchange. This feature is exposed at the OpenDACS interface. If an application indicates to OpenDACS that On-Demand permissions should be considered or does not provide an indication (the default) when performing an entitlement check then DACS will automatically entitle the exchange for that user (if that exchange has On-Demand enabled). Be aware that this will incur a cost for that reporting period. 

DACS Web Services

The DACS Web Service feature exposes programmatic interfaces for creating / querying and updating entitlements information contained within the DACS database. It is not associated with OpenDACS and is not intended for real-time entitlement checking of users, use OpenDACS for this activity.

DACS Topology

The Data Access Control System can be logically broken down into three major parts:

• The DACS Station Components which provides the Administrative functions and the database for persistent storage.
• The DACS Operational Components which make up the infrastructure of the DACS, holding and distributing the operational permission data.
• The DACS Operational Clients which are the consumers of fee-liable data for which the entitlement control services provided by DACS are required.

An OpenDACS application will connect to the DACS infrastructure in the same way as a Refinitiv Real-Time Distribution System component – they are all DACS clients, this is referred to as the Operational Component because entitlement services required by the production environment depend on it, a failure of this component will prevent any further login requests. In comparison the DACS Station Components only affect the administration activity, the Operational components will continue to perform as required without it.>

NOTE: The DACS Web Service feature is implemented in the DACS Station Components which does not have the same performance or resilience as the operational components and as such it must not be incorporated into an Operational/Production critical activity.

DACS Operational Components

The DACS Operational Components, also referred to as the DACS Infrastructure consists of two main processes, the DACS Server and the DACS sink daemon;

The DACS Server provides three main functions:

• To support control of Concurrent User Login.
  • To do this it holds the state of user logins against position/display and application in memory.
• To support the distribution of permission information for Users and when enabled, Applications to the DACS Clients.
  • To do this the DACS Server holds an in-process copy of the binary encoded operational permission database which was generated by the DACS station components.
• Distribution of the Data dictionary and mapping tables required to perform entitlement checks.
  • The DACS Server holds an in-process copy of the binary encoded operational permission dictionary which was generated by the DACS station components.

The DACS Sink Daemon provides the access point to provide entitlement services for all DACS client applications including RTDS (formerly TREP) Infrastructure components (e.g. ADS) and Open DACS Applications.

In order to perform entitlement checks an application must connect to a DACS sink daemon.

DACS Sites

The definition of users in a DACS system may be partitioned across a number of sites;

The DACS Operational Components and clients are also partitioned within these sites, with one primary (local) site and optionally a number of remote sites.

Each site is administered and enforced as a separate entity within the DACS Station e.g. A DACS user defined on site ‘B’ does not confer any existence or entitlement on site ‘A’. There is no communication between operational components across sites.

For an OpenDACS application this will require consideration where its users can be defined on different DACS sites.

Open DACS provides a multi-connect feature to allow a single application to perform entitlement checks across sites, however the application must be aware of the site at which the users profile is located or have some means to derive it from the user name or ‘poll’ each site in turn, for this last option there is an assumption that a user name will be unique across sites. For more information see the OpenDACS Multi-connect option document.

References

Q&A Forum

What is difference between Subject v/s Content Based Entitlements

Incorrect entitlement response returned from Open DACS.

How to enable logging usage data in Open DACS API?

Documents

OpenDACS Multi-connect option document

OpenDACS C++

OpenDACS Java

OpenDACS .NET

RFA C++ DACSLOCK API Developers Guide

RFA .NET DACSLOCK API Developers Guide

Glossary