Single Sign On FAQs
What is SSO? Single Sign-On (SSO) allows users to authenticate using their corporate Identity Provider (IdP) instead of creating separate credentials within our platform. This centralizes authentication and improves both security and user experience.
-
Does the application support SAML 2.0?
Yes. The application supports SAML 2.0 through our SSO integration, with FusionAuth acting as the SAML Service Provider and brokering authentication with the customer’s Identity Provider using standard SAML 2.0 flows.
-
How do you limit access (e.g., specific user groups, departments, or role-based access)? Will this authorization be performed by the application?
Access is controlled in two stages. Authentication is performed via SSO through the Identity Provider, while authorization is enforced by our application itself. Users must be pre-registered in Mission Control using their email address, and after successful authentication, the application assigns access based on the roles already configured internally in Mission Control for that user. At this time, role or privilege assignment is not dynamically derived from Identity Provider groups or attributes.
-
Our preferred identifier is SerialNumber (Public Person ID/PPID). Can the application use this as a primary identifier instead of email?
Currently, the application requires the use of email as the primary identifier for user registration, lookup, and SSO routing based on domain. Unfortunately, we are unable to accommodate the use of SerialNumber as a primary identifier at this time.
-
How does authentication work?
The general flow is:
-
-
-
The user attempts to access the platform.
- The user is redirected to their corporate Identity Provider.
- The IdP validates credentials (and MFA if enabled).
- We receive a signed response (SAML assertion or ID token).
- We validate the signature and create the user session.
-
-
- What information do we receive from the IdP?
During authentication, we receive basic identity attributes such as:
-
-
-
Email address
-
Full name
-
Unique identifier (NameID)
-
Optional attributes (if configured by the customer)
-
-
We do not query full directories or access user data beyond the authentication response.
-
Are users created automatically?
No. Users must be created in Mission Control as either Customers or Employees (depending on the type of access required). Employee records must also have an appropriate role assigned within Mission Control.
- Is MFA managed by your platform?
Multi-Factor Authentication (MFA) is typically enforced at the Identity Provider level.
We rely on the security policies configured in the customer’s IdP.