About Liberator

Caplin Liberator is a complete RTTP publishing and subscription management system.

It is designed for clients requiring tens of thousands of concurrent users. It handles both HTTP and RTTP traffic, but features a special high performance publishing engine capable of delivering hundreds of thousands of updates per second from a single server. Caplin Liberator features an advanced push server for streaming real-time data to any RTTP-aware client.

User permissioning and usage monitoring can be carried out in a variety of ways:

using Liberator Auth API (available in C and Java) to write your own Liberator Auth Module for interfacing to a proprietary database or entitlements system.
using the simple built-in file-base authentication, the quickest way to get started with your Caplin Liberator.
using the built-in xml-based authentication module which supports integration with DACS, content based permissioning and supplies a complete user audit trail.

Caplin Liberator supports many RTTP data types, including text fields, fixedformat pages and page updates, logical records and news headlines.

What is a Liberator Auth Module?

Caplin Liberator supports a modular system for handling authentication of users and entitlement of objects. This allows users to be authenticated, objects to have permissions loaded, read and write permissions for a user to be checked and object name mappings to be performed.

A Liberator Auth Module provides a means of modularising the authentication of users and authorisation of access to objects.

Standard Liberator Auth Modules

Caplin Liberator is equipped with three standard Liberator Auth Modules: openauth, cfgauth and XMLauth. The modules cfgauth and openauth are described in the companion document Caplin Liberator Administrator's Guide, in the chapter Authentication and Entitlement.

The XMLauth module is documented in the document XML Auth Module 3.6 User Guide.

Features

A Liberator Auth Module may implement a simplistic name based permissioning model, or a content based permissiong model. It is possible to implement both models within the same Liberator Auth Module.

If the Liberator Auth Module needs to contact a database to obtain permissioning information, then to not unnecessarily delay the Liberator, it is recommended that event callbacks" are used.

In order to satisfy licence restrictions, it may be necessary to implement user ejection, whereby users can be logged out of the Liberator in order for other users to login.

A Liberator Auth Module may also provide monitoring information to RTTP clients by updating system objects.

Creating your own Liberator Auth Modules

There are two main features a Liberator Auth Module must implement:

The initialisation function.
This is the initial entry point into the module from the core server code.
The function table
When Caplin Liberator loads an Liberator Auth Module, a pointer to a structure of function pointers is passed to the initialisation method. This structure must be filled with module-specific implementations of each function.

This is all that is needed to set up and initialise the module. You may need to do some of your own initialisation of resources within the initialisation function. From this point it is left to the functions stored in the function table to handle their various tasks.

The Initialisation Function: A Liberator Auth Module must implement the following initialisation function.

This function should be declared as below:

Example:

void auth_mod_init(nodeinfo_t *nodeinfo, authfuncs_t *funcs, eventcallback_t callback)
{
   ...
}

Example Liberator Auth Modules creating using the Auth SDK

A basic implementation of a Liberator Auth Module.