Logging in to a Laboratory

Overview

CCLAS is a web-based application that provides you with an interface for launching applications, programs and reports.

Once you have logged in, the Home page displays. From here you can access any authorised application in the system.

Personalisation of the Home page is available to suit you or your organisation. Refer to Using the Home Page for more information.

This section covers logging in for an CCLAS session, logging out, and changing login credentials.

Process

Logging in to a Session of CCLAS

A user can only log into a laboratory where the user has at least one non-suspended role for the laboratory. When they are logged into the laboratory, the user can access only those system features where the rights are granted according to the non-suspended roles for the logged-in laboratory. The system rights that are granted are a summation of all non-suspended roles for the laboratory.

To log into CCLAS, you need a user account and password.

When you log in, you are prompted for:

  • User code (which is not laboratory specific)
  • Password
  • Laboratory (combo, with the default laboratory pre-filled in). Only laboratories that have the Is Available for Login check boxes checked are available for selection. For the CCLAS session, the selected laboratory scopes the entities that are visible to the user, by the related organisation and the laboratory itself.

When a user attempts to log into a laboratory, then user's User Principal Name, for the CCLAS 6 user whose Code matches the entered Username, and the entered Password are passed to the Azure Active Directory (AAD) authenticator, such that, where the user is not configured in AAD, then they are denied login to CCLAS 6.

Any error condition raised by AAD returns an error message to the user.

The ENABLE_USER_LOGIN_SCOPE_FILTER application preference controls whether the available laboratories are filtered based on a user's role upon login.

Log in to CCLAS

Logging Out of the Current Session of CCLAS

Note: Logout is available on all screens. Selecting X in the top, right corner of the browser screen does not log you out of the instance. It is recommended you do not use this button to exit CCLAS.

Log out of CCLAS

Changing Login Credentials

A user can only log into a laboratory where the user has at least one non-suspended role for the laboratory. When they are logged into the laboratory, the user can access only those system features where the rights are granted according to the non-suspended roles for the logged-in laboratory. The system rights that are granted are a summation of all non-suspended roles for the laboratory.

Note: A user can only change login credentials where the system is configured to permit users to change their login credentials.

Change Login Credentials

Session Timeout

The ria.session.timeout system user preference, (Refer to Configuring CCLAS Post-installation to change the online session timeout) defines the number of minutes after which an inactive interactive session remains connected to CCLAS.

Preference Settings and Access Rights given to a User for a CCLAS Session

The level of access you have is dependent on your level of responsibility. As an example, a Laboratory Manager has the ability to validate data entry values, whilst a Laboratory Operator does not have that function.

Each user has a list of security permissions, each of which comprise a role and laboratory. A user can have multiple roles per laboratory. A security permission can comprise a role for all laboratories.

A role is a collection of rights to applications, methods and attributes. This is set up by the system administrator.

When you log in, your cached permission data is cleared, thereby forcing a load of the latest permissions for you. Where you are already logged in when security permissions are changed, then you log out and re-log in to be given the latest permissions. This must be repeated for every currently logged in session, that is, you may be logged into multiple laboratories.

In a multiple server environment, the permissions are checked when a service is requested, so if you do not log out and back in again, you might get an unpredicable permission or rejection from the services, that you did not get when you first logged in, as the permissions are not assessed/cached per server. Logging in ensures that, in that current session, there is no perceived change of permissions.

Each role applicable to you for the login laboratory is overlaid to set your initial security permission such that, you obtain the highest (most power) access rights and permissions from all roles that you have for the laboratory:

  • If any role gives full access to an application, then full access is granted to that application.
  • If any role gives read-write access to a class attribute, then read-write access is granted to that attribute.
  • If any role gives full access to a class method, then full access is granted to that method.
  • Some methods allow for split-level operational security:
    • If an object is an org-scope object then only a user with a security level of 'Org Only' or 'Lab and Org' or 'Full' can execute that method. If an object is a lab-scope object then only a security level of 'Lab Only', 'Lab and Org' or 'Full' can execute that method.
    • As access levels are hierarchy based, if the user has roles with both 'Lab Only' and 'Org Only', then the user account acts like they have access level 'Lab and Org'.
    • If any role gives access level 'Lab and Org' to a method, then effectively, an access level of 'Full' is granted to that method. The PREFERENCE and SCRIPT class methods are an exception to this rule as they have multiple levels that are different to Lab and Org.
    • The following objects have methods (for example, Create, SaveAs, Update, Read, Search, Delete) which are implemented with split-level operational security:
      • Biofields
      • Canned Comments and Canned Comment Groups
      • Category Types and Categories
      • Clients, Client Addresses, Contacts, Contact Addresses, Projects, Client Quotes
      • Container Types
      • Cost Centres
      • Devices
      • Hazards
      • Instrument Groups
      • Methods and Method Accreditations
      • Products, Product Hazards, Product Specifications
      • Product Specification Groups
      • QC Masks
      • QC Types
      • Range Tables
      • Rounding Tables
      • Sample Handlings
      • Schemes, Scheme Version and Scheme Version Analytes
      • Scheme Groups
      • Specifications
      • Standards, Standard Lots and Specifications
      • Units

    The following objects and methods (specific methods) are implemented with split-level operational security:

    • Biofield: Approve, Unapprove and ImportBiofields
    • PriceBook: UpdatePrices
    • Product: Activate, Approve, Unapprove, Promote, Suspend, ImportPRoducts
    • Scheme: Approve, Unapprove, ImportSchemes
    • Specification: Activate, Suspend, Promote
    • SpecificationSchemeVersionAnalyte: CreateFromAnalyte
    • Standard: Activate, Deactivate, Promote, Suspend, Approve, Unapprove