This page answers the most frequently asked questions when setting up or managing Single Sign-On (SSO) access to the Cyber Guru platform. It applies to all Identity Providers: Microsoft Entra ID, Google Workspace, Okta, ADFS, Shibboleth, and others.
Before configuring
Which field should I use as the username?
An immutable field, meaning it will not change for the entire duration of the project. This is the most important choice in the whole configuration: the username is the key the platform uses to recognize the user and cannot be changed once the project has started.
On Microsoft Entra ID, the recommended choice is the Object ID (user.objectid). On Google Workspace, use a stable identifier like the Employee ID. Other fields are allowed as long as they are immutable.
Can I use email or UPN as the username?
Technically yes, but it is not recommended. If the email or UPN changes — due to a name change, domain migration, or reorganization — the association between the identity and the platform account is broken and the user will no longer be able to log in. Restoring access requires intervention from Cyber Guru.
Which attributes do I need to send?
Four attributes are required: username, email, firstName, lastName. Optional: locale, country, and organizations in the form org_{ORG_NAME}. The complete reference, including formatting rules and update frequency, is in SSO Identity Provider Attributes. Any attributes not listed there must be agreed upon in advance with Cyber Guru.
How are teams managed?
The Team is not a separate attribute: it is one of the organizations (org_{ORG_NAME}), the one designated as the Team for statistics and gamification purposes. The designation is made in the company configuration, not in the SAML assertion. If organizations are preloaded in the platform, you do not need to send them via SSO.
What is the difference between SSO with and without user preloading?
With preloading (recommended mode), users are loaded into the platform before activation and SSO only handles authentication: anyone not preloaded cannot access. Without preloading, each user is automatically created at their first login with the attributes present in the assertion. Details in General SSO Procedure.
Can I change the mode after activation?
Yes. You can switch between the two modes by enabling or disabling the preloading flag in the company configuration: this does not require redoing the SSO configuration. Request this from your Cyber Guru contact.
Some users need to continue logging in with username and password. Is this possible?
Yes, this is called hybrid authentication: you can set on a per-user basis whether they log in via SSO or with application credentials. It must be enabled after standard SSO configuration. See Hybrid Authentication (SSO + Application Credentials).
Is LDAP supported?
No. Authentication integration is done via SAML 2.0.
Will our organization's MFA still work?
Yes, and it remains entirely under your control. Authentication happens on your Identity Provider: MFA, Conditional Access, and any other policy you apply before issuing the assertion are up to you. The Cyber Guru platform only receives the SAML response; everything that happens before that is determined by the Identity Provider.
During configuration
What do I need to send to Cyber Guru, and what will I receive?
On Microsoft Entra ID, send the application's federation metadata URL (not the certificate, not the downloaded XML file). On Google Workspace, send the GoogleIDPMetadata.xml file, because Google does not provide a public URL.
In return, you will receive the Cyber Guru SP metadata URL, from which you can get the values to enter in your application configuration.
Can I reconstruct the ACS URL and Entity ID myself?
No. Always use the values from the metadata file you are given: the address depends on the environment where your company is hosted and may not match those of other organizations or examples.
How long does activation take?
The Cyber Guru side configuration takes about 30 minutes from the moment they receive the metadata. The total time depends on your activities: creating the application, mapping attributes, authorizing users, and testing.
Are attribute names case-sensitive?
Yes. firstName and lastName must be written exactly like this, in camelCase. If written as FirstName or firstname, they will not be recognized.
On Microsoft Entra ID, do I need to fill in the Namespace field?
No: the Namespace field must be left empty. Entra ID auto-fills it with a value like http://schemas.xmlsoap.org/ws/2005/05/identity/claims: if you leave it, the attribute arrives at Cyber Guru with that prefix and will not be recognized. This is the most common error on Entra ID: delete it for all four required attributes.
How can I check what I'm actually sending?
Install a SAML tracer extension in your browser, try logging in again, and observe the SAML response. Check the exact attribute names (including case), the absence of namespace prefixes, the value of username, and the presence of all four required attributes. This is the fastest way to diagnose almost all issues.
Errors at login
"User … authenticated with identity provider saml does not exist"
The username value sent by the Identity Provider does not match any username present in the platform. Typical causes:
- the user was not preloaded (in preloading mode, they cannot access);
- the attribute mapped to
usernameis not the agreed one; - the user's email or UPN changed after activation.
Use a SAML tracer to compare the value sent with the username in the platform. In the third case, Cyber Guru intervention is needed: see SSO Maintenance.
"Unexpected error during authentication with identity provider"
The Identity Provider identity is already associated with another account in the platform. This cannot be resolved on your own: contact Cyber Guru support with the users involved and the company subdomain.
An error indicating a null field (e.g., Column 'firstname' cannot be null)
The attribute arrived with a name the platform does not recognize, so the field is empty. Two possible causes, often both present: incorrect case in the attribute name, or the Namespace field was not cleared. Fix both and retest.
"Registration error" on a new user's first login
One of the required attributes is missing in the assertion, or the attribute is present but empty in the user's profile on the Identity Provider. Check both: an unpopulated field on the IdP results in an empty attribute.
Note: this error affects companies without preloading, where the user is created at first login. With preloading, an empty attribute does not block access: the data simply remains unupdated.
Error 403 or "service not enabled" right after clicking the SSO button
The user is not authorized for the application on the Identity Provider side. On Entra ID: assign the user or their group to the application in Users and groups. On Google Workspace: make sure the user belongs to a group with Service status = ON in the User access panel. After making changes, wait a few minutes for propagation.
Login works, but first and last name are empty or incorrect on the platform
The issue is with attribute mapping, or the field is empty in the IdP profile. First and last names are updated at every login, so once the mapping is fixed, the data will be corrected at the next login.
Login works, but the user can't see courses or appears unlicensed
Check license availability in the company. If the company operates without user preloading, automatic license assignment at first login must be enabled: confirm this with your Cyber Guru contact.
Existing users can log in, new users cannot
This is expected behavior in preloading mode: only users already present in the platform can log in. Add new users via user list, or request to switch to non-preloading mode (it's a flag, not a reconfiguration).
A password is requested even after SSO login
This may be due to an application password still present on the account, or because the company uses hybrid authentication and that user is set to log in with credentials. Check the user's mode: see Hybrid Authentication.
The SSO button does not appear on the login page
The button appears when configuration is complete on both sides. If you don't see it, check with your Cyber Guru contact about the activation status.
Logout does not work correctly
Some Identity Providers handle logout in ways that require additional configuration on the Cyber Guru side. If you encounter errors or sessions that remain open after logout, report it: this is not a change to make on your Identity Provider.
After go-live
Do SSO users receive a welcome email?
No. The welcome email is tied to license assignment — it is sent when a license association event is expected and licenses are actually assigned — and is a mechanism independent of SSO. Users who log in via SSO do not receive credentials by email, because they don't need them: they access the platform from their dedicated address and authenticate with their company credentials.
How long does a session last?
The platform session lasts 30 minutes; after it expires, the user must log in again. If a valid session is still active on your Identity Provider, re-authentication is transparent for the user.
Can metadata change over time?
They should not. After configuration, metadata should be considered fixed. If something changes on your Identity Provider — new certificate, new application, different endpoints — do not modify or recreate the configuration on your own: open a request with Cyber Guru support, who will coordinate the update on both sides.
The SAML signing certificate is expiring. What should I do?
Notify Cyber Guru of the new certificate before activating it, and agree on the switch window. The full procedure is in SSO Maintenance.
We are changing our company email domain. Does this affect SSO?
Yes, if email or UPN are used as username: the change breaks the association with platform accounts. Notify Cyber Guru before the migration: if planned in advance, the alignment can be done in a coordinated window.
What happens if we disable a user on our Identity Provider?
The user will no longer be able to authenticate, so they cannot access the platform. However, their account and associated license remain in the platform: SSO manages authentication, not the account lifecycle. To automatically align deactivations and deletions, SCIM 2.0 provisioning is required; without SCIM, deprovisioning methods must be agreed with Cyber Guru.
We have two tenants or two Identity Providers. Is this supported?
Yes. Access started from the Identity Provider portal and managing multiple companies on the same tenant are also supported. See Advanced SSO Scenarios: the sequence of steps changes, so let us know before starting configuration.
Can we automatically sync users and attributes?
SSO only transmits information at login. To sync user lifecycle or bring many attributes into the platform, consider SCIM 2.0 provisioning or APIs. Discuss this with your Cyber Guru contact before go-live.
Need help?
If the problem persists after these checks, contact Cyber Guru support and provide:
- the full error message and the time of the attempt;
- the username of the affected user and the company subdomain;
- if available, the
SamlRequest.xmlandSamlResponse.xmlfiles exported from the SAML tracer.
This information significantly reduces diagnosis time.