Single Sign-on

Note: SSO is a company add-on and is subject to payment.

The Single Sign-on (SSO) functionality enables clients to use their own authentication infrastructure when logging on to the Authoring environment, Reportal (designers and report viewers) and limited surveys. If a respondent has already logged on to the system, they will be able to access the survey without the requirement for additional in-logging.

Note: If someone is using SSO to access Reportal, the end user list that is referenced for access MUST have been created by a Professional user who is a member of the same company.

For a client to be able to use SSO, the client must provide Forsta with a 256-bit AES key for establishment of the trust, and this should be done over a secure file transfer channel. This key will be used when decrypting the tokens that are presented by the users during log-in. The SSO company add-on must also be enabled for the client.

Authentication:

1. SSO authentication is performed by sending a clear-text company identifier (“co”) and an encrypted token (“key”) via HTTP(S) POST or GET to a Single Sign-on enabled log-in page in Forsta Plus.

• The “co” parameter should contain the client company id.
• The “key” query parameter should have a value equal to the base 64 encoding of the encrypted value of the string composed of semi-colon delimited key value pairs for id, timestamp, and in some cases destination URL:
• id – Forsta Plus user id
• ts - UTC timestamp of the form “2007-01-10 23:39:39”
• url - Destination URL

Sample decrypted “key” value: id=abc123;ts=2007-01-10 23:39:39

1. The value for the “key” parameter must be encrypted by the client using the same 256-bit AES key that was sent to Forsta Plus previously when enabling SSO. ECB blocking and PKCS5 padding must be utilized.
2. Forsta Plus will attempt to decrypt the “key” parameter using the key associated with the client identified by the “co” parameter. If this fails, the authentication request will be rejected. Otherwise authentication will be successful as long as the timestamp parameter is not older than a predefined (but configurable) number of seconds. This leeway is used to address lack of systematic clock synchronization across client and Forsta Plus systems. Every effort should be made to reference a common time source and narrow the timestamp timeout period. After a successful authentication, authorization is performed using the decrypted “id” value.