Contents

Secrets and Passwords

The Ubisecure SSO setup script (see the page on Configuration for more information) generates random secrets and passwords that are ready for use. However, these secrets and passwords must be known in clear-text to the Ubisecure applications. These credentials are visible in the files of the Ubisecure SSO installation directory and inside the Tomcat webapps directory.

A backup copy of the Ubisecure installation directory should be kept at a safe location. The configuration files in the installation directory (win32.config and unix.config) should either be removed from the system or otherwise protected from unauthorized users

System Administrator Login and Password

The default password set after installation or upgrade can be found from the win32.config or unix.config file. This default password should be changed to a strong password.

It is important to change the password of the Ubisecure SSO System Administrator to a strong password and store the password securely.

It is possible to change the System Administrator account’s login name to something different from the default.

Use the Ubisecure SSO Management application to change the password of the System Administrator identity. This can be done after the Ubisecure SSO installation has been completed

Select the System site from the Site Navigaton
Select the Users tool
Click the user named Administrator
Click Password and enter a new password

LDAP Connection Credentials

The default OpenLDAP installation with the configuration files generated by Ubisecure configures a root account with full privileges to the LDAP directory. This account is not used by Ubisecure software at run-time. In a secured production environment this account should be disabled. The easiest way to accomplish this is to simply comment out the rootdn and rootpw lines in the file /usr/local/ubisecure/ubilogin-sso/openldap/etc/openldap/<suffix>.conf. The configuration file is in the form cn=Ubilogin,dc=localhost.conf.

Modified <suffix>.conf file with root account disabled

database          bdb 
directory         "/usrc/local/ubisecure/..." 
suffix            "..." # 
rootdn            "uid=System,ou=System,..." # 
rootpw            {SSHA}...

The OpenLDAP server must be restarted after modifying the <suffix>.conf file. Issue the following commands to restart the OpenLDAP server:

OpenLDAP restart

/etc/init.d/ubilogin-directory restart

Restricting Internal LDAP Access

Access to the LDAP server should be restricted in the firewall to allow connections only from the Ubisecure applications on the registered LDAPS port number. If the LDAP server is deployed on the same server with the Ubisecure applications, LDAP server should only listen to connections from localhost.

Restricting External LDAP Access

Any LDAP server that is connected using external directory integration should be done using credentials created specifically for the Ubisecure SSO. The rights of these credentials should be set to the absolute minimum required to complete the desired use case.

Restricting SSO Management API Access

In addition to built-in application controls, access to the SSO Management API can be restricted further to known trusted networks or devices at the transport layer. SSO Management API should be disabled completely if not required.

Firewall

A firewall should be deployed to protect the Ubisecure SSO applications. Access from the public network should be allowed only to the SSL encrypted HTTPS port where the Ubisecure web applications are installed (see uas.url setting in the configuration file).

It is recommended that access to the core applications uas and password are permitted from external networks, and the management console applications ubilogin, search and logviewer are restricted to either local console users or internal network users.

Disable Unused Applications

Any unused applications should be disabled in the context.xml file of the SSO Tomcat server. Unused applications are commented out.

For example, if Common Domain Cookie discovery is not required, it should be commented out.

Instructions for enabling or disabling components can be found in the Password application configuration guide.

Custom Error Message in SSO User Interface

Refer to the Message Hardening section in the Login UI customization - SSO guide for information how to modify system error messages to display less information to the user. An example would be to not reveal that a User ID is correct, but the password is incorrect.

Custom Tomcat Error Pages

Tomcat error pages should be disabled in protection or mapped to generic pages. Pages useful in development or testing (showing stack trace error messages) must not be enabled in production.

Tomcat Version Number Masking

ServerInfo.properties should be modified to mask version number in production

Disable Message Tracing

To assist system testing, a message tracing system can be enabled that shows all a complete list of sent and received authentication messages, included decrypted messages.

If this has been enabled, disable it. The service is available from a web browser at uas.url /uas/trace .

For more information, please refer to page SAML protocol tracing, chapter Enable tracing on UAS.

Disable Info Page

To assist system support, an information page can be enabled that shows the current users active sessions, locale, template and other system statistics. This page must be disabled for production environments.

If this has been enabled, examine the page contents and determine if it should be disabled for your environment. The service is available from a web browser at uas.url /uas/info

For more information, please refer to page SSO Session Information Page, chapter Enable session information page on UAS.

OAuth2 - Enable explicitly only required grant types

Review all OAuth2 agents. Any unused OAuth2 grant types should be disabled for each agent. The example below allows only SAML2 bearer and authorization_code grant types. This setting is made in the Agent Metadata value of the agent.

Enable only required grant types in OAuth2 metadata

{"return_uris":["https://app.example.com/return/oauth"],"grant_types":["urn:ietf:params:oauth:grant-type:saml2-bearer","authorization_code"]}

OAuth2 - Review return URIs

When moving an agent to production, review return_uris value in the OAuth2 metadata and allow only secure addresses.

Check return_uris value for only secure, trusted parties

{"return_uris":["https://app.example.com/return/oauth"],"grant_types":["urn:ietf:params:oauth:grant-type:saml2-bearer","authorization_code"]}

Session Timeout Review

Review timeout values to ensure unnecessarily long session lengths are avoided. See Timeout Configuration Guide.

Server SSL Certificate Settings

Use a tool such as https://globalsign.ssllabs.com/ to review server SSL Certificate configuration and adjust to meet project security requirements. Note changes must be made to the network device where SSL certificate is served from which is before the Ubisecure services.

Schedule regular reviews of TLS settings as recommendations change from time to time.

Record the expiry date of any SSL server certificate in a maintenance calendar and ensure a process is in place to renew the certificate in good time before expiry.

EV certificates are highly recommended to improve end-user trust and detection of domain spoofing.

Secure Storage of Backups

Ensure backup data is stored securely. Encrypted storage is recommended.

Security Audit

A standard security audit should be performed on production environments.

Browser not supported