Skip to main content

About authentication

Test Services validates who you are before it lets you view or run tests, but it does not keep its own user accounts. It delegates that decision to OpenLab Shared Services, the same service that manages identity for OpenLab CDS. This explains why you log in with your OpenLab CDS credentials and why some deployments ask for a domain. It also explains why the very first login after installation needs an administrator. For the login procedure itself, see Log in to Test Services.

Identity comes from OpenLab Shared Services​

When you log in, Test Services passes your credentials to OpenLab Shared Services and asks whether they are valid. It never stores passwords of its own. This is why your OpenLab CDS user name and password work in Test Services unchanged, and why account rules set in OpenLab CDS apply here too. If your account is disabled or temporarily locked, OpenLab Shared Services refuses the login and Test Services reports the reason.

Because identity is shared, the audit picture is shared as well: OpenLab Shared Services records login events, including failed attempts, in the OpenLab CDS activity log.

The authentication providers​

How you log in depends on the authentication provider configured for OpenLab CDS, not on Test Services. There are three:

  • Internal authentication. You supply a user name and password that OpenLab Shared Services manages directly.
  • Windows domain authentication. You supply a user name, a password, and a domain. The login page offers the domains registered with OpenLab Shared Services.
  • No authentication. Available only on a file-based Workstation configured without security. No login page appears and you are admitted automatically. Because there is no identity to check, the Security Test is not available in this configuration. The Storage System Test, which does not depend on authentication, remains available.

Test Services adapts its login page to the configured provider: it shows the domain field only when domain authentication is in use, and it skips the login page entirely when no authentication is configured.

Logging in is not the same as being able to run tests​

Validating your credentials only proves who you are. To use Test Services you also need the right to do so, which is granted through roles in OpenLab Shared Services. At login, Test Services confirms both that your credentials are valid and that you hold the Test Services user role; without that role, a valid login is still refused. What each role can do is described in Roles and privileges.

This separation also matters for individual tests. A test may need OpenLab privileges beyond the basic Test Services role, and scheduled tests run under the credentials of the user who created them. For the credentials that scheduled and on-demand runs use, see Set run credentials.

The first login after installation​

The Test Services roles are created in OpenLab Shared Services the first time an administrator signs in after installation, not during installation itself. Until that first administrator login completes, other users cannot log in, because the roles they need do not yet exist. After it completes, normal users log in with the Test Services user role.

The same first-administrator login is also what repairs the deployment after the authentication provider is changed. Switching the provider, for example from internal to domain, can leave scheduled tasks, test parameters, and shared settings unable to run; when an administrator signs in afterwards, Test Services restores them. To set up roles, see Configure roles and privileges.

Important

After an administrator changes the OpenLab CDS authentication provider, have an administrator log in to Test Services to restore scheduled tasks, test parameters, and shared settings before relying on them again.

See also​