The five security models
Five security models exist in MainView Middleware Administrator (MVMA). 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:
- The ADMIN_ADMIN model
- The LDAP_ADMIN model
- The LDAP_LDAP model
- The PREAUTH_ADMIN model
- The PREAUTH_LDAP model
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.
Note
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.
Note that the ADMIN_ADMIN security model does not support enhanced security features such as, for example, a password policy. To ensure access security you must choose a strong password and change any default password. For implementing stronger security policies such as stricter credentials management, BMC recommends alternatives such as LDAP or Active Directory.
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 MainView 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.
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 |
ADMIN_ADMIN | Internal/Internal | All Functionality |
LDAP_ADMIN | External/Internal | All Authorization Functions |
LDAP_LDAP | External/External | Only Permissions |
PREAUTH_ADMIN | External/Internal* (see the note below) | Authorization Functions |
PREAUTH_LDAP | 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.
Comments
Log in or register to comment.