This documentation supports the 19.08 version of Remedy Single Sign-On.

To view an earlier version, select the version from the Product version menu.

Security planning

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

Related topics

Installing

Upgrading

Apache Tomcat security guidelines

Ensuring security for sensitive data

User credentials and authentication tokens are sensitive data that must be secured. To secure this data, you must configure HTTPS.

To use HTTPS connections, ensure that SSL certificates are generated, signed, and imported on the Tomcat server (for a standalone environment) or the load balancer (for a High Availability environment).

HTTPS configuration 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 theRemedy SSO node happen through either HTTP or HTTPS, depending on the configuration.

Network configuration for simple deployment use case

HTTP configuration 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 happen through HTTP.

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 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.

Network configuration for HA mode

Configuring Tomcat security

Tomcat is not shipped with Remedy Single Sign-On. Remedy Single Sign-On is installed on an existing Tomcat. Hence, a system administrator should tune Tomcat security. 

Best practice

BMC recommends to see 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:

HeaderValueDescription
X-XSS-Protection

Set the value to 1.

Stops pages from loading when a browser detects reflected cross-site scripting.
X-Content-Type-OptionsSet 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. 

This setting is recommended if Remedy SSO is available via both HTTP and 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.

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.

Related videos

Watch the video on how to manage SSL Certificates with SSL offloading.

Note

The following video shows an older version of Remedy SSO. Although there might be minor changes in the user interface, the overall functionality remains the same.


 https://www.youtube.com/watch?v=jFbKpzJX4pk?rel=0

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

Comments