This documentation supports the 9.1 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 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.

Preventing Tomcat version exposure

Tomcat, by default, displays its current version number on an error page. An exposed Tomcat version can be used by an attacker to search for known exploits specific to that version. With this information, an attacker can develop a scenario that can exploit the vulnerabilities of the specific version that is being used by a target host. To secure the system from such an attack, you must configure the Tomcat settings to hide the version display.

You can use one of the following methods to hide the version number of Tomcat:

 Also, for security reasons, ensure that the latest stable version of Tomcat server 7.x or later is installed.

Configuring the web.xml file

You can use the web.xml file to display a custom error page that does not contain the Tomcat version. If you have deployed multiple web apps into the ROOT folder, you need to update the web.xml for each of the applications. Consider that:

  • Your web app is deployed into the Tomcat ROOT context.
  • You already have custom error pages Errorpage_500.html and Errorpage_404.html for errors 500 and 404 respectively.

Perform the following steps to display the custom error pages:

  1. Go to the $CATALINA_HOME/webapps/ROOT/ directory.
  2. Open the web.xml files and add the following code in the file.

    <error-page>
      <error-code>500</error-code>
      <location>/errors/Errorpage_500.html</location>
    </error-page>    
    
    <error-page>
      <error-code>404</error-code>
      <location>/errors/Errorpage_404.html</location>
    </error-page>    
  3. Test by sending a request for a non-existent file to your tomcat instance verify that your custom error page is displayed.

Configuring the ServerInfo.properties file

You can use the ServoInfo.properties file to display a custom error page that does not contain the Tomcat version.

  1. Go to $CATALINA_HOME/lib.
  2. Create the org/apache/catalina/util directory.
  3. Create a ServerInfo.properties file.
  4. Open the ServerInfo.properties file and the server.info parameter and set it to a value that you want the error page to display.
  5. Restart the Tomcat server.
  6. Test by viewing an error page and verify that the error page displays the value that you had set instead of the Tomcat version.

For example, consider that CATALINA_HOME is set to /home/tomcat. Run the following commands.

1. cd /home/tomcat/lib
2. mkdir -p org/apache/catalina/util
3. cd org/apache/catalina/util
4. $ vi ServerInfo.properties
5. Add the following parameter.
   server.info=Apache Tomcat Version X
6. cd $CATALINA_HOME/bin
7. ./catalina.sh stop
8. ./catalina.sh start

To secure the session cookie of the Admin console, modify the web.xml file located in the path <TOMCAT>/webapps/rsso/WEB-INF/ after installing Remedy SSO. Add the following code in the <session-config> element.

<cookie-config>
  <secure>true</secure>
</cookie-config>

Changing encryption key after upgrading Remedy SSO

If you are using Remedy SSO version that is prior to 9.1 SP1, the database password is encrypted by a hard coded key. In case you have upgraded Remedy SSO to 9.1 SP1 or higher OR you want to change the database password or encryption key for security reasons, then you may want to change the encryption key and encrypt the database password again.

Perform the following steps to change the encryption key and re-encrypt the password for each Remedy SSO server node.

  1. Determine the new encryption key
  2. Run the following command to obtain a new password for the database user.

    java -jar rsso-ds-9.1.01.jar <password> <new-key>
    where,
    * <password>: Is the unencrypted password of the database user. 
    * <new-key>: Is the new encryption key.
    * rsso-ds-9.1.01.jar: Can be found in the <tomcat>/webapps/rsso/WEB-INF/lib folder.
  3. For each Remedy SSO server in the clsuter, perform the following steps:
    1. Modify the rsso.key file in the <tomcat>/webapps/rsso/WEB-INF/classes folder.
    2. Change existing line key=<old-key> to key.old=<old-key>, where <old-key> is the current key in rsso.key file.
    3. Add a new line key=<new-key>, where <new-key> is the new key to be applied.
    4. Modify the context.xml file in <tomcat>/webapps/rsso/META-INF folder.
    5. Update the password field as password="AES:<encrypted-password>", where <encrypted-password> is the encrypted password obtained in Step 2.
  4. Log in to the Admin console of Remedy SSO.
  5. On the General tab, click Save without making any change.
  6. Click the Realm tab.
  7. Edit each realm and click Save without making any change.
  8. For each Remedy SSO server, remove the old encryption key from the rsso.key file in the <tomcat>/webapps/rsso/WEB-INF/classes folder.

Note that there is no need to restart the Remedy SSO server after you change the encryption key.

Obtaining Remedy SSO server version information

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

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

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

Comments