The Tsecurity system provides two major functions to the client: authentication and authorization. Authentication refers to the process of verifying that a user is who he claims to be, that is, verifying the password for a given user.  Authorization refers to determining what privileges should be afforded to a given user.

In terms of authentication, Tsecurity provides a number of functions for authenticating a user, checking that the password is valid and has not expired, and changing the password for a given user.  In terms of authorization, Tsecurity provides the concept of a Tsecurity Application for defining classes of privileges and associating those privileges with selected sets of domain users and domain user groups. In both cases, Tsecurity clients connect across the network to a Tsecurity host service and remotely calls functions through the host service.

User authentication through the Tsecurity system has been designed to provide the optimal degree of freedom, flexibility, and, above all, reliability.  Because authentication through the Active Directory server depends on network connectivity, which may be slow or even broken, the Tsecurity system implements a caching system for user credentials and information.  This caching system allows for very fast response to authentication requests and reliability even when the connection to the Active Directory server is down, but at the same time minimizes the possibility of errors in authentication.

User authentication in Tsecurity involves two separate threads.  The primary thread (Thread A) is responsible for the following items:

• Enforcing user-defined timeouts on the network calls used in the second thread.

• Checking for user credentials in the local cache file.

• Ultimately returning the authentication success or failure indication to the client.

The secondary thread (Thread B) is responsible for the following items:

• Authenticating the username and password against the local host (for local users) or against the Active Directory (for domain users).

• Updating the local cache file with the latest known user credentials.

Though the local cache file is an XML ASCII text file, private user information is stored in a hashed format to keep private information such as the user password secure.

Following is a flow chart of the sequence of events during authentication:

Open

Further information about the various timeout periods described in the above flow chart can be found in the Tsecurity Service Configuration section of this manual.

Simply put, a Tsecurity Application is merely the definition of the associations between various domain members and the special subset of privileges that they are given. The term application in this sense does not necessarily refer to a single executable program; although it may be the case that the Tsecurity Application only governs a single executable program, it is better to think of a Tsecurity Application more generally as a set of rules used by a piece of software to control access to itself.

As an example, consider a group of custom-built screens for a rolling mill control system.  The system owner would want his mill operators to be able to control the schedule through the Preset screen.  Maintenance personnel would also be able to adjust the schedule, but should additionally be able to run various tests from the Diagnostics screen.  And above all, engineers should be given rights to both the Preset and Diagnostic screens, as well as being able to adjust any system tuning parameters from the Tuning screen.

Following are definitions of some key terms used within a Tsecurity Application:

• A privilege is a single right that can be given to an application user.

• A domain member is refers to either a user defined on a domain or a group of users defined on a domain.  A domain can be either the local domain or an Active Directory.  The names of domain members are specified in a domain\username format.

• An application privilege class, or more simply a privilege class, is the combination of a group of privileges with a group of domain members.  Each of the domain members contained in a privilege class are given each of the privileges associated with that privilege class.  A privilege class exists only within the definition of a Tsecurity Application.

Continuing the rolling mill example from above:

In order to manage security for the rolling mill applications, the system owner would define a Tsecurity Application named RollingMillScreens.  Within this application there would be three privilege classes defined: Operators, Maintenance, and Engineers.  In addition, there would be three privileges defined: ModifyPreset, RunDiagnostics, and TuneSystem.  Privileges would be assigned to application privilege classes as follows:

Once the privilege classes and associated privileges have been defined, the system owner would need to add domain members to each of the appropriate privilege classes.  For instance, Joe the Operator would be added to the list of members of the Operators group, Jane the Maintenance Tech would be added to the list of members of the Maintenance group, and Bob the Engineer would be added to the list of members of the Engineers group. 

Alternatively, if there is an Active Directory group already defined that contains of all engineers for the rolling mill, this AD group could be added to the Engineers application privilege class in the RollingMillScreens Tsecurity application and any domain user contained in that group in the Active Directory would be given all three of the above rights specified for the Engineers application privilege class.

This complete set of information, including the privileges, application privilege classes, domain members, and each of their interrelationships, comprises a Tsecurity Application. The definition for each Tsecurity Application is stored on the host in a separate XML file called an Application Security Configuration File (ASCF).  These are described in detail in Application Security Configuration Files.

It is important to point out that under the Tsecurity framework the Tsecurity system itself is not responsible for preventing unwanted access to resources; rather it is a tool that allows other custom software to quickly, easily, and reliably determine if a given user should be provided access to some resource within that custom software.  Given that a Tsecurity Application is merely a definition of user access rules within a set of software, it is important to realize that the software itself is ultimately responsible for managing its own the security.

Generally speaking, a custom Tsecurity client would use Tsecurity in the following fashion:

1. The custom client queries the user for his username, domain, and password.

2. The client makes a call into the Tsecurity system to authenticate this username, domain, and password.

3. The Tsecurity system responds, indicating whether or not the password is correct.

4. If the password is not correct, the client denies the user access and requires a valid login.  If the password is correct, the client then makes a second call to the Tsecurity system to retrieve the list of privileges provided to this user within a given Tsecurity Application.  This Tsecurity Application must already be defined on the Tsecurity system.

5. The Tsecurity system then responds with either the appropriate list of privileges or an indication that the supplied user does not have any rights to the Tsecurity Application.

6. The client then uses the returned list of user privileges to modify its behavior accordingly.  For instance, it may enable or disable various displays and inputs depending on whether or not the user has rights to those resources.