Security planning

This topic describes the following security requirements for Remedy Single Sign-On:

Ensuring security for sensitive data

Sensitive data such as user credentials and authentication tokens must be secured by HTTPS configuration. To use HTTPS connections, ensure that SSL certificates are generated, signed, and imported on the Tomcat server on which Remedy Single Sign-On runs (for a standalone environment) or the load balancer (for a high availability environment).

Security on a standalone system

For standalone installations, HTTPS must be configured on the Tomcat server in the server.xml file. When HTTPS in configured, the interactions between end users and the Remedy SSO node happen only through HTTPS.

However, the interactions between integrated applications and the Remedy SSO node can happen through HTTP or HTTPS, depending on the configuration. If you want to configure HTTPS, contact your system administrator or network team.

Security on a high availability system

For high availability installations, HTTPS must be configured on the load balancer. When HTTPS is configured, interactions between end users and the load balancer happen through HTTPS connections.

The interactions between the load balancer, the Remedy SSO nodes, and the supported BMC applications can happen through HTTP or HTTPS, depending on the configuration. If you want to configure HTTPS, contact your system administrator or network team.

Remedy SSO supports the X-Forwarded-Proto and X-Forwarded-Host headers that might be sent by the load balancer with a request. Remedy SSO considers the information that comes from the headers while it is generating a login URL (pointing to the Remedy SSO server) for the end user. This feature keeps all external traffic secure, though the internal traffic, which happens behind the load balancer, may not be secure.

Configuring Tomcat security

Tomcat is not shipped with Remedy SSO. Remedy SSO is installed on an existing Tomcat. Hence, a system administrator should tune Tomcat security.

Best practice
BMC recommends to see the Tomcat documentation before making any changes. Refer to the Tomcat official online guidelines to find a full list of security recommendations, and to stay up-to-date with security guidelines.

General recommendations

BMC recommends some options that should improve security:

For better security, BMC recommends accessing Remedy SSO via HTTPS only.
Though content transmitted over an SSL/TLS channel guarantees confidentiality, ensure that caching of sensitive content is disabled unless caching is absolutely needed.
The default installation of Tomcat includes several web applications, which may not be required in your production environment. Delete these default applications to keep the Tomcat clean, and avoid any known security risk with Tomcat default applications.
Disable or replace the default 404, 403, 500 error pages. Not found, Forbidden, and Server error pages, by default, expose server version details.

Security headers

To ensure that sensitive content is protected, BMC recommends that you configure the following headers in Tomcat:

Header	Value	Description
X-XSS-Protection	Set the value to 1.	Stops pages from loading when a browser detects reflected cross-site scripting.
X-Content-Type-Options	Set the value to nosniff.	Blocks content sniffing by Internet Explorer browser that can transform non-executable MIME types into executable MIME types.
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains - set <expire-time>	Set the value in seconds. For example, 31536000 that corresponds to 1 year.	Sets the period of time for accessing Remedy SSO over HTTPS. Even if you have the HTTP configuration, this setting always switches to HTTPS.

Ensuring more secured and restricted access to the cookie

The domain attribute of the cookie determines which domains can access the cookie. While installing the Remedy SSO server, the default value of the cookie set is to the parent domain. Because of this, the parent domain and its sub-domains can access the cookie, and if the cookie carries any sensitive data, then that data is accessible to all less trusted or less secure applications hosted on these domains. To prevent this, you can set the cookie domain value to the domain on which the Remedy SSO server is installed, and not restrict it to the parent domain. This ensures that the cookie is not accessible to any less trusted applications.

You can set the cookie domain value either during installation, or after installation in the Remedy SSO Admin Console. For more information, see Configuring-the-Remedy-SSO-server.

Remedy SSO operation with specific database features

Remedy SSO does not depend on any external vendor-specific solutions, such as multi-subnet failover environment for MSSQL, Oracle RAC, and various security extensions like data encryption techniques from database vendors. The vendor specific solutions also include procedures for disaster recovery, backup, archiving, and import and export of data.
As a Remedy SSO administrator, you can manually configure the settings by using the JDBC connection string in the context.xml file or by using your database. Even though Remedy SSO is not specifically certified with certain database settings and configurations that the database vendors provide, the product should work with these settings. For any issues related to a supported database or environment, contact BMC Customer Support.

Support for multiple administrator accounts in Remedy SSO

For security reasons, in the Admin User tab, the Remedy SSO administrator can create and manage multiple administrator accounts. The Remedy SSO administrator can block, unblock, delete the administrator account they created, or change its password. For more information about creating and managing multiple administrator accounts, see Setting-up-Remedy-SSO-administrator-accounts.

User accounts lockout policy

To make sure that there are no unauthorized logins, Remedy SSO administrators who exceed the number of failed login attempts due to an incorrect password are blocked automatically. Remedy SSO administrators can unblock the locked administrators manually through the Admin User Management tab on the Remedy SSO Admin Console. For more information, see Configuring-the-Remedy-SSO-server.

The administrator lockout policy does not apply to external LDAP administrators.

Remedy SSO depends on the external identity providers to authenticate end users. To make sure that there are no unauthorized logins, end users who exceed the number of failed login attempts due to an incorrect password should be blocked by the identity provider.