Single Sign On

13.12. Single Sign On

Overall description #

The Single Sign On functionality in SICS consists of these components:

A startup parameter which will instruct SICS to run in Single Sign On mode.
A ’technical user’ which is used to establish a connection with the database. This user will be provided through the existing facilities, see details below.
A ‘real user’ which is used to establish access rights (authorization to do things in SICS). In Single Sign On mode, the real user will be identical to, and will be retrieved from, the Windows login.
In Single Sign On mode, since the real user is already authenticated in Windows, there will be no prompting from SICS for user name (ID) and password. However, there may still be prompting for database and environment name, if these are not provided by other means, see details below.

Startup parameter #

The SICS startup parameter for Single Sign On mode is set in a manner similar to other login-related parameters (see below).

For the ‘sics.inifile.properties’ file settings, the parameter is named SINGLESIGNON and the valid parameter values are N and Y, meaning ‘No’ and ‘Yes’. If the parameter is not present, or it is present but does not have a valid value, it defaults to ‘No’.

For the SICS command line arguments the parameter is named ‘-ds’ (no further input needed). The presence of this parameter means Single Sign On mode is to be used.

It is possible to provide a user name (ID) and password, as well as database name and the environment, as ‘parameters’ when starting SICS. This is where the ’technical user’ must be provided. Please refer to the separate Word document “SICS Installation Guide.pdf”, section:

9.1.2Ini File Settings (in the ‘sics.inifile.properties’ file)
10.1.2SICS Application Command Line Arguments (overrides ‘sics.inifile.properties’ file settings)

Technical user #

The technical user must be provided through the login-related parameters, see above. The technical user will be used for establishing the initial connection to the database. Whether this connection is kept or replaced by a second connection, depends on how the ‘real user’ is set up - see below.

Password encryption #

The password for the technical user may be encrypted.

In the SICS installation folder, there is a file named ’encrypt.bat’. This bat file takes a plain-text string (the password) as input, calls a SICS utility program and outputs an encrypted version of the string. This encrypted value will always be prefixed with ‘%’ so as to later recognize it as an encrypted value. The encrypted password can be provided in the password field for the technical user, see above.

Examples of providing the technical user #

Example of ‘sics.inifile.properties’ file settings

SINGLESIGNON=Y
USER=TECHUSER
PASSWORD=%51DBEA0344D3031D12FB15B49069A199
DATABASE=DBPROD
ENVIRONMENT=SICS4PC

Example of command line arguments

-ds -duTECHUSER -dp%51DBEA0344D3031D12FB15B49069A199 -dnDBPROD -deSICS4PC

Real user #

The user ID from the Windows login will be used as ‘real user’. SICS will not perform any authentication of this user ID. The real user will be used for several purposes, as follows.

The real user will be used to read a SICS User Object from the SICS database (table CNU_USER). This means that the person using SICS must be defined as a SICS user with the same name/ID as the Windows login ID.

The real user / SICS User Object could be set up to use one-level or two-level login; it will not affect the Single Sign On functionality.

Via the SICS User Object (or via the User Authorization Interface, see chapter User Authorization Interface) the real user will determine the authorization for SICS functions, i.e. which use cases and domain restrictions that apply for the end-user.

The real user will also be used for logging purposes in SICS.

SICS’ SSO Integration with AWS AppStream 2.0 #

The user opens the AppStream stack URL (Redirect URL) in a web browser.
AppStream redirects the user to an Identity Provider (IdP) such as AWS Cognito, Okta, Keycloak etc. Authentication is performed using SAML 2.0, or OIDC (OpenID Connect).
On successful authentication A SAML Assertion or ID Token (JWT) is returned, it includes user identity and attributes, such as Username and Email address.
AppStream validates the SAML assertion or OIDC token, and a streaming instance is selected and a new AppStream session is created.
Inside the streaming instance, applications run under the default OS account i.e., PhotonUser.
- The authenticated SSO user does not become a Windows login user.
- PhotonUser is an internal system account used only to launch applications.
AppStream injects session variables to pass user identity details to applications.
- Example:
```
AppStream_UserName = user.name@abc.com
```
SSO enabled SICS application reads AppStream_UserName variable to identify which user started the session and treat that identity as the Real user.
Note:
- Command-line arguments such as: -ds -du -dp -dn -de should be configured as described above.

SICS’ SSO Integration with AWS Workspaces #

User launches the WorkSpaces client or web access.
Authentication happens via SAML, OIDC or AD. User provides credentials which are validated by IdP / AD.
The WorkSpace instance performs a Windows login using the actual user.
A normal Windows session is created by loading user profile.
SSO enabled SICS application identify which user started the session from windows logged in user details and treat that identity as the Real user.
Note:
- Command-line arguments such as: -ds -du -dp -dn -de should be configured as described above.

Security Considerations #

Encryption of the technical user password is recommended, see above.

With one-level login, the initial database connection made using the technical user will be kept. In this case, the technical user needs to be defined in the RDBMS with SELECT/INSERT/UPDATE/DELETE rights on all SICS tables.

With two-level login, the technical user will be disconnected and the 2nd level ID (from the SICS User Object / CNU_USER table row corresponding to the end-user) will be used for connecting again to the database. Note that the password of this 2^ndlevel database user is also encrypted (implicitly via the User maintenance GUI).

With two-level login, the initial user (technical user) only needs SELECT rights on two SICS tables, CNU_ENVIRONMENT and CNU_USER. The 2^ndlevel database user needs SELECT/INSERT/UPDATE/DELETE rights on all SICS tables.

When Single Sign On is not activated, using two-level login increases the security against unauthorized modification of the SICS database with 3rd party tools.

In the Single Sign On scenario, the use of two-level login is not essential if one assumes that the technical user password is encrypted.

Limitations #

Single Sign On mode applies only to the SICS Workstation and System Administration desktops. It does not apply to SICS API Server.

Single Sign On mode cannot be activated / will be ignored, when using database remote OS authentication.