CPQ SSO Authentication
IT disabled her Azure AD account on Monday. She still opened CPQ with a local password until Wednesday.
SSO authentication · session
Identity from enterprise IdP
Employee
Corporate user
Company identity provider
Okta · Entra ID · Google Workspace
SAML 2.0 / OIDC
No Mercura-only password
Mercura
Authenticated
Role + access
Mapped from IdP groups
Step 4 · Returned authenticated
SSO establishes identity · Access Control determines permissions
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.
User lifecycle
Joiner · Mover · Leaver
Joiner
Added to IdP group → Mercura account provisioned → Role assigned
Mover
IdP group changes → Mercura role changes
Leaver
IdP access removed → Mercura access revoked
Role mapping
IdP group → Mercura role
SSO establishes identity. Access Control determines permissions.
IdP Group
CPQ-Sales-EU
Mercura Role
Sales Rep — Europe
IdP Group
CPQ-Pricing
Mercura Role
Pricing Analyst
What's included
What CPQ SSO authentication covers
Connect
- 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
Provision
- SCIM and just-in-time user provisioning from directory groups
- IdP group to Mercura role mapping on login
Policy
- MFA and session policy enforced by the identity provider
- Local CPQ password disable after SSO cutover
Evidence
- SSO authentication events captured in audit logs
The difference
CPQ login before and after SSO authentication
Mercura-only passwords
- 01 CPQ credentials exist outside the corporate identity directory then
- 02 Departed staff retain CPQ access if offboarding skips a manual step then
- 03 MFA and session rules from IT do not apply to CPQ login then
- 04 Role assignment duplicated in CPQ and the identity provider then
- 05 Security audits flag CPQ as outside identity governance scope
With Mercura SSO
- 01 Users sign in through the same IdP as email, CRM, and ERP
- 02 Disabling a directory account removes CPQ access without a second ticket
- 03 MFA and conditional access inherited from corporate policy
- 04 Directory groups map to Mercura roles on provision
- 05 CPQ included in standard identity and access reviews
Real-world example
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.
Business impact
Central identity control
Users sign in through the same IdP as email, CRM, and ERP.
Faster onboarding and offboarding
Disabling a directory account removes CPQ access without a second ticket.
Consistent MFA and session policy
MFA and conditional access inherited from corporate policy.
Compare
SSO vs access control
SSO Authentication
Who are you?
Identity provided by enterprise IdP.
Access Control
What are you allowed to do?
Permissions provided by Mercura role/scope model.
Governance map
How identity, permissions, change, review, publish, history, and evidence connect
Authenticated · identity from IdP
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.