Table Of Contents

The AUTH Component

User authentication

User management with AUTH

Profile management

Creating new users

AUTH's database

The auth database schema

Example configuration of the auth database

Starting AUTH

Conclusion

The AUTH Component

---

This section describes AUTH, the MWFM NMOS authentication engine. AUTH is the component which handles security, authentication and user privileges for MWFM NMOS and the extension modules.

User authentication

AUTH does not interact directly with MWFM NMOS components; it operates separately and supervises all transactions users attempt to enact, to ensure they have the correct privileges to manage the network or configure MWFM NMOS.

When a MWFM NMOS component is launched it runs an authentication procedure, which communicates with AUTH to check that the user requesting the application has the appropriate privileges to do so. If AUTH validates them an authentication approval is returned and the MWFM NMOS component launched, otherwise the process is terminated.

User management with AUTH

AUTH comprises two main components, a user name and profile. User management in AUTH is a two stage process, as shown below:

1. Profile creation.

2. User creation and profile assignment.

The first step in managing users is creating a profile (analogous to user groups in UNIX), which defines the permissions of its members. The second step is the creation of the username with its associated password and assigning the user to a profile defined in the first step. By default, AUTH comes with a predefined user name `root' which has a `super' profile. During configuration, this enables the system administrator to construct profiles for other users; for instance, network managers and network operators.

---

Note The default `super' profile is omnipotent and is the top rank of authentication. During configuration it allows the system administrator to establish other user profiles.

---

Profile management

AUTH allows you to assign specific privileges or permissions to a "group" known as a profile. It is perfectly acceptable for you to assign many users to a single profile provided you are aware that they have common permissions.

Additionally, you can also restrict what actions a profile can perform in relation to each AOC. For example, you may allow a profile to view every aspect of MWFM NMOS, enabling members of the profile to create poll definitions and event methods within the AOCs, but disable their capacity to change or delete any items associated with them.

Profile rank

The profile rank is the final attribute of the profile definition that requires configuration when setting up user profiles. It determines which profiles can make changes to other people's profiles. Any user that belongs to a profile with a rank higher than yours can change your user attributes and profile; of course, you can make the same changes to a user ranked lower than yourself but it is not possible to modify your own profile, only your password.

Creating new users

A new user is constructed by entering an appropriate user name and password, then verifying this password. Once a user has been defined, it is necessary to appoint them with a profile. This requires a user profile to be constructed and then assigned to the specific user name.

AUTH's database

AUTH uses a database called the Auth database (auth) to store information on each user including their name, password, profile, rank, and access privileges. The Auth database contains two tables, the users table (auth.users) and the profiles table (auth.profiles).

The users table

The users table stores the following textual information about users:

•The name of a user

•A password associated with a user

•The name of the profile to which the user belongs

The profiles table

The profiles table contains information about a user's rank relative to other users and a list of permissions available for that user. The type of information contained in this table is listed below:

•The profile category of the user

•An integer used to establish a hierarchy or rank amongst users

•An object list of permissions available for the users that are assigned to the profile

Configuring the permissions list in the profile table

The permissions list in the profiles table consists of one attribute, Users, which has four configurable fields. These fields refer to the ability of the current profile to view, change, create, and delete users from the user list. The relevant fields are listed in the following table:

Table 17-1 Fields available in the Users attribute of the permissions list

Field	Datatype	Description
pView	Integer	A flag which determines whether the user has permission to view the user list. Access denied (0); Has access (1).
pChange	Integer	A flag which determines whether the user has permission to make changes to a user in the user list. Access denied (0); Has access (1).
pCreate	Integer	A flag which determines whether the user has permission to create a user in the user list. Access denied (0); Has access (1).
pDelete	Integer	A flag which determines whether the user has permission to delete a user from the user list. Access denied (0); Has access (1).

---

Note A list of the names of all users that appear in the auth.users database.

---

In the case of the default `root' user, whose profile would be `super', the fields displayed above would all be assigned a value of 1. Alternatively, a `read-only' profile would have a value of 1 assigned in the pView field and all other fields would be assigned a value of 0.

The auth database schema

The schemata of the users and profiles tables of the auth database are shown below.

Table 17-2 Synopsis of the auth database and its tables

Database name	auth database: auth
Database definition location	$RIV_HOME/etc/AuthSchema.cfg
Fully qualified database table names	users table: auth.users profiles table: auth.profiles

Table 17-3 The users table: auth.users

Table column name	Properties (column constraints)	Column data type	Description
Name	PRIMARY KEY NOT NULL UNIQUE	Text	A unique sequence of characters used to specify the name of a user.
Password	NOT NULL	Text	A unique sequence of characters used to determine that a user requesting access to the system is really that user.
Profile	NOT NULL	Text	A unique sequence of characters used to specify the profile category of users.

Table 17-4 The profiles table: auth.profiles

Table Column Name	Properties (column constraints)	Column Data Type	Description
Profile	PRIMARY KEY NOT NULL UNIQUE	Text	A unique sequence of characters used to specify the profile category of users.
Rank		Integer	Determines the relative position of users within this profile with respect to other profiles. Enables a hierarchy of profiles to be established.
Permissions		List of Object type permission	A list of permissions associated with profiles.

If alterations are made to the schema, any cached information must be deleted and AUTH must be restarted.

Example configuration of the auth database

The following example inserts that are appended to the end of the AuthSchema.cfg configuration file show you how to create additional users with different access rights to the NMOS databases.

Creating profiles with different permissions

The following examples show how you would create different profiles with varying levels of access to the NMOS databases.

The super profile

The following example shows the creation of the "super" profile with the highest rank (rank 0) and full permissions:

insert into auth.profiles ( Profile, Rank, Permissions ) values ( "super", 0, [ { Views = { pView=1, pChange=1, pCreate=1, pDelete=1 } }, { Users = { pView=1, pChange=1, pCreate=1, pDelete=1 } } ] );

The read-only profile

The following example shows the creation of the "readonly" profile, with a lower rank (in this instance, 5) than the super profile—it can be altered by the higher ranking "super" profile at any time. The "readonly" profile defined below is configured to have permission to view but not alter the NMOS databases:

insert into auth.profiles ( Profile, Rank, Permissions ) values ( "readonly", 5, [ { Users = { pView=1, pChange=0, pCreate=0, pDelete=0 } } ] );

Creating users with different profiles

The following examples show how you can create some more users with different profiles:

The root user

The following example creates the "root" user and assigns it the "super" profile:

insert into auth.users ( Name, Password, Profile ) values ( "root", "", "super" );

---

Note This example creates a super user with no password. This action would not normally be advisable in any kind of security-conscious network environment.

---

Other users

The following example creates a user called "viewer" belonging to the "readonly" profile created in the previous examples:

insert into auth.users ( Name, Password, Profile ) values ( "viewer", "", "readonly" );

---

Note This example creates a user with no password. Because the user is given the readonly profile, it is not such a security risk.

---

Starting AUTH

There are no prerequisites for running AUTH. However, like other MWFM NMOS components, AUTH is domain-specific and a valid domain name must be specified in the command line. AUTH is started using the following command line:

riv_auth -domain <DOMAIN_NAME> [-latency <TIMEOUT>] &

auth

Domain name under which the NMOS process is being run.

auth.users

Enables you to specify the maximum time in milliseconds that AUTH will wait to connect to other NMOS processes via the messaging bus. This option is advantageous in large and busy networks where the default settings can cause the process to assume that there is a problem when in fact the communication delay is a result of network traffic. Note This is different from the device response timeout, which refers to the maximum time to wait for a response from a device on the network.

A help option can be accessed using the following command line:

riv_auth -help &

auth.profiles

Prints out a synopsis of all the command line options for running AUTH. AUTH is not started even if -help is used in conjunction with other arguments.

It is possible to have multiple AUTH components operating for every running domain.

Conclusion

This chapter has detailed AUTH, the MWFM NMOS component responsible for managing and configuring security and user privileges to ensure no unauthorized access occurs. You have also been shown some examples of how to configure different profiles and assign different users to these profiles.