Cfgauth configuration

The following configuration items set up authentication and permissioning information for Liberator’s cfgauth auth module

Cfgauth enables you to configure authentication for Liberator users and establish simple permissions for the types of objects they access.

The cfgauth auth module is intended for Liberator installations with relatively low numbers of users where the usernames and other details don’t need to be changed often.

For background information, see the Liberator Features and Concepts page about User authentication and permissioning.

The general auth module configuration also applies to cfgauth. In particular, you use an auth-module configuration item to specify that Liberator is to use the cfgauth module.

auth-module cfgauth

The cfgauth.conf configuration file

The configuration for cfgauth is kept in a separate configuration file called cfgauth.conf. If you’re not using the Caplin Deployment Framework, you should put the cfgauth configuration items you require into this file.

The CfgPermissioning blade

From Liberator 6.2.6, cfgauth is activated using a built-in config blade, CfgPermissioning.

In Liberator version 6.2.6 or later

If you deploy Liberator version 6.2.6 or later using the Deployment Framework version 6.2.1 or later, there’s a built-in CfgPermissioning Config blade that changes Liberator’s auth module to cfgauth and supplies a skeleton configuration file for the module. This blade isn’t activated by default. Before activating it, make sure you first deactivate the currently active permissioning blade (if you’ve just installed a new Liberator, this will be the OpenPermissioning blade, which loads the openauth module):

./dfw deactivate OpenPermissioning
./dfw activate CfgPermissioning

The blade’s skeleton cfgauth.conf configuration file is in <Framework-root>/global_config/overrides/servers/Liberator/etc/

(Note that <Framework-root> represents the file path of the Deployment Framework’s topmost directory for the Platform installation). Edit this file to set up the users you require and their access permissions. There are some commented out examples in the file for you to follow.

In older versions of Liberator (6.2.5 or earlier)

In older versions of Liberator (6.2.5 or earlier), there’s no CfgPermissioning blade, so to set up cfgauth:

  1. Deactivate the OpenPermissioning blade:

    ./dfw deactivate OpenPermissioning

  2. Add the cfgauth module to <Framework-root>/global_config/overrides/servers/Liberator/etc/rttp.conf

    auth-module cfgauth

  3. Create a configuration file called cfgauth.conf in <Framework-root>/global_config/overrides/servers/Liberator/etc/cfgauth.conf and put the cfgauth configuration you require in there.

    There’s an example cfgauth.conf file in <Framework-root>/kits/Liberator\Liberator-<version>/etc/. If you want to add more users and permissions to cfgauth, you can copy this file to <Framework-root>/global_config/overrides/servers/Liberator/etc/ and edit that copy. Don’t edit the cfgauth.conf file directly in <Framework-root>/kits/Liberator\Liberator-<version>/etc/

add-user

add-user specifes a Liberator user who will be authenticated by cfgauth, and the access permissions for that user. If the sigcheck option is supplied, cfgauth always authenticates the user against the signature in a credentials token, otherwise it authenticates against the user’s password.

Syntax:

add-user
   username [string]
   password [string]
   licenses [integer]
   read     [array of integers]
   write    [array of integers]
   prefix   [string]
   sigcheck [boolean]
   siguser  [string]
   http     [boolean]
   expire   [string]
end-user
Option Type Default Description

expire

string

NULL

Specifies a start date from which this user is allowed access to the Liberator and the duration in days for which access is valid. The format is YYYYMMDDNN, where YYYYMMDD is the start date and NN is the number of days. For example, 2015042030 allows the user access for 30 days starting from 20 April 2015.

http

boolean

FALSE

When http is set to TRUE, the user is allowed access to specified HTTP directories (HTTP-authenticated directories). Each allowed directory must be specified by an add-authdir configuration item in which the check-module option is set to TRUE.

licenses

integer

1

The maximum number of concurrent Liberator sessions that a licenced user can have.

password

string

[none]

The password for this user.

If encrypted-passwords is set to 1, the passwords must be encrypted using the cfgpass utility

Cfgpass is only available in Linux-based Liberator installations.

To run cfgpass:

  1. Navigate to <Framework-root>/servers/Liberator/bin (where <Framework-root> represents the file path of the Deployment Framework’s topmost directory for the Platform installation)

  2. Type the command ./cfgpass.

  3. When prompted, enter the password twice. cfgpass then displays the encrypted version of the password.

prefix

string

[none]

A prefix that’s added to every subject this user subscribes to, before the subscription is actioned. This effectively personalises the subscription request.

Example:

add-user
   username UserA
   ...
   prefix /TIER1
end-user

add-user
   username UserB
   ...
   prefix /TIER2
end-user

When UserA subscribes to /FX/GBPUSD, the request is actioned as a subscription to /TIER1/FX/GBPUSD

But when UserB subscribes to the same subject, the request is actioned as a subscription to /TIER2/FX/GBPUSD

read

array of integers

[none]

A space-separated list of the object types that this user can read.

The supported object types are:

Unknown Objects are objects that have been requested from an active DataSource application. The actual type of such an object may not be known until the DataSource application returns the object together with information about its type.

System Information Objects include /SYSTEM/AUTH/, /SYSTEM/LICENSE/, /SYSTEM/LICENSING/

sigcheck

boolean

FALSE

When TRUE, the password option is ignored and instead the cfgauth module authenticates this user against the signature in a credentials token supplied by KeyMaster.

If you set sigcheck to TRUE, you must supply a value for siguser.

siguser

string

[none]

(But option doesn’t apply unless sigcheck is TRUE)

A signature key used to authenticate this user against the signature in a credentials token supplied by KeyMaster. If sigcheck is set to TRUE, you must supply a value for siguser. The value must be a signature key id that is the same as the key-id option of an add-sigkey configuration entry. (This means you can have several users for whom the cfgauth module uses the same signature checking key.)

username

string

[none]

The username for this user.

write

array of integers

[none]

A space-separated list of the object types that this user can write to.

The supported object types are:

Unknown Objects are objects that have been requested from an active DataSource application. The actual type of such an object may not be known until the DataSource application returns the object together with information about its type.

System Information Objects include /SYSTEM/AUTH/, /SYSTEM/LICENSE/, /SYSTEM/LICENSING/

encrypted-passwords

encrypted-passwords specifies whether or not the passwords specified in the password option of each add-user item are encrypted.

  • encrypted password 1 means the passwords are encrypted.

  • encrypted password 0 means the passwords are plain text.

Syntax: encrypted-passwords <0-or-1>

Type: integer

Default value: 0 (passwords are plain text)

See also: