文章

面向OpenDACS开发者的DACS权利系统介绍

作者:

David Thomas
Developer Advocate Developer Advocate

概括

Refinitiv实时数据访问控制系统(DACS)是一个授权系统,是Refinitiv实时分发系统(RTDS,前身为TREP)的一部分,它可以使平台能够实施权限控制。OpenDACS是DACS的编程接口,它提供的功能将允许应用程序确定任何RTDS用户对平台上服务和数据的权限。

读者

本文介绍DACS和OpenDACS的概念,旨在让不熟悉该主题的开发人员了解何时需要OpenDACS,以及如何在应用设计中实施权限相关的需求。

范围  

本文的重点是围绕OpenDACS API提供的确定用户权限方法,以及这与部署和实现的关系。

这不是一个编程教程,编程具体请参阅开发者论坛中OpenDACS API java (Refinitiv Real-Time Open Data Access Control System API (Open DACS API) · Java | Refinitiv Developers)和OpenDACS C++(Refinitiv Real-Time Open Data Access Control System API (Open DACS API) · C++ | Refinitiv Developers)的教程。

什么时候需要OpenDACS?

为了回答这个问题,让我们首先看看DACS在市场数据系统(Market Data System)中扮演的角色

使用DACS的好处

由Refinitiv实时数据源产品(Refinitiv Real-Time Data Feed Products)和Refinitiv实时分发系统(Refinitiv Real-Time Distribution System)承载的交易所和其他第三方数据内容是有产权的,数据发起方会根据用户对数据的访问收取费用。

Refinitiv 实时数据访问控制系统(DACS)允许组织在Refinitiv Real Time Distribution System(RTDS,前身为TREP)环境中通过对每个用户引入对收费数据的访问控制来降低其数据成本。

使用Refinitiv Real Time SDK或Refinitiv Robust Foundation API开发的消费应用程序需要向Refinitiv Real Time Distribution System(RTDS,前身为TREP)提交用户凭据,然后由DACS进行验证,从而受相同的访问控制机制约束。上诉情况不需要OpenDACS。

需要OpenDACS的情况

当消费者应用程序在Refinitiv Real Time Distribution System(RTDS,前身为TREP)环境之外提供数据(即重新分发)时,它不再受DACS访问控制。

OpenDACS API向开发人员提供与DACS通信的编程接口,它使应用程序能够验证用户及其权限,从而维护DACS管理员定义的数据访问控制。

OpenDACS 提供了什么

OpenDACS开发者工具包(DSDK)可用于Java, .NET和C++在Windows、和Linux上确定数据权限的应用。

当语言或平台不是 OpenDACS 开发者工具包所提供的语言或平台时,OpenDACS 权限服务器(ODPS)可以作为一种选择。它使用行业标准的 HTTP 1.1/REST 协议,因此允许任何允许使用 http 请求的环境执行 DACS 权限检查。

虽然ODPS提供了更大的可访问性,但在使用开发者工具包和使用ODPS之间的选择也将取决于应用程序的性能和可扩展性要求。无需额外的实施,当使用ODPS提供响应的缓存和随之而来的缓存值的维护时, OpenDACS开发者工具包将具有性能优势,因为OpenDACS API自己缓存了授权信息,并最大限度地减少网络绑定请求。

DACS 功能特性

本节介绍DACS提供的各种权限控制,以及这些功能与OpenDACS应用程序的关系。

用户验证(User Verification)

DACS将根据用户名检索正确的授权配置文件。但DACS执行用户授权而非身份验证。身份认证过程将在应用程序提交用户凭据以进行授权之前成功完成。

并发登录控制(Concurrent Login Control)

一个用户名的同时使用位置数是有限制的,默认情况下,它被设置为一,但可以由DACS管理员增加。这个权限会被记录下来用于报告,这样它就可以受制于用户可以访问的数据源的任何商业政策。它并不限制同一用户进行登录的次数,只要所有的请求都在同一位置注册,如果一个用户需要一个应用程序的多个实例,这将是意料之中的。但是为了使用不同的位置,用户必须首先从以前的位置注销。

OpenDACS应用程序必须维护和支持DACS并发登录控制,这要求OpenDACS应用程序为用户提供准确的位置信息,这些信息是在登录过程中提供的。一旦登录,用户必须保持这种状态,直到明确要求注销或所有正在消费的数据都已释放。一旦注销,用户就不能再消费数据。

应用授权(Application Entitlement)

这使DACS管理员能够控制使用一个应用程序的权利。DACS包含一个应用程序名称与应用程序标识符的映射。在登录过程中,应用程序将提供一个应用程序标识符,在允许登录之前,可以对照用户的授权进行检查。用户登录和任何后续授权检查所产生的使用信息会包含这个应用标识符。默认情况下,应用的授权是禁用状态。

1至256范围内的应用标识符由Refinitiv分配并预装到DACS,标识符257至65535可由DACS管理员分配。

一个OpenDACS应用程序必须有一个以这种方式注册的应用程序标识符,它必须在任何登录请求中使用这个标识符,以便在任何时候应用授权能够发挥作用,同时也能在使用数据报告中正确报告该应用程序。

服务授权(Service Entitlement)

第一个也是最基本的用户权利是被授权访问一项服务。据此授权,用户要么有权使用该服务,从而获得该服务的所有数据,要么用户根本无权访问该服务。

基于主题的授权(Subject Based Entitlement)

DACS 管理员可以定义一项服务,使用与数据请求相关的主题名称,以确定用户是否有权获得数据。这可以通过授予对字面主体名称的访问来实现,例如 "IBM",但在实践中,它通常通过使用通配符作为主体规范的一部分来授予一系列的主体。OpenDACS接口不要求应用程序知道一个主题是如何限定的。

基于内容的授权(Content Based Entitlement)

一项服务可以被定义为使用基于内容的授权,这种类型的授权允许管理员授予对一个实体(如交易所)的访问。决定数据是否属于特定实体(如交易所)的信息包含在数据本身,有时被称为DACS锁,它定义了访问数据所需的权利。为了从基于内容的授权服务中访问数据,用户必须被授予对服务和实体的访问权。对于Refinitiv实时API,DACS锁可在Refresh/Image响应消息的标题中找到。如果在响应消息中提供了DACS锁,那么它就是一个基于内容的授权服务,OpenDACS应用程序必须使用该DACS锁对所有请求(或已经消费)相关数据的用户进行权限检查;有可能收到DACS锁的更新值,但除非你在消费新闻,否则这应该是一种罕见的情况。

对于缓存或存储数据的OpenDACS应用,DACS锁也必须与数据一起存储,以便在检索时可以进行权利检查。

Refinitiv实时数据源产品,如Refinitiv Real-Time(以前的ERT)都使用基于内容的授权,因为它提供了遵守这些数据源的所有不同商业政策所需的灵活性。

有关DACS锁剖析的更多信息,请参阅《DACSLOCK API开发人员指南》(DACSLOCK API Developers Guide),RFA开发人员工具包文档中也提供了该指南。

使用报告(Usage reporting)

DACS可以记录以下类型的使用事件。

  • 成功的用户登录尝试
  • 被拒绝的用户登录尝试
  • 成功的用户信息打开
  • 被拒绝的用户信息打开

任何Refinitiv实时分发系统(RTDS, 以前的TREP)或OpenDACS应用程序执行的每项授权检查都将产生一个使用记录,并由DACS存储,该信息用于产生使用报告,是DACS管理的一个重要成本节约功能。作为OpenDACS的开发者,重要的是你要以支持这一功能的方式来实现你的应用程序;要做到这一点,请遵循《OpenDACS C++开发者指南》中给出的建议(这一信息不包括在Java版本中),关于对使用记录的控制,即使在服务使用基于内容的授权, 在权利检查期间提供的参数值应该是完整和准确的,确保所有权利检查要包括被查询项目名称(Item Name)。

OpenDACS 应用程序提取用户配置文件信息(例如,使用 getPEList() 方法),并以此来确定用户是否有权限,不会触发任何形式的使用记录。这是一个特殊的用例,通常涉及到与缓存或存储项目的整合挑战(它不会对授权检查提供任何显著的性能优势,因为用户资料已经被保存在OpenDACS的内存空间中)。为了生成使用记录,使用通过应用用户资料信息产生的数据集来追溯进行谨慎的授权检查。

DACS On Demand

On-Demand功能在最初向交易所请求数据时自动提供对选定交易所数据的访问。该功能在OpenDACS接口处暴露。如果应用程序向OpenDACS表明应考虑按需权限,或在执行权限检查时没有提供指示(默认),那么DACS将自动为该用户授予交易所权限(如果该交易所已启用按需权限)。请注意,这将产生该报告期的费用。

DACS Web Services

DACS Web服务功能为创建/查询和更新DACS数据库中的权益信息提供了程序化的接口。它与OpenDACS没有关系,实时检查用户的授权请使用OpenDACS来进行。

DACS 拓扑结构

 数据访问控制系统在逻辑上可分为三个主要部分。

  • DACS站点组件,提供管理功能和持久性存储的数据库。
  • 构成DACS基础设施的DACS操作组件,持有并分发操作许可数据。
  • DACS运行客户,他们是收费数据的消费者,需要DACS提供的权限控制服务。

一个OpenDACS应用程序将以与Refinitiv实时分发系统组件相同的方式连接到DACS基础设施 - 它们都是DACS客户端,这被称为操作组件,因为生产环境所需的权利服务取决于它,该组件的故障将阻止任何进一步的登录请求。相比之下,DACS站点组件只影响管理活动,操作组件将在没有它的情况下继续按要求执行。

注意:DACS Web服务功能是在DACS站点组件中实现的,它不具有与操作组件相同的性能或弹性,因此它不能被纳入操作/生产的关键活动中。

DACS Operational Components

DACS操作组件,也被称为DACS基础设施,由两个主要进程组成,DACS Server和DACS Sink daemon。

DACS Server提供三个主要功能。

  • 支持对并发用户登录的控制。
    • 为了做到这一点,它在内存中保存用户登录与位置/显示和应用的状态。
  • 支持对用户授权信息的分发。
    • 为了做到这一点,DACS Server持有一份加密后的操作权限数据库。此数据库由 DACS station组件产生。
  • 分发执行授权检查时所需的数据字典和映射表。
    • DACS Server持有一份由DACS station组件生成的二进制编码的操作权限字典的进程内副本。

DACS Sink Daemon提供访问点,为所有DACS客户端应用提供权限服务,包括RTDS(以前的TREP)基础设施组件(如ADS)和OpenDACS应用。

为了执行授权检查,一个应用程序必须连接到DACS Sink Daemon。

DACS 站点(DACS Site)

DACS系统中的用户定义可能会被划分到若干个站点。

DACS操作组件和客户也在这些站点内被划分,有一个主(本地)站点和一些远程站点。

每个站点作为DACS站内的一个独立实体进行管理和执行,例如,在站点B上定义的DACS用户并不可以赋予在站点A上的用户任何存在或权利。跨站点的操作组件之间没有通信。

对于OpenDACS应用来说,这将需要考虑其用户可以定义在不同的DACS站点。

OpenDACS 提供了一个多连接功能,允许一个应用程序跨站点进行权利检查,但该应用程序必须知道用户配置文件所在的站点,或有一些方法从用户名中得出,或依次 "调查 "每个站点(对于这中情况,有一个假设,即用户名在各站点是唯一的)。

参考

Q&A 论坛

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?

参考文档

OpenDACS Multi-connect option document

OpenDACS C++

OpenDACS Java

OpenDACS .NET

RFA C++ DACSLOCK API Developers Guide

RFA .NET DACSLOCK API Developers Guide