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

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

Configuring multiple accounts for administrator

To reduce the dependency on one administrator, as a Remedy SSO administrator, you can use the new Admin User Management tab on the Remedy SSO Admin console to create multiple administrator accounts in your organization. For more information, see Setting up Remedy SSO administrator accounts.

Remedy SSO administration lockout policy

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

The administrator lockout policy is applicable to internal administrators only.

Remedy SSO end users lockout policy

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. 

Performing Remedy SSO administrative activities by external users

To distribute responsibility of an RSSO administration, you can configure external users as administrators after the successful LDAP authentication in Remedy SSO. This configuration ensures that after the authentication, these external users can log in to Remedy SSO Admin Console and perform all Remedy SSO administrative activities. These external users follow the password policies enforced by LDAP. The login and logout activities of an external administrator are displayed in the Remedy SSO log files. During the logout activity, the tokens of the external administrators are invalidated.
For instructions on how to configure LDAP for external users, see Configuring general settings for Remedy SSO server.

Enabling signed SAML metadata for security

To ensure that the security policies of your organization are followed, you can now sign the SAML metadata. For this, a new Sign Metadata field is added on the Remedy SSO Admin Console. When the SAML realm is configured for signing metadata, the RSSO server gets the certificate and private key from keystore's alias and signs the metadata with it.

For more information on enabling the signing metadata, see Configuring Remedy SSO to authenticate users with SAMLv2.

Ensuring more secured and restricted access to the cookie

The domain attribute of the cookie determines which domains can access the cookie. In earlier versions, while installing the Remedy SSO server, by default, the value of the cookie was set to the parent domain. Because of this, the parent domain and its sub-domains could access the cookie, and if the cookie carried any sensitive data, then that data was accessible to all the less trusted or less secure applications hosted on these domains. From this release, you can now 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 this cookie domain value either during installation, or through the Remedy SSO Admin Console. For more information, see Configuring general settings for 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, 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