Security planning

This topic describes the following security requirements for BMC Helix 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 BMC Helix 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 BMC Helix SSO node happen only through HTTPS.

However, the interactions between integrated applications and the BMC Helix 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 BMC Helix 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.

BMC Helix SSO supports the X-Forwarded-Proto and X-Forwarded-Host headers that might be sent by the load balancer with a request. BMC Helix SSO considers the information that comes from the headers while it is generating a login URL (pointing to the BMC Helix 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 BMC Helix SSO. BMC Helix 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 BMC Helix 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.
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 BMC Helix 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. During installation of the BMC Helix SSO server, the default value of the cookie is set to the parent domain. Because of this setting, the parent domain and its sub-domains can access the cookie, and if the cookie carries any sensitive data, that data is accessible to all less trusted or less secure applications hosted on these domains. To prevent this vulnerability, you can set the cookie domain value to the domain on which the BMC Helix 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 BMC Helix SSO Admin Console.

You can also enhance the security by tying the cookie to the path attribute, which limits the scope of the cookie to the /rsso path on the BMC Helix SSO server. This limitation prevents unauthorized access to the cookie from other applications on the same host. The path-specific cookie is enabled in the BMC Helix SSO Admin Console. The following diagram demonstrates how this feature affects cookie sharing:

For more information, see Configuring-settings-for-the-BMC-Helix-SSO-server.

BMC Helix SSO operation with specific database features

BMC Helix 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 BMC Helix 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 BMC Helix 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 BMC Helix SSO

For security reasons, in the Admin User tab, the BMC Helix SSO administrator can create and manage multiple administrator accounts. The BMC Helix 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-BMC-Helix-SSO-administrator-accounts.

User accounts lockout policy

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

Important

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

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