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

To view the latest version, select the version from the Product version menu.

Security planning

This section describes the following security requirements for Remedy Single Sign-On (Remedy SSO) application:

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 is generated, signed, and imported on the Tomcat server (for standalone) or load balancer (for High Availability environment).

HTTPS configuration on a standalone system

For standalone installations, HTTPS has to be configured on the Tomcat server in the server.xml file. After the configuration, the interactions between the user and Remedy SSO node happens through HTTPS only. But the interactions between the supported BMC application and Remedy SSO node happens through either HTTP or HTTPS, depending on the relevant configuration.

HTTP configuration on a High Availability system

For High Availability installations, HTTPS has to be configured on the load balancer. After the configuration, while the interactions between the user and the load balancer happen through HTTPS connections, the interactions between the load balancer and the Remedy Single SSO nodes and the supported BMC applications happens through HTTP only.

Decrypting SAML assertions

To encrypt SAML assertions, the identity provider uses one of the following methods: aes-128, aes-192, aes-256.

If aes-192 or aes-252 have been used, you need to perform the following step to enable Remedy SSO to decrypt the SAML assertions:

Update %JRE_HOME%->lib->security by downloading files from the link and following the instructions in the JRE Readme.

Configuring Tomcat security headers

Though content transmitted over an SSL/TLS channel guarantees confidentiality, administrators must ensure that caching of sensitive content is disabled unless the caching is absolutely needed.

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

  • X-XSS-Protection—Set the value as 1, which means Enabled, on all outgoing requests.
  • X-Content-Type-Options headerSet the value as nosniff on all outgoing requests.

Obtaining Remedy SSO server version information

You can obtain the Remedy SSO server version information through the <RSSO Server>/config/server-status URL. But, you must be authenticated as a Remedy SSO administrator before that.

Security improvements in the Remedy SSO agent

The Remedy Single Sign-On 18.08 release includes multiple functional and security enhancements. BMC strongly recommends that you upgrade both, the Remedy SSO server and the Remedy SSO agent, to version 18.08. For compatibility of Remedy Single Sign-On 18.08 with other BMC products, see BMC Solution and Product Availability and Compatibility (SPAC).

Configuring sessions for simultaneous logins

For security reasons, you can now configure the number of active sessions or simultaneous logins for a particular realm. You can also decide whether to invalidate an older session or not allow the user to log in to a new session and display an error message. For this, a new Session Quota field and an Automatically invalidate oldest session on reaching quota checkbox has been added to the Remedy SSO Admin console under the Realm tab.

For more information, see Configuring realms. For information about troubleshooting, see Troubleshooting log on and log off issues.

RSSO administration lockout policy

For security reasons, to make sure that there are no unauthorized logins, the administrators who exceed the number of login attempts due to incorrect password are blocked automatically. Additionally, you can also unblock the locked administrators manually through the Admin User Management tab on the Remedy SSO Admin Console. For more information, see Remedy SSO server general configuration.

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, various security extensions like data encryption techniques from database vendors. The vendor specific solutions also include procedures for disaster recovery, backup, archiving, 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.

Related topic

Installing Remedy SSO by using the installation wizard

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


  1. Martin Penev


    Could you please provide more details about "Securing session cookie for the Remedy SSO Admin console" and "Configuring Tomcat security headers". For securing the cookie, the procedure says that we should add some code in the element. However, we do not have a element in the web.xml file of RSSO at all. The information you have provided for the security headers is highly insufficient. How are we supposed to add these headers? I read that the easiest way for adding headers to applications running on a Tomcat, is through filters included in the application's code. If these headers are really needed, why are they not included in the RSSO code?

    Thank you in advance.

    Best Regards, Martin Penev

    Sep 20, 2018 01:56
    1. Vrishali namdev Galinde

      Hi Martin,

      I shall discuss this with the SMEs and get back to you soon.



      Sep 20, 2018 10:46
    1. Vrishali namdev Galinde

      Hello Martin,

      I have updated the content for securing cookie. Regarding the Tomcat security headers, Tomcat provides a number of Filters which can be configured for use with all web applications using $CATALINA_BASE/conf/web.xml or can be configured for individual web applications by configuring them in the application's WEB-INF/web.xml (Path in example relates to Tomcat v 8.0).

      As we do not ship Tomcat and don't know the version that the customer is using, recommendation for one version may be invalid for other. So, to know more about tuning Tomcat for a particular version or any other Tomcat related configurations, we strongly recommend referring official docs of Tomcat .

      Hope this helps.

      Thanks & Regards,


      Oct 01, 2018 03:12