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

Password hashing algorithms

For security reasons, Ubisecure Identity Server stores passwords in hashed format by default. For more information, please refer to Password hashing algorithms.

System Administrator login and password

There is a default Administrator account that is created with every installation. It is important to perform a few tasks to secure the newly installed service. Among those are:

• Create a new Administrator account for active use.
  • It is good practice to create an individual new Administrator account, with MFA, for each Administrator on your system. 
• Consider renaming the default System account name and reserve it for emergency reconnection to your service if all other administrator accounts are unavailable.
  

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 also recommended 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 Navigation
• Select the Users tool
• Click the user named Administrator
  
• Change system value in Username field and press Update
• Click Password and enter a new password
• Save the password by selecting OK
  

• Record the safety Administrator username and password in a secure manner

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.

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 command to restart the OpenLDAP server:

systemctl restart ubilogin-directory

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 is recommended to 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.

Using a Reverse Proxy

For security and performance purposes, it is recommended to use a Reverse proxy in front of Ubisecure applications. A key benefit when using a reverse proxy is to hide the characteristics of the underlying system, control the exposure of HTTP endpoints and segregate public and internal networks. This also gives the ability to mask error codes and web pages exposed by the applications from being exposed externally. To aid in internal trouble shooting, the error codes of a misconfigured application will remain to be visible. It should be noted that application hardening is never perfect therefore the use of a Reverse proxy is strongly recommended.

• To mention a few OSS options (not in particular order):
  
  • NGINX: https://www.nginx.com/
  • HAProxy: http://www.haproxy.org/
    
  • Træfik: https://containo.us/traefik/

Customizing error pages with HAProxy 

The following example illustrates a simplified configuration to customize error pages with HAProxy. Internal errors are mapped to HTTP 404 (Not Found) in order to avoid leaking any application specific stacktraces. Note that this approach also gives the possibility to use your organization's common error page as the default return.

frontend https-in
    bind *:443 ssl no-sslv3 crt /etc/pki/tls/certs/cert.pem
...
    errorfile 500 /etc/haproxy/404.http # Internal Server Error
    errorfile 502 /etc/haproxy/404.http # Bad Gateway
    errorfile 503 /etc/haproxy/404.http # Service Unavailable
    errorfile 504 /etc/haproxy/404.http # Gateway Timeout

HTTP/1.0 404 Not Found
Cache-Control: no-cache
Connection: close
Content-Type: text/html

<html>
  <head>
    <title>404 Not Found</title>
  </head>
  <body>
    <div>
      <h2>404 Not Found</h2>
    </div>
  </body>
</html>

To test the configuration, you can execute following command in your terminal to verify that proxy reroutes IANA HTTP status codes correctly

curl -kI https://manage.example.com/ubilogin

A correctly configured errorfile should result into something like:

HTTP/1.0 404 Not Found
Cache-Control: no-cache
Connection: close
Content-Type: text/html

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 - SSO configuration guide.

Hide information about user account status in Password Application

Information related to account status, such as if it's invalid, can be hidden in password reset by setting configuration string parameter policy.dontRevealAccountStatus=true, to the authentication method's configuration string.

Note: A restart of SSO is required for the configuration to take affect.

Custom error message in SSO user interface

Refer to the Message Hardening section in the Login user interface 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. Alternatively, it is recommended to deploy a Reverse Proxy in front of Ubisecure applications as described in this page.

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 - SSO, 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 Session information page - SSO, chapter Enable session information page on UAS.

OAuth2 - Enable explicitly only required grant types

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

{"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 application to production, review return_uris value in the OAuth2 metadata and allow only secure addresses.

{"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.

RefreshServlet security

RefreshServlet (uas/refresh) provides two functions:

• Refresh user's SSO session from user agent (web browser).
• Reveal to the web client whether or not user has a session.

By default the RefreshServlet is enabled and allowed to be called with CORS requests from any origin. For the RefreshServlet to function, it's required that the user agent sends SSO session cookie to uas/refresh endpoint with each request, which is why it needs to have CORS with credentials enabled. Therefore the CorsFilter for RefreshServlet is configured so that Access-Control-Allow-Credentials response header is true and the Access-Control-Allow-Origin response header reflects the value of the Origin request header for all requests, whatever the value of the Origin request header is. If required there are two options to harden the security of RefreshServlet.

1. If the functions provided by RefreshServlet are desirable, but you want to restrict its use with CORS requests so that it's either possible to call only from certain known origins, or not possible at all. To do this, follow the instructions in page Configuring CORS with credentials.
   
   
2. If the functions provided by RefreshServlet are not desirable, then disabling it completely is recommended in order to prevent its misuse. To do this, follow the instructions below.

Disabling RefreshServlet

To disable the RefreshServlet, remove or comment out the following lines in ubilogin/webapps/uas/WEB-INF/web.xml:

<servlet>
    <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.RefreshServlet</servlet-name>
    <servlet-class>com.ubisecure.ubilogin.sso.ui.servlet.RefreshServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.RefreshServlet</servlet-name>
    <url-pattern>/refresh/*</url-pattern>
</servlet-mapping>

After updating web.xml, run the update command as follows:

• On Linux: /usr/local/ubisecure/ubilogin-sso/ubilogin/config/tomcat/update.sh.
• On Windows: %PROGRAMFILES%\Ubisecure\ubilogin-sso\ubilogin\config\tomcat\update.cmd.