# Cfgauth configuration

The following configuration items set up authentication and permissioning information for Liberator’s **cfgauth** [auth module](liberator-user-authentication-and-permissioning.md#how-does-liberator-implement-user-authentication-and-permissioning)

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

**📌 NOTE**\
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](liberator-user-authentication-and-permissioning.md).

The general [auth module configuration](liberator-auth-module-configuration.md) also applies to cfgauth. In particular, you use an [auth-module](liberator-auth-module-configuration.md#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](../deployment-framework/index.md) version 6.2.1 or later, there’s a built-in **CfgPermissioning** [Config blade](../deployment-framework/cdf-blade-types.md#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](liberator-openauth-configuration.md) module):

```
./dfw xref:../deployment-framework/cdf-the-deployment-framework-command-utility-dfw.md#deactivate[deactivate] OpenPermissioning
./dfw xref:../deployment-framework/cdf-the-deployment-framework-command-utility-dfw.md#activate[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 xref:../deployment-framework/cdf-the-deployment-framework-command-utility-dfw.md#deactivate[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.

   **💡 TIP**\
   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](#sigcheck) option is supplied, cfgauth always authenticates the user against the signature in a credentials token, otherwise it authenticates against the user’s [password](#password).

**Syntax:**

```
add-user
   xref:username[username] [string]
   xref:password[password] [string]
   xref:licenses[licenses] [integer]
   xref:read[read]     [array of integers]
   xref:write[write]    [array of integers]
   xref:prefix[prefix]   [string]
   xref:sigcheck[sigcheck] [boolean]
   xref:siguser[siguser]  [string]
   xref:http[http]     [boolean]
   xref:expire[expire]   [string]
end-user
```

| Option | Type | Default | Description |
| --- | --- | --- | --- |
| `<a name="expire"></a>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. |
| `<a name="http"></a>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](liberator-http-configuration-part-2.md#add-authdir) configuration item in which the [check-module](liberator-http-configuration-part-2.md#check-module) option is set to `TRUE`. |
| `<a name="licenses"></a>licenses` | integer | `1` | The maximum number of concurrent Liberator sessions that a licenced user can have. |
| `<a name="password"></a>password` | string | +[none]+ | The password for this user. If [encrypted-passwords](#encrypted-passwords) is set to 1, the passwords must be encrypted using the **cfgpass** utility NOTE: Cfgpass is only available in Linux-based Liberator installations. To run **cfgpass:** . 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) . Type the command `./cfgpass`. . When prompted, enter the password twice. **cfgpass** then displays the encrypted version of the password. |
| `<a name="prefix"></a>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` |
| `<a name="read"></a>read` | array of integers | +[none]+ | A space-separated list of the object types that this user can read. The supported object types are: * `0` Unknown Objects * `1` System Information Objects * `20` [Directory Objects](../datasource/datasource-directories.md) * `21` [Page Objects](../datasource/datasource-pages.md) * `22` [Record Objects](../datasource/datasource-records.md) * `23` [News Headline Objects](../datasource/datasource-news-headlines-and-news-stories.md) * `24` [News Story Objects](../datasource/datasource-news-headlines-and-news-stories.md) * `27` [Chat Objects](../streamlink/streamlink-streamlink-data-types.md) **Unknown Objects** are objects that have been requested from an [active](../datasource/datasource-active-subscription-model.md) 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/` |
| `<a name="sigcheck"></a>sigcheck` | boolean | `FALSE` | When `TRUE`, the [password](#password) option is ignored and instead the cfgauth module authenticates this user against the signature in a credentials token supplied by [KeyMaster](../keymaster/index.md). If you set sigcheck to TRUE, you must supply a value for [siguser](#siguser). |
| `<a name="siguser"></a>siguser` | string | +[none]+ (But option doesn’t apply unless [sigcheck](#sigcheck) is `TRUE`) | A signature key used to authenticate this user against the signature in a credentials token supplied by KeyMaster. If [sigcheck](#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](../datasource/datasource-keymaster-configuration.md#key-id) option of an [add-sigkey](../datasource/datasource-keymaster-configuration.md#add-sigkey) configuration entry. (This means you can have several users for whom the cfgauth module uses the same signature checking key.) |
| `<a name="username"></a>username` | string | +[none]+ | The username for this user. |
| `<a name="write"></a>write` | array of integers | +[none]+ | A space-separated list of the object types that this user can write to. The supported object types are: * `0` Unknown Objects * `1` System Information Objects * `20` [Directory Objects](../datasource/datasource-directories.md) * `21` [Page Objects](../datasource/datasource-pages.md) * `22` [Record Objects](../datasource/datasource-records.md) * `23` [News Headline Objects](../datasource/datasource-news-headlines-and-news-stories.md) * `24` [News Story Objects](../datasource/datasource-news-headlines-and-news-stories.md) * `27` [Chat Objects](../streamlink/streamlink-streamlink-data-types.md) **Unknown Objects** are objects that have been requested from an [active](../datasource/datasource-active-subscription-model.md) 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](#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:**

* Reference: [Auth module configuration](liberator-auth-module-configuration.md)
* [User authentication and permissioning in Liberator](liberator-user-authentication-and-permissioning.md)