Product configurator SSO and identity integration

Give every customer, dealer and team member the right Configurix access.

Configurix can connect enterprise identity with product configuration, pricing, quotes and projects. A dependable implementation separates SSO, provisioning, roles, tenant isolation, service identities and session security—then proves each boundary with working access tests.

Plan the identity boundary Discuss enterprise access

One identity decision

Identity provider

User authenticated · issuer trusted

Configurix account

Subject resolved · active

Tenant and role

Dealer North · sales role

Object decision

Project CX-4821 · allowed

A valid assertion creates identity context. Configurix still checks the local user, business tenant, role and requested object before showing a price, project, quote, order or administrative function.

Identity architecture definition

SSO is one layer—not the complete access-control system.

Enterprise access becomes safer and easier to explain when authentication, federation, provisioning and authorization remain distinct. Each layer has different protocols, owners, failure modes and acceptance evidence.

Authentication

How a person or service proves its identity. SSO can delegate human authentication to a trusted identity provider.

Federation

How Configurix, as the relying party, verifies an assertion from an identity provider and establishes a local session.

Provisioning

How user accounts, group membership, activation, update and deactivation are managed across their lifecycle.

Authorization

What the authenticated identity may do to a specific tenant, project, price list, quote, order or administration object.

Interactive identity architecture planner

Define users, federation, lifecycle and authorization together.

Choose the closest deployment. The result identifies the trust, mapping and acceptance evidence to prioritize. Actual provider capabilities, protocols, roles and security requirements depend on the working systems and signed Configurix scope.

Primary audience

Federation model

Account lifecycle

Authorization model

Trust and authority matrix

Put identity evidence and business permission at the correct boundary.

Authority	Primary responsibility	Boundary to prove
Identity provider	Primary workforce or partner authentication, authenticators, account status, group or attribute assertions and federation keys	Configurix validates the trusted issuer and assertion; it does not blindly trust an email address or unsigned browser field.
Configurix identity layer	Federated account resolution, local user identity, session, tenant memberships, role mappings and identity audit events	Authentication establishes who signed in. Local policy still determines which Configurix resources are accessible.
Business tenant owner	Dealer, distributor, showroom, brand, legal entity, market and product-assignment decisions by agreed workflow	External IdP groups cannot grant access to another tenant unless the mapping and business authority explicitly allow it.
Product and pricing owners	Catalog, rule, price-list, discount, quote, document and publication permissions	Powerful product or pricing actions need explicit roles, object scopes, approval and audit—not a generic authenticated state.
Application APIs	Human-session APIs, service identities, scopes, object authorization, rate controls and integration audit	A valid access token is not sufficient proof that its subject may read or change the requested project or tenant.
Connected CRM, ERP or ecommerce	Their own users, service accounts, object permissions and downstream business authority	Do not reuse a browser user's privileges as an uncontrolled integration identity or copy unnecessary identity attributes.

Canonical identity contract

Carry trusted identity without turning every claim into permission.

Federation establishes a trusted authentication context. Configurix should retain the smallest identity contract needed to resolve a user, create a session, map approved business membership and explain authorization decisions.

issuer

Exact trusted identity-provider identifier and configured federation connection

subject

Stable provider-scoped subject identifier used with the issuer to resolve the local account

audience

The intended Configurix client or relying-party identifier accepted for this assertion

assurance

Authentication time, method, context or agreed assurance information needed by policy

attributes

Minimum approved name, email, locale, organization or other claims with source and purpose

tenant

Configurix organization, dealer, region or brand membership established through controlled mapping

roles

Local role and capability assignment, plus who or what is authoritative for each change

lifecycle

Created, active, suspended, deactivated, removed and reactivated state with effective timing

session

Issued, refreshed, expired, reauthenticated, revoked and logged-out state by channel

audit

Correlation, actor, source, target object, decision, reason, timestamp and administrative evidence

Role model

Define business capabilities without weakening tenant and object isolation.

Customer

Create and resume owned projects, review allowed prices or quotes and approve or request action by scope.

Dealer user

Work only within assigned dealer accounts, catalogs, price lists, customers, projects and permitted commercial actions.

Dealer manager

Manage approved dealer users or assignments without crossing the manufacturer's tenant or global administration boundary.

Salesperson

Create and continue customer projects, prepare quotes and use permitted price or discount workflows.

Product manager

Maintain assigned catalog content, choices, rules, assets and releases through the accepted governance process.

Pricing manager

Maintain assigned price sources, discount policy, validity and approvals without inheriting unrelated system administration.

Operations user

Read accepted project, order, survey, installation or production context required for assigned operational work.

Administrator

Manage tenant configuration and authorized identities; sensitive global actions remain deliberately limited and audited.

A role is not a global data entitlement. Every protected request should also evaluate organization, ownership, product assignment, market, price authority, project sharing and other applicable object policy.

Federated identity lifecycle

Make trust, access and deactivation observable from end to end.

Establish trust

Register the exact IdP and Configurix identifiers, endpoints, redirect locations, keys, certificates and accepted profile.

Resolve organization

Determine the approved tenant, dealer, market or brand from a controlled connection or business mapping.

Authenticate

Send the user through the agreed federation flow and validate issuer, audience, signature, time and transaction protections.

Resolve account

Match the issuer-and-subject pair to one Configurix user; avoid treating mutable email alone as permanent identity.

Provision membership

Create or update approved local attributes, tenant membership, groups and status through JIT, SCIM or administration.

Authorize object

Evaluate role, tenant, ownership, product, price and project policy on every protected request.

Operate session

Apply expiry, refresh, reauthentication, logout, device and sensitive-action policy to the Configurix session.

Deactivate and reconcile

Remove access promptly, terminate or limit sessions by policy and compare IdP, SCIM and Configurix state.

Identity integration patterns

Match the access pattern to the people and systems using Configurix.

One workforce IdP

Employees use one managed identity provider for Configurix sales, product, pricing and administration roles.

Workforce IdP → OIDC or SAML → Configurix local account and role mapping

Control: Keep privileged roles explicit and test suspended users, group removal, old sessions and administrator recovery.

Manufacturer plus dealer federation

Internal users and external dealer organizations authenticate through different trusted identity connections.

Home-realm or tenant choice → approved IdP → dealer membership → object policy

Control: Bind each connection to approved organizations; never derive cross-tenant access from a user-entered domain alone.

SCIM-managed enterprise lifecycle

The organization requires centralized user and group creation, update, suspension and deprovisioning.

Identity lifecycle system → SCIM service → Configurix user, group and active-state reconciliation

Control: Define group-to-role mapping, soft versus hard deletion, reactivation, conflicts, retries and manual exception ownership.

Invited customer identity

Customers receive controlled access to specific configured projects without inheriting workforce identity policy.

Project invitation → customer authentication → project membership → scoped session

Control: Use expiring invitations, verified account resolution, project-level authorization and clear sharing revocation.

Step-up for sensitive actions

Price publication, high discount, user administration or order approval requires stronger or recent authentication.

Existing session → policy trigger → reauthentication or stronger context → authorized action

Control: Define which actions require step-up, what evidence is accepted, expiry and behavior when the IdP is unavailable.

Separate service identities

CRM, ERP, ecommerce, PIM or automation needs API access without impersonating a human browser user.

Integration identity → scoped credential or token → Configurix API → object authorization and audit

Control: Use least privilege, rotation, environment isolation, workload ownership and no interactive login privileges.

Session, logout and recovery

Define what happens after the identity provider says yes.

Federation creates a Configurix session; it does not manage every later session decision automatically. Expiry, refresh, reauthentication, logout, deactivation and recovery need explicit behavior and working evidence.

Session creation

Create a Configurix session only after complete assertion and transaction validation.

Idle and absolute expiry

Define both inactivity and maximum session age according to role and business risk.

Reauthentication

Require recent or stronger authentication for sensitive administrative or commercial actions when policy demands it.

Refresh and rotation

Protect and rotate refresh material according to the chosen protocol and application architecture.

Local and federated logout

Document what local logout, IdP logout, front-channel and back-channel behavior actually terminate.

Account deactivation

Decide whether existing sessions are revoked immediately, expire naturally or require a separate revocation event.

Recovery

Define break-glass and administrator recovery without creating a permanent bypass around enterprise identity policy.

Audit

Record sign-in, failure, mapping, role change, step-up, logout, revocation and privileged action evidence.

Implementation blueprint

Start with one identity provider and every role it can reach.

Inventory identities and journeys

List customer, dealer, sales, manager, product, pricing, administrator and service-account use cases.

Choose the federation profile

Document IdP, protocol, flow, client or service-provider identity, endpoints, keys, claims and logout expectations.

Define stable account resolution

Use issuer and subject identity, duplicate controls, migration rules and deliberate email-change behavior.

Model tenancy and roles

Map organizations, dealer accounts, markets, products, price lists and capabilities with explicit authority.

Design provisioning

Choose JIT, SCIM, invitation or administration; specify create, update, suspend, delete, reactivate and reconcile behavior.

Protect sessions and APIs

Set session, reauthentication, token, service identity, secret, environment and object-authorization controls.

Test failure and recovery

Cover invalid assertions, stale keys, removed groups, deactivation, IdP outage, duplicate users and locked administrators.

Operate the trust relationship

Monitor signing-key rollover, certificate expiry, mapping drift, inactive access, audit and incident ownership.

Federation and access security

Validate the assertion, then authorize the object.

Validate issuer, audience, signature, key, time, nonce, state and the exact protocol transaction according to the chosen profile.
Prefer stable provider-scoped subject identity; treat email, name and group claims as mutable attributes unless policy says otherwise.
Minimize requested claims and document why Configurix receives, stores, refreshes and deletes every identity attribute.
Enforce tenant and object authorization after authentication on every project, price, quote, order, document and administration request.
Prevent role escalation through untrusted claims, editable profile fields, ambiguous group names or unsupported identity providers.
Separate browser sessions, API access tokens, SCIM credentials, integration identities and emergency administrator access.
Protect signing keys, client credentials, certificates and SCIM tokens with rotation, environment isolation and accountable ownership.
Monitor sign-in anomalies, mapping failures, privileged changes, deprovisioning lag and repeated access to unauthorized objects.

Acceptance evidence

Test forbidden paths as carefully as successful sign-in.

1A valid user from the trusted IdP signs in once and resolves to exactly one intended Configurix account and tenant membership.
2An assertion with the wrong issuer, audience, signature, time, state, nonce or transaction context is rejected safely.
3Two identity providers issuing the same email address do not merge users unless an explicit controlled account-linking process approves it.
4Dealer A cannot read, guess, search, export or mutate Dealer B projects, customers, prices, quotes, orders or documents.
5Removing a user from the authoritative group or SCIM directory removes the intended role or access within the accepted time window.
6Suspension, deletion and reactivation preserve the correct audit history and do not accidentally restore obsolete privileges.
7Role and attribute changes affect only the permitted tenant, market, product, price and administration capabilities.
8Expired, revoked, replayed or logged-out sessions and tokens cannot continue protected actions beyond the documented policy.
9A sensitive action requires the expected recent or stronger authentication context and fails honestly when evidence is insufficient.
10Signing-key rollover or certificate renewal succeeds without accepting an untrusted key or causing an uncontrolled lockout.
11A service identity cannot use interactive customer or administrator flows and can access only its approved API objects and actions.
12Reconciliation identifies extra, missing, inactive, duplicated and privilege-drifted accounts across the identity provider and Configurix.

Failure patterns

Where enterprise SSO creates a false sense of security.

SSO is treated as authorization

A valid login is allowed to access every tenant, project or admin action because object policy was never designed.

Email is the permanent user key

A changed, recycled or identical cross-provider email links the wrong identity or duplicates a user.

Every IdP group becomes a role

Uncontrolled group naming or claims can grant pricing, publication or administration privileges.

JIT provisioning has no offboarding

Users are created at first login but never suspended when they leave the organization or dealer.

SCIM success means access is gone

The account changes, but existing sessions, tokens, tenant memberships or project shares remain active.

Logout promises too much

The interface says signed out while another Configurix session, IdP session or refresh path remains valid.

Service integrations impersonate people

ERP or CRM automation inherits human access and produces weak ownership, rotation and audit evidence.

The emergency account becomes normal

A break-glass identity bypasses SSO permanently and is shared, unmonitored or overprivileged.

Primary identity standards

Design federation, lifecycle and sessions from current primary guidance.

OpenID Foundation · OpenID Connect Core

Primary specification for authentication on top of OAuth 2.0 and interoperable claims about the authenticated end user.

Open primary source

OASIS · SAML 2.0 Technical Overview

Official overview of SAML assertions, identity-provider and service-provider roles, profiles, metadata and message exchanges.

Open primary source

IETF · SCIM Protocol RFC 7644

Internet Standards Track protocol for creating, retrieving, replacing, updating, deleting and discovering identity resources.

Open primary source

IETF · OAuth 2.0 Security BCP RFC 9700

Current best-practice security guidance that updates the original OAuth 2.0 threat model and deprecates unsafe patterns.

Open primary source

NIST · Digital Identity Guidelines SP 800-63-4

Current NIST framework for risk, identity proofing, authentication and federation assurance with security and privacy considerations.

Open primary source

NIST · Federation and Assertions SP 800-63C-4

Current federation guidance for IdP and relying-party trust, assertions, audience restriction, replay and injection protection.

Open primary source

W3C · Web Authentication Level 3

Primary web standard for public-key credentials scoped to a relying party and created with authenticators.

Open primary source

SSO and identity FAQ

Detailed answers for security, IT, sales, dealer and product teams.

Product configurator single sign-on allows an approved user to authenticate through a trusted identity provider and then establish a Configurix session without maintaining a separate everyday password for that application. The implementation still needs a federation protocol, stable account resolution, tenant membership, role mapping, session policy and object-level authorization. SSO answers who authenticated; it does not automatically decide which products, prices, projects or administration actions that identity may access.

OpenID Connect or SAML federation can be scoped for a Configurix deployment when the chosen identity provider, application registration, domains, metadata, endpoints, keys, certificates, claims, logout expectations, environments and reviewers are available. OpenID Connect defines an identity layer on OAuth 2.0; SAML uses XML assertions and established enterprise profiles. The exact supported profile and acceptance evidence must be confirmed against the working Configurix build.

A standards-based connection can be evaluated for Microsoft Entra ID, Okta, Google Workspace, Ping Identity, Auth0 or another enterprise IdP when it exposes the required OpenID Connect or SAML behavior and the customer can configure the application. Product name alone is not enough: verify issuer, client or service-provider identity, redirect or assertion endpoint, signing keys, claims, group behavior, logout, provisioning and tenant policy in the working environment.

OpenID Connect is an authentication and identity layer built on OAuth 2.0. OAuth 2.0 itself is an authorization framework for delegated access and tokens; an access token is not automatically proof of user authentication. SAML 2.0 is an XML-based federation framework for exchanging security assertions between identity providers and service providers. Choose the agreed profile from application architecture, IdP capability, security and operational needs rather than treating the names as interchangeable.

No. SSO establishes or conveys authenticated identity. Configurix still needs local authorization for tenant membership, product catalogs, price lists, customers, projects, quotes, orders, documents, user administration and integrations. Roles can define broad capabilities, while ownership, tenant and object policies constrain each record. The API must enforce those decisions even when the interface hides unavailable controls.

Create an explicit allowlisted mapping from a trusted connection and group or attribute to a defined Configurix role and tenant scope. Document who owns each mapping, what happens when a group is absent, renamed or duplicated and whether powerful roles require separate approval. Do not accept arbitrary group names from any IdP or allow a profile field that the user can edit to become an authorization role.

Dealer federation adds organization resolution and tenant isolation. Each trusted identity connection or controlled mapping must resolve the user to the correct manufacturer, distributor or dealer account, then apply assigned products, markets, price lists, customers and roles. A dealer user must not gain access to another dealer through an email domain, guessed ID or reused group. Test cross-tenant search, export, files, APIs and historical links.

Yes, when customer identity is part of the agreed project. A customer can authenticate through a customer identity provider, invitation flow or another accepted method, then access only owned or explicitly shared projects, quotes and approvals. Workforce SSO policy should not be copied blindly into public journeys. Define account recovery, invitation expiry, project sharing, consent, deletion and what happens when the customer's email changes.

SCIM is an HTTP-based standard for managing identity resources across domains. In a scoped Configurix deployment, SCIM can create, retrieve, update, deactivate or delete users and manage agreed group membership. SCIM does not replace authentication, session revocation or local object authorization. The implementation needs authentication for the SCIM service, schema and mapping rules, pagination, idempotent behavior, retries, conflicts, reconciliation and security tests.

Just-in-time provisioning resolves or creates the Configurix user when a valid federated sign-in occurs. It is simple for first access but cannot remove a user who never signs in again unless another lifecycle process exists. SCIM lets an identity lifecycle system update or deactivate users proactively. Some deployments combine SCIM for lifecycle with federation for authentication and controlled JIT fallback for selected cases.

Use the stable logical pair of trusted issuer and provider subject identifier to resolve the federated identity. Email, display name, department and group membership are useful attributes but can change and may be duplicated across providers. Account linking, email migration and identity-provider replacement need a controlled process with audit and proof; automatic linking by matching email can attach the wrong person to privileged projects.

Authentication strength can normally be provided by the chosen identity provider, including its MFA or passkey policies. Configurix can scope requirements for accepted authentication context or recent reauthentication for sensitive actions. WebAuthn defines public-key credentials bound to a relying party, while NIST SP 800-63 provides assurance guidance. Exact authenticator, assurance and step-up behavior must be tested with the selected IdP and Configurix deployment.

Logout is protocol- and deployment-specific. Local Configurix logout can terminate the application session while the IdP session remains active. OIDC or SAML may provide additional front-channel or back-channel logout behavior, but coverage differs across clients, tabs, devices and providers. Document precisely which sessions and refresh paths are terminated, test deactivation separately and avoid promising that one button signs the user out of every connected application.

The accepted policy should define the maximum delay from authoritative suspension or removal to blocked Configurix access, role removal and session handling. Higher-risk administrator, pricing or order roles may need faster revocation. SCIM delivery success alone does not prove all access is gone; test local membership, active sessions, API tokens, project shares, service credentials and later reconciliation.

CRM, ERP, ecommerce, PIM and automation should normally use separate service or workload identities with narrowly scoped credentials or tokens, not a copied employee session. Define the permitted environment, tenant, APIs, objects, actions, rate, rotation, expiry and owner. A service identity should not gain interactive login or global administrator access unless a separately justified and accepted design requires it.

Test valid sign-in plus wrong issuer, audience, signature, time, state and transaction context; duplicate email across IdPs; first login; existing account; group and role change; dealer cross-tenant access; user suspension; SCIM retry and conflict; session expiry; logout; sensitive-action reauthentication; key rollover; IdP outage; service identity scope; administrator recovery and full reconciliation. Verify protected APIs and direct object URLs, not only the login screen.

Provide identity-provider product and tenant, protocol and profile, application registration process, domains, metadata or discovery URL, keys and certificates, claims, subject strategy, user and group examples, tenant and role model, provisioning method, session and logout requirements, MFA or step-up policy, service identities, environments, network restrictions, deactivation timing, recovery, audit requirements, reviewers and acceptance cases.

A focused Configurix Fast Launch can usually target one governed product in around seven days when identity integration is outside that first phase and product inputs are ready. A white-label deployment with workforce and dealer SSO, several IdPs, SCIM, role mapping, tenant isolation, service identities and security acceptance can take up to 30 days depending on IdP access, policy decisions, environments, user lifecycle, test cases and reviewer availability. The signed scope and working evidence remain authoritative.

Bring one IdP and your real role model

Map trusted identity to the exact Configurix access your business needs.

We can define federation, account resolution, provisioning, tenant and role mappings, sessions, service identities, deactivation, recovery and working authorization tests across customers, dealers and internal teams.

Plan an identity workflow demo

Security and privacy Configurator integrations B2B dealer portal Headless configurator Order management Implementation guide

SSO is one layer—not the complete access-control system.

Authentication

Federation

Provisioning

Authorization

Define users, federation, lifecycle and authorization together.

Put identity evidence and business permission at the correct boundary.

Carry trusted identity without turning every claim into permission.

Define business capabilities without weakening tenant and object isolation.

Customer

Dealer user

Dealer manager

Salesperson

Product manager

Pricing manager

Operations user

Administrator

Make trust, access and deactivation observable from end to end.

Establish trust

Resolve organization

Authenticate

Resolve account

Provision membership

Authorize object

Operate session

Deactivate and reconcile

Match the access pattern to the people and systems using Configurix.

One workforce IdP

Manufacturer plus dealer federation

SCIM-managed enterprise lifecycle

Invited customer identity

Step-up for sensitive actions

Separate service identities

Define what happens after the identity provider says yes.

Session creation

Idle and absolute expiry

Reauthentication

Refresh and rotation

Local and federated logout

Account deactivation

Recovery

Audit

Start with one identity provider and every role it can reach.

Inventory identities and journeys

Choose the federation profile

Define stable account resolution

Model tenancy and roles

Design provisioning

Protect sessions and APIs

Test failure and recovery

Operate the trust relationship

Validate the assertion, then authorize the object.

Test forbidden paths as carefully as successful sign-in.

Where enterprise SSO creates a false sense of security.

SSO is treated as authorization

Email is the permanent user key

Every IdP group becomes a role

JIT provisioning has no offboarding

SCIM success means access is gone

Logout promises too much

Service integrations impersonate people

The emergency account becomes normal

Design federation, lifecycle and sessions from current primary guidance.

OpenID Foundation · OpenID Connect Core

OASIS · SAML 2.0 Technical Overview

IETF · SCIM Protocol RFC 7644

IETF · OAuth 2.0 Security BCP RFC 9700

NIST · Digital Identity Guidelines SP 800-63-4

NIST · Federation and Assertions SP 800-63C-4

W3C · Web Authentication Level 3

Detailed answers for security, IT, sales, dealer and product teams.

What is product configurator SSO?

Can Configurix support OpenID Connect or SAML 2.0?

Can Configurix integrate with Microsoft Entra ID, Okta or another identity provider?

What is the difference between OpenID Connect, OAuth and SAML?

Does SSO replace role-based access control?

How are Configurix roles mapped from identity-provider groups?

How does SSO work for dealers and distributors?

Can customers use SSO to access saved configurations and quotes?

What is SCIM provisioning?