Security

WingArc Australia does not generally carry out formal third-party security audits or penetration testing of the SuperSTAR suite. The infrastructure and configuration of each deployment plays a significant role in the overall security of the solution, so any testing that might be carried out on the SuperSTAR suite in isolation would not provide complete assurance of the security of a real-world deployment. Customers should arrange their own third-party audit of the full solution that they have implemented, including SuperSTAR. If you require assistance or advice with security matters, please contact support.

Should your audit identify any security issues, please bring these to our attention via our support channels. We address any issues exposed by these audits with a high priority.

Following is some information about security measures within SuperSTAR that may assist with your audit:

Credential Security

Passwords are hashed with PBKDF2, using 240 bit keys, 64,000 iterations and SHA-256 HMAC, and independently salted. 

SSL/TLS Encryption

It is the customer's responsibility to ensure that the server is correctly configured so that only HTTPS protocols are used for access to the SuperWEB2 client by end users. Options for configuring SuperWEB2 to use HTTPS include:

• Use a reverse proxy, such as NGINX. See Configure Reverse Proxy and Audit Logging for more details.

• Configure SSL in the Tomcat settings. See https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html for more details.

System Configuration

It is important to ensure that OS permissions and infrastructure configuration have been set up so that no unauthorised users can gain access to the datasets or configuration files and to follow the principle of least privilege with any other accounts (such as accounts for accessing the relational database where SuperADMIN and SuperWEB2 information is stored). Customers may also choose to apply encryption at the OS or hardware level.

Communication Between Components: JSON Web Tokens (JWTs)

From version 9.18 onwards, communication between the components of the suite are authorised using signed JSON Web Tokens (JWTs) to ensure that information passed between components can be verified and trusted. 

SuperWEB2 and the SuperADMIN Console

SuperWEB2 and SuperADMIN use narrowly-scoped access tokens intended for specific subsets of tasks (such as tabulation, viewing the catalogue, etc.) and refresh tokens that are used to generate access tokens.

When a client authenticates with the server, it initially provides them with a catalogue access token and a refresh token. These are linked to an internal “refresh family”, which acts as a session. Whenever another access token is required, the refresh token needs to be provided as authorisation and, if successful, the requested token and a replacement refresh token are provided in the response. Only the most recent refresh token will be accepted. If a previous refresh token is given to SuperADMIN, it will assume an attacker is trying to use an old token, or that they have already, and the user is now using an old token. Either way, the session has been compromised, so the refresh family is revoked, and no tokens generated from it will work.

Tabulation tokens are generated for every tabulation, and by default expire after 15 minutes. These tokens are checked by SuperSERVER almost immediately after creation, so the lifespan can be quite low, as it only needs to account for any load spikes that may delay processing of the request.

Since refresh tokens have their own token expiry, they may need to be refreshed before another access token is required. This is done by checking the refresh token expiry on every user action and, if it gets too close, a request for an access token will be sent specifically to refresh the refresh token. If the refresh token expiry has already been reached because the user did not perform an action for an extended period of time, their session will effectively be ended because an expired refresh token is no longer valid, and it is the only way to generate a new one without logging in again. This can be thought of as a session timeout.

Refresh families also have an overall expiry when refreshing the refresh token will no longer be allowed. This can be thought of as the max session time.

You can use the tokenKeys command and the refreshFamilies command in the SuperADMIN console to manually revoke JWT keys and refresh families, for example if you believe that a specific token or refresh family has been compromised.

Job Queue Manager (JQM)

When a job is submitted to JQM, a long lived “queued job” token is generated and stored with the job entry. This token contains a cryptographic hash of the table and the dataset ID. This token will then be used to authorise the tabulation of that table at the time it is processed, allowing the specific user permissions to be reapplied to the table. It will be rejected if the user account has been deleted or if they no longer have access to the dataset.

The table hash and dataset ID are checked by JQM when it picks up the job and it will not submit it to SuperSERVER if they do not match. SuperSERVER will also check these once the job is submitted and will refuse to tabulate the job if they do not match.

By default, the queued job token is valid for 7 days. If the job is still in the JQM queue after this time it will not be able to be processed, although the user who queued the job will be able to log in and re-queue it.

Open Data API

The Open Data API works in a similar way to SuperWEB2, but with an API token that authorises the creation of the initial token pair and refresh family. The API token itself is unchanged from previous versions.

Because Open Data API sessions are intended to only last for a single request, a separate refresh family lifetime is used that is much shorter than the one used normally. This should only be long enough to perform any single operation via the API (it will normally be defined by the table that takes the longest to tabulate, which will depend on the dataset size, structure, and configuration).

SuperCROSS and Production System

These clients use a different model, based around a single long-lived access token, referred to as internal access tokens (as opposed to external access tokens used by clients such as SuperWEB2 and the SuperADMIN console).

Internal access tokens are generated with all the required scopes up-front and need to last long enough to accommodate all normal use cases as, once they expire, the user will need to restart the application. There is no associated refresh family tracked by SuperADMIN for these.

By default, internal access tokens are valid for 30 days, but you can change this duration if necessary. See below for details.

Changing JWT-Related Default Settings

In most cases, the out of the box settings for JWT should be sufficient and it should not be necessary to make any adjustments. Please see below for more details should you wish to change any default settings.

jwt {
    clockSkew: 5 seconds
    keyServer {
      keyPollInterval: 5 minutes
      clientTimeout: 10 minutes
    }
  }

str.superadmin {
  jwt {
	lifespan {
		internal: 30 days
	  }
	}
}