CPQ SSO Authentication
IT disabled her Azure AD account on Monday. She still opened CPQ with a local password until Wednesday.
The challenge
IT disabled her Azure AD account on Monday. She still opened CPQ with a local password until Wednesday.
A commercial kitchen and ventilation hood OEM runs Mercura CPQ for twenty-eight inside sales reps and dealer portal users who configure hood widths, filtration tiers, and fire-suppression add-ons. Corporate policy routes every other application through Azure AD with MFA. CPQ still accepted Mercura-only passwords created when the portal launched, so users kept a second login nobody tracked in the central directory.
When a regional rep left, HR processed offboarding in Azure AD the same day. CPQ access stayed active until sales ops noticed open quotes in her name two days later. Password resets for CPQ required a separate ticket queue. Security review flagged local credentials that bypassed session timeout and MFA rules applied to email, CRM, and ERP.
Access-control pages define what each role may do inside CPQ. Audit-log pages record actions after login. Approval-workflows pages route changes through reviewers. SSO authentication is different: it decides how users prove identity at the door, whether CPQ trusts your identity provider instead of a standalone password, and whether disabling a directory account closes CPQ access the same hour.
Inquiry to config to price to approval to order should not depend on a shadow credential system IT forgot to include in offboarding checklists.
How it works
How Mercura connects CPQ login to your identity provider
IT configures Mercura against your identity provider using SAML 2.0 or OpenID Connect. Users reach CPQ through your standard SSO flow: IdP portal tile or Mercura URL redirect to Azure AD, Okta, Google Workspace, or another supported provider. No Mercura-only password is required after cutover. MFA, session length, and conditional access rules come from the IdP policy already applied to other apps. SCIM or just-in-time provisioning creates CPQ users when directory group membership changes. IdP groups map to Mercura roles so access control rules apply on first login. Authentication events write to audit logs with IdP identity attribution. Access-control pages still define permissions; SSO ensures the person logging in is the employee or partner your directory vouches for.
What's included
What CPQ SSO authentication covers
- SAML 2.0 and OpenID Connect support for major enterprise IdPs
- Azure AD, Okta, Google Workspace, OneLogin, and PingIdentity compatibility
- IdP-initiated and service-provider-initiated login flows
- SCIM and just-in-time user provisioning from directory groups
- IdP group to Mercura role mapping on login
- MFA and session policy enforced by the identity provider
- Local CPQ password disable after SSO cutover
- SSO authentication events captured in audit logs
The difference
CPQ login before and after SSO authentication
- CPQ credentials exist outside the corporate identity directory
- Departed staff retain CPQ access if offboarding skips a manual step
- MFA and session rules from IT do not apply to CPQ login
- Role assignment duplicated in CPQ and the identity provider
- Security audits flag CPQ as outside identity governance scope
- Users sign in through the same IdP as email, CRM, and ERP
- Disabling a directory account removes CPQ access without a second ticket
- MFA and conditional access inherited from corporate policy
- Directory groups map to Mercura roles on provision
- CPQ included in standard identity and access reviews
Real-world application
Example workflow: kitchen hood OEM Azure AD cutover
An OEM of canopy hoods, variable-flow ventilation, and integrated fire suppression sold through dealer configurators. Pre-audit review found twenty-eight CPQ users on local passwords while the rest of the group used Azure AD with enforced MFA. After Mercura SAML configuration and SCIM group sync, inside sales and dealer portal users signed in through Azure AD only. Local passwords were disabled. IdP groups for CPQ Sales and CPQ Dealer mapped to Mercura roles with matching quote and catalog scope. When a rep left mid-quarter, disabling her Azure AD account closed CPQ the same afternoon. Open quote investigations no longer started with whether IT remembered the CPQ offboarding step.
Business impact
Why SSO closes the identity gap CPQ often sits in
SSO authentication brings CPQ under the same identity infrastructure as the rest of the enterprise stack. It complements role permissions, audit trails, publish governance, and approval routing. Mercura does not replace your IdP, conditional access design, or annual access certification programme. Someone must maintain group-to-role mappings when org structure changes. If the pain is "CPQ is the app we forget during offboarding", directory-backed login in CPQ aligns inquiry, configuration, price, approval, and order with users whose access IT can revoke in one place.
See CPQ login through your identity provider with group role mapping
Book a demo and walk through SAML or OIDC setup, MFA inheritance, and IdP group mapping to Mercura roles.
Let’s build together.
We empower manufacturers to master product modeling, streamline quoting process, reduce errors, and ultimately deliver the tailored solutions that customers demand.