User authentication and permissioning
Liberator supports a flexible modular system for authenticating users and permissioning them.
What are user authentication and permissioning?
Authentication is the process of determining whether someone is who they say they are. In networks such as the Internet, authentication is commonly done through the use of login passwords: knowledge of the password is assumed to guarantee that the user is authentic. The user must know and use the declared password. Liberator requires that client applications log in to it supplying a username and password on behalf of the application user.
Permissioning (also called authorization or entitlement) is the process of giving someone permission to do or have something. For example, in a financial trading system it would involve granting or denying a user access to particular classes of instruments, to view them or to trade them.
How does Liberator implement user authentication and permissioning?
Liberator uses an auth module to authenticate users and grant or deny them permission to access objects and send messages. The auth module implements Liberator’s Permissioning Service.
Basic auth modules
When you don’t have an external permissioning system to supply Liberator with permissioning data, you can use one of the following auth modules.
openauth
This is the simplest of the auth modules. You use it for Liberator installations where no authentication or permissioning is needed. openauth allows any username to log on to the Liberator with any password. You can also specify whether all users have either read or write access to any object in the system, or both.
cfgauth
This auth module enables you to configure the number of users and the types of objects they can read. It’s intended for Liberator installations with relatively low numbers of users where the usernames and other details don’t need to be changed often.
XMLauth
With XMLauth you can use XML to define your own own permissioning structures and control entitlement to objects held on the Liberator.
tokenauth
Use the tokenauth module when your client applications use a single sign-on system incorporating KeyMaster.NET. The module accepts user credentials tokens that have been created by a.NET application built with the KeyMaster.NET API. The token can contain permissioning information relating to the end-user authorised by the token. Tokenauth can interpret the permissions and grant or deny the user’s access to the relevant resources. Also see, Single sign on support using KeyMaster below.
Permissioning blades
The Caplin Deployment Framework comes with two built-in Liberator Config blades that enable basic user authentication and permissioning functionality; the C-based OpenPermissioning blade and its Java-based equivalent JavaOpenPermissioning . See Configuration and blades. Caplin can also supply a Permissioning Service blade; there’s more about this below.
The Permissioning Auth module and Permissioning Adapters
If you have your own existing permissioning system, you can hook it up to the Caplin Platform so that Liberator and client applications can obtain their permissioning data from the system and act on it accordingly.
To do this, you write a Permissioning Adapter using the Permissioning Integration API of the Caplin Integration Suite. This Adapter obtains user authentication and permissioning data from your permissioning system, transforms it into a standard format, and passes it on to the Liberator’s Permissioning Auth module.
Between them, the Permissioning Integration API and Permissioning Auth module enable you to implement sophisticated permissioning models. You can also upload selected permissioning data to a Caplin Trader client application, so the application can directly control what the user can see and do based on the permissions they’ve been granted.
Here’s a diagram showing how the permissioning components of the Caplin Platform fit together, including Liberator’s Permissioning Auth Module and the Permissioning Integration API in a Permissioning Adapter.
Permissioning Service blade
You can easily install and configure a Permissioning Auth Module into Liberator by deploying the Permissioning Service blade, as shown in the diagram above. This Service blade enables the Liberator to handle permissioning data received from a Permissioning Adapter. You can also write your own Permissioning Service blades.
Custom auth modules
You can implement your own custom auth modules using APIs supplied with Liberator. There’s a C-based API and a Java-based one.
Single sign-on support using KeyMaster
In most systems that use Liberator, such as single dealer portals for financial trading, the users log in to an existing web server and subsequently connect to Liberator to obtain streaming data (and trade if they’re running a financial trading app). It’s not a good idea to make the users explicitly log in to Liberator when they’ve already logged in once, so you’d typically do the initial log in through a single sign-on system.
Caplin’s KeyMaster component integrates with any single-sign on system. It creates secure authentication tokens (user credentials tokens) that Liberator uses to authenticate login requests. The end-user isn’t aware of the extra login to Liberator, because the client app uses the credentials token to log in on the user’s behalf.
See also: