APM Security
This topic defines terms used when discussing security as well as CA Technologies Application Performance Management (CA APM) security options.
apmdevops97
This topic defines terms used when discussing security as well as CA Technologies Application Performance Management (CA APM) security options.
CA APM Security Summary
CA APM uses these security mechanisms to secure Introscope and CA CEM:
- user- and group-based authentication and authorization access to Introscope and CA CEM:
- file-based Local security using ausers.xmlfile.You can secure Introscope using Local security and use Local authentication and authorization for CA CEM.
- CA EEM.You can secure Introscope using CA EEM and use CA EEM authentication and authorization for CA CEM.For supported CA EEM versions, see the Compatibility Guide.Also see these CA EEM guides, which are included with the CA EEM application for download from the CA Support site:
- CA Embedded Entitlements Manager Getting Started Guide
- CA Embedded Entitlements Manager Release Notes
- Enterprise Manager security:
- public and private keys for secure authenticating between the Manager of Managers (MOM) and Collectors.
- communication between the Collectors and MOM is obfuscated.configuration properties for secure communications between Enterprise Managers and browsers.For more information, see Restricting Enterprise Manager access via HTTPS only.
- configuration properties for secure communications between an agent and an Enterprise Manager.For more information, see the or the .
- configuration properties to allow specific users to see specific Introscope domains.For more information, see Define and Configure Introscope Domains and Securing Introscope.
- configuration properties to allow specific users to shut down specific Enterprise Managers.
- configuration properties to allow specific users to see specific business services and frontends on the application triage map.
- configuration properties to allow specific users to perform dynamic instrumentation.
- configuration properties to allow specific users to perform thread dumps.
- CA CEM security:
- root password protection for the Windows or Linux machine on which the TIM is installed.
- configuration properties to secure communications between the Enterprise Managers and TIMs.
- CA CEM data in the APM database is encrypted and meets FIPS compliance.
- APM database security:
- password protection for the APM database.See Changing the PostgreSQL database passwords.
- secure a connection to the Enterprise Manager.See information about setting an encrypted password in the tess-db-cfg.xml file.
- Introscope and CA CEM applications monitoring:
- user authorization is required for business service based security.See Default CA EEM CEM access policies.
CA APM Security and Permissions Overview
CA APM security, which consists of authentication and authorization, allows individual users and user groups (groups), which are specified sets of users (such as Application Administrators, System Administrators, or Analysts), to securely log into Introscope and CA CEM. Permissions allow users and groups to perform specific Introscope tasks.
User Authentication
Authentication
is the mechanism that securely identifies users. Authentication provides Introscope and CA CEM with answers to questions such as:- Who is this user?
- Is this user really who they are representing themselves to be?
Authentication systems depend on a unique bit of information known only to the individual being authenticated and the authentication system. In order to verify a user’s identity, the authenticating system typically challenges the user to provide the unique information. If the authenticating system can verify that the information presented is correct, the user is considered authenticated.
User Authorization
Authorization
is the mechanism by which a system determines the level of access a particular authenticated user should have to secured resources (such as applications, pages, and data) controlled by that system. In other words, authorization is the process of checking if a user has permission to perform an action on a resource.An
access policy
grants permission to specific users or groups to perform an action on a set of resources of a given type.For example, a database management system might be designed to provide certain individuals with the ability to retrieve information from a database but not change data stored in the database, while giving other individuals the ability to change data. Authorization systems grant these permissions by providing answers to questions such as:
- Is userXauthorized to access resourceR?
- Is userXauthorized to perform operationP?
- Is userXauthorized to perform operationPon resourceR?
Security Realms
A security realm defines a source of users, user groups, and access policies that is responsible for authenticating, authorizing, or authenticating and authorizing users.
You configure one or more security realms for CA APM security in the
realms.xml
file. Introscope and CA CEM use the security realms configured in realms.xml
to decide how to authenticate and authorize users. When a user logs in to either Introscope or CA CEM the application being logged in to checks each security realm in the order defined in realms.xml. The application checks to see whether a user with the given ID exists. The authentication succeeds If the user password supplied matches the value that is provided for the specific security realm. If one of these conditions is in effect, authentication fails:- No user of that name exists in any of the defined realms.
- The user exists in a realm but the password is wrong.
For information about configuring realms in realms.xml, see these topics:
You can deploy Introscope security using one or any supported combination of these three security realms:
- Local security consists of Local authentication and authorization using XML files stored in the Enterprise Manager in the<EM_Home>/configdirectory.
- For Local authentication, an XML file is used to store the username and password information locally on each Enterprise Manager. The default filename isusers.xml. At runtime, Introscope checks the Local file (users.xml) to authenticate CA APM users.
- For Local authorization, Introscope stores two XML files locally on each Enterprise Manager. Introscope usesdomains.xmlfor domain permissions andserver.xmlfor server permissions. At runtime, Introscope checks the Local files (domains.xml and server.xml) to authorize CA APM users.
Introscope provides Local security as the default.Changing the default CA APM login to Enterprise Managers from the Workstation, WebView, Web Start Workstation, or CEM console is a best practice. If this best practice is not followed and only Introscope local security is used, there is an increased chance of identity theft. For this reason CA EEM is the recommended security mechanism. - An application protocol for querying and modifying directory services running over TCP/IP.You can use the LDAP security realm only to authenticate CA APM users if you use Local XML files for authorization.
- A CA Technologies application that allows other applications to share common access policy management, authentication, and authorization services.CA EEM security is optional for Introscope, however, CA Technologies recommends CA EEM for Introscope security for several reasons. CA EEM provides an industry standard solution, a user interface for managing users, and centralized storage that allows fine-grained permissions for authorization. If you want to secure the Introscope application triage map, deploy CA EEM.You can deploy CA EEM to authenticate and authorize CA APM users.You can also configure CA EEM to use LDAP for authentication and CA EEM for authorization.
This table lists the major features that Introscope security realms support.
Supported features by security realm | CA EEM | LDAP | Local |
Centralized security server shared by multiple Enterprise Managers | Yes | Yes | No |
Security realm is always available | No | No | Yes Runs in the Enterprise Manager, so it's always available. |
Supports failover | Yes | Yes | Not applicable |
Integrated with SiteMinder | Yes | No | No |
Supports fine-grained permissions? Supports these fine-grained permission types: Application triage map permissions. Business-service-based security Flexible CA CEM permissions | Yes | Not applicable | No |
Industry standard solution | Yes | Yes | No |
Allows for auditing | Yes | Yes | No |
Includes a user interface for managing users | Yes | Yes | No |
Includes a user interface for managing access policies | Yes | Not applicable | No |
You can deploy CA CEM security using one or any supported combination of these two security realms:
- Local XML files (Local):Local security consists of Local authentication and authorization using XML files stored in the Enterprise Manager in the<EM_Home>/config directory.
- For Local authentication and authorization, an XML file is used to store the username and password information locally on each Enterprise Manager. Four default CEM security groups and the users belonging to these groups are also defined here. The default filename isusers.xml. The authorization check is based on the membership that is defined for four default security groups. At runtime, the Local file (users.xml) is used for authentication and authorization of CA CEM users.
- A CA Technologies application that allows other applications to share common access policy management, authentication, and authorization services.CA Technologies recommends CA EEM for CA APM security for several reasons. CA EEM provides an industry standard solution, a user interface for managing users, and centralized storage that allows fine-grained permissions for authorization.
- You can deploy CA EEM to authenticate and authorize CA APM users.
- Configure CA EEM authentication using CA SiteMinder and CA EEM for authorization.
- Configure CA EEM for authentication only, and Local XML files for authorization.
CA APM provides single login capability. Users who are permitted to access both CA CEM and Introscope can navigate between these two applications without being prompted to log in again. Upon CA CEM or Introscope user authentication, CA APM gets the user identity and the name of the realm that authenticated the user. Introscope uses this information to obtain the groups to which the user belongs. Then CA APM uses one of these methods to authorize the user:
- For CA EEM, the user access policy.
- For Local security, membership in one or more CA CEM security user groups.
In setting up CA APM security, your organization must determine which single or hybrid security realm to deploy. To allow CA APM users to access Introscope, deploy either the Local or CA EEM realm.
CA Technologies recommends that you deploy both CA EEM authentication and authorization.
Benefits of Securing CA APM using CA EEM
CA Technologies recommends that you deploy CA EEM for CA APM security because CA EEM provides these features:
- a common, shared approach to manage user identities and access policies
- Centralized CA APM securityBecause CA EEM authentication allows multiple Enterprise Managers to share the same CA EEM server, you can deploy centralized CA APM security.
- Effective access and entitlements access management
- Business service based security in which you can use access policies to control which CA CEM security groups have access to a business service and its associated data.
- Application security cannot be limited to who can access what application. To be effective, security policies must also enforce the specific actions each user can perform on which resources within the application after they have gained access. CA EEM provides a standard means for organizations to implement flexible and granular authorization policies in their business application portfolios.
- In-process authorization checks entitlement policies are securely cached in the Embedded Entitlements Client portion of the application, then evaluated and executed locally within the application. This enables the enforcement of access policies for offline applications.
- Separation of application-specific policiesCA EEM segregates application-specific policy data in its central repository to ensure separation of policies and administrative controls while enabling application management flexibility.
- Single Identity RepositoryCA EEM includes a repository that can be used as the single authoritative source of user identities. As an alternative, this single source can be an external directory such as Microsoft Active Directory, Novell eDirectory, or SunONE Directory.
- Enterprise integrationYou can deploy CA EEM along with other CA security solutions to achieve consistent Identity and Access Management (IAM) across a complex suite of business applications. This requires security tools like CA EEM that are adaptable, flexible, manageable, and available in the current development environments.
- CA SiteMinder integrationNative integration allows Embedded Entitlements Client applications to access user and group information from the user stores CA SiteMinder is configured to use, authenticate using CA SiteMinder credentials, and support single sign-on with CA SiteMinder web applications.
- SDK in C#, C++ and JavaCA EEM supports development environments in C#, C++ and Java. It is fully documented with C#, C++ and Java references for its authentication, authorization, event management and administrative APIs. It includes sample code and XML scripts plus tutorials on how to embed its security functions into applications.
- Administration web UICA EEM minimizes the cost of establishing and maintaining application security policies, user stores and audit rules by providing a single, web-based management interface. By externalizing security policy administration from the application itself, you can maintain consistent security levels as your business requirements evolve without re-developing application code.
- Shared web UICA EEM provides an out-of-the-box web UI that is shared among all applications for managing users and groups and for defining and managing access policies. Alternatively, you can use the CA EEM SDK to embed administrative UI components into custom web pages.
- Administrative scopingYou can limit administrator permissions to viewing or working on only certain applications, users, resources, or policies.
- Permission checkingYou can test security policies and view detailed policy debug information to ensure they have the desired outcome before making them live.