The Tsecurity system provides authentication and authorization services to custom applications running on the Windows platform. It extends the native authentication services provided by Windows to allow these custom applications to authenticate users defined either on the local machine or in the Active Directory (AD). In addition, it manages lists of users to be provided privileges to these applications and exposes methods for access to these lists.
...
Expand | ||
---|---|---|
| ||
Following is a flow chart of the sequence of events during authentication: Further information about the various timeout periods described in the above flow chart can be found in the Tsecurity Service Configuration [LINK]section of this manual. |
Expand | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
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:
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 [LINK]. |
Expand | ||
---|---|---|
| ||
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:
|
...
Expand | ||
---|---|---|
| ||
The Tsecurity system comes in two different installation packages. First, Tsecurity is included as an integrated piece of a full TSENTRY installation. Alternatively, Tsecurity can be installed as a standalone package. However, both the standalone version of Tsecurity and the integrated version installed with TSENTRY cannot both be installed on the same system at the same time. If a host must be converted from a TSENTRY system to a plain Tsecurity host, or vice versa, the original software should first be uninstalled before installing the new version. In either case, the latest installation files can be obtained from the support section of the TSENTRY web site: http://www.tsentry.com. Once Tsecurity has been installed (either as part of a TSENTRY installation or as a standalone package) there are two additional steps that must be completed before the system will be fully operational:
|
...
Expand | ||
---|---|---|
| ||
The installation process registers the Tsecurity service on the local host. This service is configured to automatically start with Windows and executes under the Tsentry account, which is a local account on the Tsecurity host also created by the installation process. This service is described in more detail in the Tsecurity Service [LINK] section. |
Expand | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
The following registry changes are made by the installation process:
|
...
Expand | ||
---|---|---|
| ||
The Tsecurity service is fully configurable via a configuration file named Tsecurity.exe.config located in the same directory as the Tsecurity service binary executable. This is an XML file consistent with the application config file format specified by Microsoft .NET applications. For detailed information about the configuration of the Tsecurity service, refer to the TsecurityCfg [LINK] section of this manual. |
Expand | ||
---|---|---|
| ||
Following is a sample Tsecurity.config file:
|
...
Expand | ||
---|---|---|
| ||
The Browse Users page is used to specify credentials that can be used to browse the active directory structure. These users are only required in certain situations as described below. The Under normal circumstances, when a client wishes to retrieve the SAK for a given user from a Tsecurity host the client must provide the user’s password. This password is required if all of the following circumstances are true:
In this situation the Tsecurity host must query the Active Directory to retrieve the list of groups in which the user is either explicitly or implicitly (via nested groups) a member. In order to gain access to the Active Directory the Tsecurity host must have a valid set of credentials. Hence, the Tsecurity host uses the credentials of the user himself to gain access. However, there are cases where the client wishes to retrieve the SAK for a user for whom it does not have the password. In this case the client passes an invalid reference (NULL in C/C++ or Nothing in VB.NET) for the password. Still, though, the Tsecurity host must have a valid set of credentials to use while querying the Active Directory. Consequently, the Tsecurity host must be provided a set of credentials for a browse user in each of the domains in which the host must locate users without a password passed from the client. Only one browse user can be specified for each domain, though a single browse user can be specified for multiple domains. The browse user need not actually be a member of the domain, though he must have browse rights to that domain. The browse user credentials are stored in the <TsecuritySettings> section of the Tsecurity.exe.config file. Passwords are encrypted so that they are not stored in plain text. |
Expand | ||
---|---|---|
| ||
The Tsecurity Administrators page is used to define the list of Tsecurity Administrators for the Tsecurity host. As described in the Managing Security Applications [LINK] section, a Tsecurity Administrator has full control of the Tsecurity system. Only a Tsecurity Administrator has the ability to create and destroy Tsecurity Applications and is responsible for specifying the owners of individual Tsecurity Applications. The name of each Tsecurity Administrator is listed as an owner of the special Tsecurity Tsecurity Application, which is stored in the Tsecurity.xml file in the ASCF folder specified on the System Parameters page. |
...
Expand | ||
---|---|---|
| ||
The following sequence demonstrates the creation of a simple new Tsecurity Application from scratch. In this example it is assumed that two users, MyOwner and MyUser, exist in the domain MyDomain, and that MyUser is a member of the MyDomain group MyGroup. To replicate this example on your system, please replace MyOwner, MyUser, MyDomain, and MyGroup with appropriate values for your system configuration. The example Tsecurity Application created below is owned by the domain user MyDomain\MyOwner. It consists of two application privilege classes, Operators and Maintenance. It specifies a domain user MyDomain\MyUser as a member of the Operators application privilege class and a domain group MyDomain\MyGroup as a member of the Maintenance application privilege class. This example further demonstrates how Security Access Keys are calculated under various configuration scenarios, including explicit and implicit privilege class membership.
|
Tsecurity Clients
Expand | ||
---|---|---|
| ||
This section describes how to create a client that interacts with a Tsecurity host system. |
Expand | ||||||
---|---|---|---|---|---|---|
A client application interacts with a Tsecurity host system through an instance of the TPRI.Tsecurity.Client class. This class manages the connection back to the Tsecurity host and exposes several methods for retrieving data from the Tsecurity host.
The required components for creating a Tsecurity client application are described below. Complete information for the TPRI.Tsecurity.Client class is available in the TPRI.Tsecurity.Client API section.
First, an application must create an instance of the client class:
Next, the application must initialize the connection to the Tsecurity host:
Once the application has initialized and connected to the host, it can then authenticate a user:
|
Expand | ||
---|---|---|
| ||
Two example clients are provided along with the Tsecurity system. The code for these clients is installed only if the Examples option is selected under the Custom installation selections during software installation. The two example clients consist of: |