Testing LMS Single Sign-On for Saudi Employees

Imagine the first Sunday after a Saudi company switches its LMS software to single sign-on. A new accountant in Riyadh opens his email without trouble, but the LMS software tells him his account does not exist. A sales manager who resigned on Thursday still receives course reminders on his phone. And a site supervisor in Jubail, who replaced his phone over the weekend, cannot get past the verification step, so his mandatory safety refresher goes overdue.

Single sign-on was meant to make training access simpler, and for most employees it does. The problems sit at the edges of the employee journey: the first day, the last day, and the day something goes wrong. They rarely show up in a demonstration, where every account already exists and every phone works.

This article is for HR, IT, and procurement teams in Saudi organizations connecting LMS software to their corporate sign-in. It covers three journeys to test with IT before go-live: the joiner, the leaver, and access recovery, and shows how to run them as a short pilot rather than discovering the gaps on launch day.

What Single Sign-On Changes for LMS Software

NIST defines single sign-on as an authentication process by which one account and its authenticators are used to access multiple applications in a seamless manner, generally implemented with a federation protocol. In practice, the employee signs in once with the organization’s identity provider, using the same account as for email and other internal systems, and the LMS software trusts that sign-in instead of keeping its own passwords.

Saudi organizations also have a national reference point. Standard 5.6 of the National eLearning Center’s eLearning standards, on security, privacy and identity management, calls for a secure single sign-on where multiple systems are used, coupled with centralized identity and access management, and for identity verification appropriate to the risk level, including multi-factor authentication or its equivalent. Whether or not your organization is within the standards’ scope, those requirements describe what a sound setup should deliver.

One point is easy to miss. NIST’s federation guidelines (SP 800-63C) list centralized account management among the benefits of federation, but they also state that the account at the application, here the learning management system, has a separate life cycle from the account it is based on. Disabling someone in the corporate directory and closing their record in the LMS software are two separate events, and you have to decide what links them.

Before testing, ask the provider in writing which sign-in standards the LMS software works with, which attribute identifies each employee, and whether accounts are created in advance from HR data or at the first sign-in. NIST notes that an application account can be provisioned before authentication or as a result of the federated sign-in itself, and each model needs different tests. If you are still comparing providers, add the journeys below to the practical demo test for choosing an Arabic LMS in Saudi Arabia.

Plan the Pilot with IT Before Switching On SSO

Testing SSO for LMS software cannot be done by the learning team alone. The identity team in IT owns the corporate directory and the sign-in policies, HR owns the employee data, the LMS administrator owns the training records, and the provider configures the connection. Agree at the start who runs each test and who fixes what.

Then prepare representative test accounts in the directory, ideally connected to a test environment of the LMS software rather than the live one:

• A new joiner created the day before their start date.

• An employee whose name is held in Arabic and English in different fields.

• A line manager with a small team.

• An employee who moves to another department during the test.

• A leaver whose account is disabled on a set date.

• A contractor or external trainer who is not in the main directory

• An employee who has replaced the phone used for multi-factor authentication

Write the expected result for every journey before the first test, and keep a simple log of expected result, actual result, and evidence. Once the test accounts pass, extend the pilot to twenty or thirty real employees from two or three departments for two weeks, including a shift-based team, before the LMS software moves to SSO for everyone.

Journey 1: The Joiner’s First Sign-In to the LMS Software

For a new employee, the test starts on the day HR creates the record, not the day the employee first clicks a link. Check each step:

• Timing: can the joiner reach the LMS software on the first working day, or does the training account arrive a day or two after the directory account?

• Matching: does the first sign-in attach to the right learner through a stable identifier, such as the employee number, rather than an email address that may later change?

• Duplicates: an employee who had a local account before SSO keeps one record with their history, not a second, empty one.

• Attributes: the name in Arabic and English, department, branch, manager, and language arrive correctly and trigger the right onboarding assignments.

• Deep links: a course link in a reminder email opens that course after sign-in, on a computer and on a phone, not just the home page.

The joiner’s data usually leaves the HR system before it reaches the identity provider, so timing problems often start there. Our guide to connecting an LMS to HR systems in Saudi Arabia covers that data link; this test checks that the sign-in and the account in the LMS software meet on day one.

Journey 2: The Leaver and the Mover

The leaver journey is where SSO gives the most protection and where assumptions are most risky. Disable the test leaver’s directory account, then check in and around the LMS software that:

• A fresh sign-in is refused, in the browser and in any mobile app the provider offers.

• A session that was already open before the account was disabled ends within a time IT accepts.

• The learner record moves to an inactive status but keeps its full training history for audits.

• The leaver stops receiving reminders and no longer counts as overdue in compliance reports.

• If the person is rehired, the same record is reactivated rather than a new one created.

Because the two accounts have separate life cycles, agree which event deactivates the record in the LMS software: the directory change, a file from HR or a manual task. NIST also notes that an application may terminate its own account independently of the identity provider, so decide who is allowed to do that, and when.

Movers need a lighter version of the same test. When the test employee changes department in the directory, check that the LMS software updates the department, manager, and assignments at the next sign-in or synchronization, and that the previous manager can no longer see the employee’s results.

Contractors and external trainers are the usual exception. If they cannot be added to the main directory, decide whether they receive guest identities from IT or local accounts in the LMS software with an end date, and test their journey separately. Where several people share one tablet or kiosk, sessions raise further questions; our guide to testing an LMS on shared devices at Omani worksites covers those.

Journey 3: Recovering Access to the LMS Software

NIST’s authentication guidelines (SP 800-63B) describe account recovery as recovering from losing control of the authenticators needed to sign in, and state that an account recovery event always triggers a notification to the account holder. With SSO, that recovery happens at the identity provider, not in the LMS software. The test is whether employees and helpdesk staff know it.

Run these cases with IT during the pilot:

• Forgotten password: the employee resets it through the corporate route and can open the LMS software straight away.

• Lost or replaced phone used for multi-factor authentication, including for a site employee who rarely visits the office.

• Account locked after too many attempts: who unlocks it, and how quickly?

• Sign-in fails between the identity provider and the LMS software: does the error message tell the employee where to go?

• The SSO connection is down: how do named administrators still reach the LMS software to manage training?

Then align the helpdesk. Employees who cannot open the LMS software will call whoever they think owns it. Give the IT service desk a short script for training sign-in calls, give the learning team a clear route to escalate to IT, and agree a rule for mandatory courses that fall due while someone is locked out, so nobody is reported as non-compliant because of a sign-in fault.

A Hypothetical Example: An SSO Pilot at a Facilities Company

The following example is hypothetical and is included only to illustrate the method.

A facilities management company with head office staff in Riyadh and site supervisors in Jubail plans to connect its LMS software to the corporate sign-in. IT and HR prepare twelve test accounts, run the three journeys in a test copy of the LMS software, then pilot with thirty employees from finance, HR and one site team for two weeks.

Four problems appear. New hires created on Sunday morning cannot use the LMS software until Tuesday, because their training accounts come from a nightly HR file that runs after the directory update. A test leaver can no longer sign in to the LMS software, but still appears as overdue in the compliance report and still triggers manager reminders. A Jubail supervisor who replaced his phone is sent by the IT service desk to the learning team, which cannot help. And course links in reminder emails open the home page instead of the course.

The company moves account creation to the same HR event that creates the directory account, adds a deactivation rule triggered by the directory change, gives the service desk a two-line script, and asks the provider to fix the deep links. A second pilot with different employees passes all three journeys, and the remaining LMS software users move to SSO in waves.

Summary

Single sign-on removes a separate password from training, but it also ties the LMS software to the life cycle of every employee account, from the first day to the last.

Test those three journeys with representative accounts and a short pilot run jointly with IT, decide what links a directory change to the training record, and make sure the helpdesk knows where recovery happens. Then move the LMS software to SSO for everyone on evidence rather than assumption.

Click here if you want Skillup MENA to help you.