User authentication and permissioning
Liberator supports a flexible modular system for authenticating users and permissioning them.
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 delegates user authentication and user authorisation to a pluggable auth module. You can write your own auth module using Liberator’s C Auth API or Java Auth API, or you can use one of the set of auth modules packaged with Liberator.
Auth modules supplied with Liberator
Liberator includes the following auth modules, packaged as built-in blades.
openauth
This is the simplest of the auth modules. You use it for Liberator installations where no authentication or permissioning is needed. The openauth module 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.
To enable openauth, activate the OpenPermissioning configuration blade.
cfgauth
The cfgauth module reads user and permissioning data from configuration items. For more information on how to enable and configure it, see CfgAuth configuration.
| The cfgauth module is not suitable for use in production. |
xmlauth
With xmlauth you can use XML to define your own own permissioning structures and control entitlement to objects held on the Liberator.
tokenauth
The tokenauth module retrieves permissioning data from KeyMaster credential tokens. For more information on including permission data in KeyMaster credential tokens, see the com.caplin.keymaster.permissioning package.
To enable tokenauth, activate the TokenPermissioning configuration blade.
javaauth
The javaauth module is a JNI bridge between Java and Liberator, and is the foundation of Liberator’s Java Auth API. The javaauth module does not contain any permissioning logic itself, but instead runs the com.caplin.server.auth.Authenticator class specified in the javaauth-classid configuration item.
The javaauth module is used by the JavaOpenPermissioning blade (built in) and the PermissioningService blade (available separately to Liberator).
Auth modules supplied separately to Liberator
Caplin provide one auth module available as a separate download to Liberator.
Permissioning Auth Module (Permissioning Service)
The Permissioning Auth Module (PAM) and the Permissioning Integration API provide a framework for integrating Liberator with your permissioning systems. The PAM is packaged in the Permissioning Service blade, available as a separate download to Liberator.
The PAM retrieves live permissioning data from an integration adapter. To use the PAM in your own environment, you write an integration adapter that implements the Permissioning Integration API. This adapter obtains user authentication and permissioning data from your permissioning system, transforms it into a standard format, and publishes it to the PAM. For a tutorial on writing a permissioning integration adapter, see Permissioning Integration Adapter.
The PAM and the Permissioning Integration API 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.
Single sign-on support using KeyMaster
Web applications that use Liberator require users to authenticate with two servers: the web application server and Liberator. To overcome the necessity for the user to login twice, the Caplin Platform has a single sign-on (SSO) solution: KeyMaster.
KeyMaster is hosted by the web application server. 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: