The five security models

Five security models exist in TrueSight Middleware Administrator. These models are designed for different customer configurations and security policies. They divide authentication and authorization into operational containers.

The five security models are as follows:

A quick look at some key points about these models:

  • The default model is ADMIN_ADMIN, placing all security mechanisms within the context of the application and in the Product Administrator’s hands.
  • Enterprise security teams provide security policy and requirements - guidelines that you must consider when implementing a security model. The security model used will reflect current implementations of authentication and authorization on an enterprise-wide basis.

Special enterprise configurations exist in which external servers front the enterprise network. In such cases, two special pre-authentication security models are available for implementation.


If the default model (ADMIN_ADMIN) is not appropriate for your enterprise, you change it using functionality contained in the Administration Console. The Security object on the Navigation Panel lets you choose another of the five supplied security models. See Changing a Security Model for further information.

Depending on which model you select, Product Administrator functional options and pattern of work are affected. Changing a security model may impact current projects and work saved. In order to save work, you should change to an alternative security model immediately after product installation. Such a change requires server restart immediately afterwards. 

Note that the Security object is not fully supported in TrueSight Middleware Administrator (Monitor Edition). For example, Product Administrators can modify LDAP_LDAP security settings to accommodate changes in their LDAP environment, but cannot change the security model.

See a summary of the functionality differences between the full version of TrueSight Middleware Administrator and TrueSight Middleware Administrator (Monitor Edition).

Security model naming conventions

Each model names 1) the authentication method used and 2) the authorization method. The two entries are separated by an _ (underscore). The five security models are named logically to reflect the division of functionality between authentication and authorization and the means of handling each.

The following table illustrates the connection between 1) security model selected, 2) functional implications and 3) resultant workflow.

*Represents special model with granularity and experimental characteristic.

Security Model

Authentication/Authorization Functional Division

User Interface Functionality: Authentication/Authorization



All Functionality



All Authorization Functions



Only Permissions


External/Internal* (see the note below)

Authorization Functions


External/External* (see the note below)

Permissions Only

Both _ADMIN and _LDAP are authorization policy/implementation options within the security models. We use the second part of the security model name to point to its authorization purpose. Another example of the naming conventions: in LDAP_ADMIN, LDAP is used only to authenticate users while ADMIN is applied for authorization (user/group management). Note that using these models makes sense where site configurations include an external or proxy server. 

Was this page helpful? Yes No Submitting... Thank you