CLASS Multifactor Authentication

CLASS Multifactor Authentication replaces the outdated standard of putting the CLASS website behind an IP whitelist.

This is replaced by utilising Microsoft Authentication (aka Azure Active Directory, or AAD) in order to grant access, which has resulted in these changes to how CLASS works:

 

Users will now need a Microsoft account to sign in

  • Azure Active Directory users are now a requirement for every CLASS user, and each Centre needs to link their database to a specific Azure tenant.

 

Centres get the security benefits offered by the Azure Active Directory platform

  • This includes the option to implement a number of multifactor authentication methods, including SMS, voice call, the Microsoft Authenticator app, and many other custom secure token platforms.

 

You no longer need to be in the office or using a VPN to access the CLASS website

  • By default users will not be restricted access to CLASS by IP address.
  • Centres can choose to restrict some users, such as volunteers, so they can only work from the office – you will need to provide us a list of IP addresses for your Centre to do this.
  • The CLASS VPN will no longer be available. Existing VPN accounts will work until they expire for the purpose of keeping your access to LexisNexis Advance. We recommend you contact our friendly Operations team to request login accounts to LexisNexis for you to remove the need for VPN altogether!

 

No more outdated security barriers

  • Users will no longer receive an email from CLASS when their account is created.
  • Password reset functionality has been removed as you are using your Microsoft account. Users can reset their passwords through the normal Microsoft reset process as required.
  • Security questions are no longer needed in CLASS.
  • Aside from the occasional security challenge from Microsoft, signing in should be as simple as clicking a button!


Release date:
 4 December 2021.

If you have any feedback or questions about any of this release, please email the CLASS helpdesk. We are committed to a process of continuous improvement and providing features that meet the needs of Centres, their staff and volunteers.

 

FAQs and Technical Release Notes

There is more detailed information about user management under the “User Management and Access” header below.

  1. Sign into your primary Microsoft account in the browser (through office.com or similar)
  2. Go to portal.azure.com
  3. In the top right hand corner click on your username and select “Sign in with a different account”
  4. Follow the prompts to sign into that account
  5. Now when you click the ‘Single Sign On’ button you will be prompted with a popup like the one below which will let you select which Microsoft account you want to sign in with.


You can download the Microsoft Authenticator here.

If you have questions about MFA methods, you should speak to your IT.

Login Screen

Users will be presented with a new login screen.

  • The Username and Password fields will be removed.
  • The “Sign in” button will be replaced with a “Single Sign On” button and will appear underneath the CLASS logo, instead to the right of it. This will redirect users to a Microsoft Authentication page.
  • The “Can’t access your account?” link used for password resets will be removed.
  • A guide to this screen for non technical users can be found here.

User Account Management

  • The “Reset Password” link that previously appeared next to “Change Username” has been removed from user accounts.
  • A new checkbox is available for active users called “Supervised User”. Refer to the Supervised Users section of the IP Management part of this page for more info.
  • The AD Object ID field that was visible to users during the initial onboarding phase has been removed and is no longer used as part of validating a user login from Azure.
  • The Terminate Account feature remains in CLASS and can be used to remove access to CLASS without removing access to Azure Active Directory or Microsoft in general.


Security Questions

CLASS would previously ask users to provide the answers to two security questions upon first login. This is an extremely outdated form of security and has been switched off.


Linking CLASS and Azure Accounts

Synchronisation

  • Changes made to user accounts in Azure Active Directory are not synced to CLASS.
  • Changes made in CLASS are not synced to Azure Active Directory.
  • Users who can sign into Azure Active Directory therefore do not inherently have access to CLASS.
  • Users who can sign into CLASS using Azure Active Directory do not inherently have access to all features of the Microsoft Cloud platform.


What do you need to sign into CLASS then?

The only way an Azure Active Directory account can be used to authenticate into CLASS requires a CLASS Administrator at your Centre to:

  1. Make sure there is a user account in CLASS.
  2. Make sure the user account has a username matching the User Principal Name in Azure Active Directory.
  3. Make sure that user account is active in CLASS.
  4. Make sure that user is able to sign into their Azure Active Directory account successfully (and be connected to a valid IP address if they are a Supervised User).


Conversely, if the Centre CLASS Administrator has created a CLASS account, the user cannot access CLASS unless:

  1. The Azure Active Directory Administrator has created an account for them there first.
  2. The account is in the correct Tenant.

The Azure Active Directory section provides more information on types of AAD accounts that can be used under which circumstances.


Locking yourself out of CLASS

Security features intended to lock out users under different undesirable scenarios still exist.

  • Users will still be locked out of CLASS after 10 unsuccessful login attempts.
  • Users will still be locked out of CLASS if they attempt to sign in after 3 or more months of inactivity.

It will remain the responsibility of the Centre CLASS Administrator to unlock these users, and the same principles referred to in our user management guide apply.

Flow Diagram


CLASS authenticates with Azure Active Directory, implementing OAuth 2.0 Authorisation Code Flow principles


Alternatives to Azure Active Directory

At this stage Azure Active Directory is the only supported authentication method into CLASS.

Some other identity platforms such as Google may allow you to perform a sync from their directory to your Azure Active Directory with an integration and you should work with your IT professional to work through this.


Multifactor Authentication

Azure Active Directory supports a number of different additional security factors, and you can even implement your own temporal one time token generator.

We do not advocate for one method above another, but we strongly recommend all users who have access to sensitive information or who have email accounts are secured with at least one additional authentication factor.


Tenant and User Setup

Azure Tenants

  • Each CLASS Centre Database can be configured to receive user information from only one Azure Active Directory tenant
  • The same Azure Active Directory tenant can be used across multiple CLASS Centre Databases – for example, if you are one organisation with multiple databases in CLASS.
  • Each Azure tenant to be used with CLASS must grant consent to the CLASS AAD Enterprise Application – this grants the CLASS application to request an access token for a specific user after a login attempt is made, alongside their user principal name and IP address.
  • An Organisation with an Azure account can create multiple tenancies, although additional tenancies will usually just be on the free tier without purchasing additional licensing.
  • Tenancies on the free tier who implement MFA will be restricted to the Azure Authenticator App.


Azure User Types

Azure has two main types of users:

  • Member Users – these are users created inside the tenant and the tenant has full control over access policies. They may or may not have licenses to full Azure Active Directory features or other Microsoft Cloud Platform products that have been purchased by the Centre.
  • Guest Users – these are users who exist in another tenant and have been invited by your organisation to have access to some level of B2B collaboration.

Whether a user is a member or guest, and if a member user is unlicensed or not can have a few impacts on CLASS access.


Member Users

A member user who is under an appropriate Azure Active Directory License:

  • Will usually be the primary way a user accesses Azure Active Directory and therefore will probably have the easiest time accessing CLASS.
  • Is eligible to require multifactor to be setup to access CLASS regardless of the security policy the Centre adopts.

A member user who is not under an appropriate Azure Active Directory License:

  • Will usually be either a volunteer or a secondary login for someone who needs to access multiple CLASS databases.
  • Is only eligible to require multifactor to be setup to access CLASS if your tenant uses the security defaults.


Guest Users

A guest user:

  • May come from another Azure tenant, or possibly from a consumer identity source – such as a personal Outlook account.
  • Will authenticate using the UPN from their source tenant, and should therefore be created in CLASS with the source tenant UPN as its username.
  • May be used to grant external organisations temporary access to CLASS for collaboration (such as cross checks).
  • May also be used as a way to allow a user to sign into an alternative tenant using an account they are familiar with – for example, if you create a secondary tenant to setup CLASS as you do not wish to support our Enterprise Application in your main tenant, you could invite your users as guest users into that tenant in order to allow them to log into that tenant with familiar credentials.


Note that usernames must be unique across all of CLASS so if someone is already accessing another CLASS database using their email, you will get an error if you try and create a CLASS account with the same email after inviting them as a guest user.

IP Whitelist

  • The existing Azure Network Security Group (NSG) will open up all traffic over https port 443.
  • IP lists will be managed in the CLASS Admin Portal by the Helpdesk – each Centre has their own dedicated list and IP addresses, where previously all allowed IP addresses were applied to all https traffic for any user.
  • IPv4 addresses can be supplied using any combination of CIDR single addresses or ranges.
  • IPv6 is still not supported.
  • IP restriction will be applied to each user individually as set by the Centre’s CLASS Administrator, and is not checked until after Azure Authentication has been passed by the user. This concept is called “Supervised Users”


Supervised Users

  • Supervised users will be unable to access CLASS unless connected to an IP address provided by the Centre to the Helpdesk.
  • If the Centre has flagged users as Supervised, they will not be locked out if no IP addresses have been supplied by the Centre to Helpdesk.
  • Supervised users are flagged with a checkbox inside the user account in CLASS by the Centre’s CLASS Administrator (refer to the User Management section of the release notes for screenshots).
  • Supervised users who pass Azure Authentication but are not connected to an IP address in the supplied list will receive the below error message:


Supervised users receive this message when connecting from an invalid IP address.


VPN

  • The CLASS VPN will continue to operate to assist in servicing LexisNexis Advance access until we deem it is no longer required.
  • The CLASS VPN will no longer be available for use in any Centre’s IP whitelist. We do not see this as a secure method of remote access, instead as a potential vulnerability that is no longer required.
  • VPN User Management features previously available in CLASS to Helpdesk staff will be removed.
  • New CLASS VPN Users will not be provisioned after 3 December 2021.
  • Existing VPN accounts will be active until they reach their expiry date.
  • There will be a generic VPN user account available in extenuating circumstances if LexisNexis Advance access is required but LexisNexis does not provide a user account to access the product in a timely manner.
Search