Single Sign-On (SSO) for NebulaCRS
Introduction
Single Sign-On (SSO) is a secure authentication method that allows you to access multiple applications and systems using one set of login credentials (your company username and password).
Instead of remembering unique passwords for every service, you log in once to your company's central system (such as Microsoft or Google), and SSO handles your access across all connected platforms, including NebulaCRS.
Configuration and Initial Sign-Up
The SSO process requires a one-time sign-up to link your NebulaCRS user profile with your central company login credentials.
Admin/Supervisor Setup (System Administrator Tasks)
Create or Update User: Create a new user or update an existing user profile within NebulaCRS. (Refer Knowledge Base Article).
Assign Company Email: Ensure the user profile has a valid company email address assigned. This email address is the critical link for SSO.
Optional Invitation: Click the 'Invite User' button to send an invitation email.
End-User Sign-Up Process (User Tasks)
Follow Invitation: If you received an invitation email, click the link inside and select the Sign Up option.
Match Email: During the sign-up process, you must use your company email address that was assigned to you in NebulaCRS.
First Login: Once the sign-up is complete, you can log in to the connected NebulaCRS modules using the dedicated "Organisations Login" option (e.g., "Login with Google" or "Login with Microsoft").
Email Requirement: You must have a valid company email address assigned to your NebulaCRS profile.
Legacy Password Requirement: A password still needs to be assigned to your user account within the NebulaCRS system. This password is required for Legacy Login modules (see supported modules below) and for Supervisor Override features. It is NOT used for logging into the SSO-supported modules. Your SSO login is secured by your Identity Provider (e.g., Microsoft or Google).
How SSO Works
User accesses the NebulaCRS application and selects the SSO login option.
NebulaCRS redirects the user to the SSO provider for authentication.
The SSO provider verifies credentials and sends an authentication token back.
The user is granted access to NebulaCRS (and other connected apps) without logging in again.
Security Authentication
The SSO system checks your credentials against a Central Identity Provider (IdP), such as Microsoft Entra ID or Google Workspace.
To enhance security, your IdP may require extra verification steps before the token is issued. These are known as Multi-Factor Authentication (MFA) and may include:
Two-Factor Authentication (2FA): Entering a one-time code sent to your phone or generated via an authenticator app.
PIN or Security Questions: Answering a personal security question or entering a personal identification number.
Device or Location Verification: Checking if you are logging in from a recognized device or location.
These steps are managed by your central IT department, not by NebulaCRS directly.
Supported CRS Modules and Legacy Access
Not all NebulaCRS applications support SSO.
Login Type | Supported Modules | Notes |
SSO Login | NebulaCRS Admin | Use your company's SSO button. |
| Call Center Reservations | Use your company's SSO button. |
| Booknow 2.0 Content Manager | Use your company's SSO button. |
Legacy Login | eRes | Requires your NebulaCRS legacy username and password. |
| Old Booknow Content Manager | Requires your NebulaCRS legacy username and password. |
Supervisor Override: Supervisors using override features must still log in with their legacy NebulaCRS account for the override action. The current SSO configuration does not support concurrent sessions (logging in with multiple accounts) or multi-account sign-in within the same browser session.
For IT Administrators
IT administrators may need to apply additional permissions within the applicable central identity platform to allow the nebulaone application access.
Identity Provider (IdP) | Required Action | Support Reference |
Microsoft Entra ID | Allow app nebulaone. Users will see an error message if permission is not granted (a specific error screen, often requesting admin consent). | Microsoft Help Center |
Google Workspace | Allow app nebulaone. Users will see a specific permission error screen if access is denied. | Google Workspace Help |
Apple | Allow nebulaone access within your Apple Account | Apple Support |
*HTI is not responsible for third-party forums. Linked articles are provided for troubleshooting convenience only.
Troubleshooting
Issue | Potential Cause(s) | Resolution(s) |
Invite email not received | Email filtered to spam/trash; incorrect email address in CRS; organisation filtering (e.g., Mimecast). | Check Spam or Trash folders. Check the email address signed up is correct. If your organisation uses Mimecast, allow the email or contact your IT administrator. |
Invalid Credentials | Incorrect details entered; attempting to use the Legacy password on the SSO button. | Confirm details are correct. Ensure you are entering your company credentials (not your legacy CRS password) when using the SSO login option. |
"We couldn’t find an account with that email." | Email mismatch between CRS and sign-up/login attempt. | Check with your CRS System administrator to confirm the correct email is assigned to your user profile. Ensure you are using the correct company email address to sign in. |
New user created, not able to sign in but did Sign Up | The user account is missing the required legacy password. | The user must have a password assigned in NebulaCRS to complete the full linking process, even if they only use SSO going forward. |
Module Access Denied | The user group does not have access to specific module (CRS Admin, Call Center or Content Manager) | Confirm access rights with your system administrator. |
“Need admin approval” (or similar wording) appears. | Admin consent not granted: The SSO application (e.g., NebulaCRS, NebulaONE) requires permissions to access basic profile information, but these permissions have not yet been approved by your organization’s Microsoft/Google administrator.
User consent blocked by policy: The organization’s identity provider (IdP) — such as Microsoft Azure Active Directory (AAD) or Google Workspace — has a policy that prevents users from granting consent to third-party applications.
App not yet registered or verified: The SSO app may not be registered, or its details (redirect URL, permissions, etc.) have changed since first setup. This triggers the need for admin re-approval.
Different tenant or domain: The login attempt may be coming from a user whose email domain does not match the organization’s tenant domain authorized for SSO. | Contact your IT Administrator for further assistance |