Authentication and SSO integration patterns

Enterprise sales platforms operate inside identity-managed environments. The customer expects to provision users from their identity provider (IdP), apply MFA centrally, deprovision automatically when employees leave. MegatronLead supports this with SAML 2.0 and OIDC.

This is the practical integration guide.

What the integration achieves

When configured, the workflow is:

• A new employee joins the customer's sales team.
• IT provisions the user in the IdP (Microsoft Entra ID, Okta, Google Workspace, Auth0) and assigns them to relevant groups.
• The user navigates to MegatronLead. They are redirected to the IdP.
• The user authenticates with the IdP (password, MFA, conditional access policies).
• The IdP returns a signed assertion to MegatronLead.
• MegatronLead reads the assertion, maps claims to a user record (creating one if first-time login), assigns roles and market scopes from group claims, and grants access.

The customer's user-management workflow happens entirely in the IdP. Roles and scopes are mapped from groups. Deprovisioning the user in the IdP automatically deprovisions them in MegatronLead.

SAML 2.0 configuration

For SAML 2.0:

1. In MegatronLead admin: initiate SAML configuration. Download the Service Provider (SP) metadata XML.
2. In your IdP: create a new SAML application. Upload the SP metadata or paste the ACS URL and Entity ID manually.
3. In your IdP: configure attribute statements. Required: NameID (user's email), groups claim (the group memberships that map to MegatronLead roles).
4. In your IdP: download the IdP metadata XML.
5. In MegatronLead admin: upload the IdP metadata. Save.

The configuration is bidirectional: MegatronLead trusts assertions signed by the IdP's signing certificate; the IdP trusts requests signed by MegatronLead's.

Test with a non-production user first. Then enable for the broader org.

OIDC configuration

For OIDC:

1. In your IdP: create a new OIDC client. Get the client ID, client secret, and the IdP's discovery URL (typically /.well-known/openid-configuration).
2. In MegatronLead admin: create an OIDC connection. Paste the discovery URL, client ID, and client secret.
3. Configure scopes. At minimum: openid, profile, email. For group-based role mapping: groups (or the equivalent scope your IdP uses for group claims).

OIDC is generally faster to configure than SAML and works well with cloud-native IdPs.

Just-in-time provisioning

JIT provisioning means MegatronLead creates user records automatically on first login, based on the IdP assertion.

The behavior:

• First-time user authenticates via the IdP.
• MegatronLead receives the assertion with email, name, and group claims.
• MegatronLead creates a user record with those attributes.
• MegatronLead maps group claims to roles and market scopes per the configured mapping.
• The user lands in MegatronLead with the right authorization, no admin pre-provisioning required.

For organizations with high user churn (new hires, role changes), JIT provisioning eliminates a class of admin work.

For organizations that prefer explicit provisioning, JIT can be disabled. In that case, admins create user records before users can log in.

Group-to-role mapping

The mapping from IdP groups to MegatronLead roles is the configuration that determines authorization.

The mapping is:

• IdP group "MegatronLead-Admins" -> MegatronLead role "super_administrator".
• IdP group "MegatronLead-RegionalManagers-India" -> role "regional_manager" + market scope "India".
• IdP group "MegatronLead-Sales-UAE-Inside" -> role "sales_representative" + market scope "UAE" + team scope "UAE-inside-sales".

The mapping table is configured in MegatronLead admin. Adding a new group mapping is a configuration change, not a code change.

The principle of least privilege applies: a user gets the union of scopes from all their group memberships. A user in only "Sales-India" gets India scope; one in both "Sales-India" and "Sales-UAE" gets both.

MFA inheritance

MegatronLead does not implement its own MFA when SSO is configured. The MFA happens in the IdP.

This is the right design. Your IdP enforces conditional access policies (MFA required for high-risk sessions, geographic restrictions, device compliance). MegatronLead trusts the IdP's assertion that the user authenticated with MFA.

If your IdP supports step-up MFA for sensitive operations, MegatronLead can request step-up via the IdP for destructive admin actions.

Session lifetime

MegatronLead sessions are short-lived (15 minutes by default). Beyond that, the user re-validates with the IdP.

The IdP's session may be longer; if so, the re-validation is silent (the IdP returns a fresh assertion without prompting the user). If the IdP's session has also expired, the user authenticates again.

This is the standard pattern. Short session lifetimes limit the blast radius of token theft.

Audit trail

Every authentication event is in the audit log:

• Successful login with IdP assertion details.
• Failed login attempts (without sensitive details).
• Session termination.
• Group changes that reflected in MegatronLead role changes.

This is part of the compliance posture. Auditors reviewing access control want to see the authentication chain.

Common patterns

Three patterns worth knowing:

Pattern 1: Microsoft Entra ID + groups. Most common in enterprise. Groups in Entra map to MegatronLead roles. Conditional Access enforces MFA.

Pattern 2: Okta + SCIM provisioning (optional). SCIM is the protocol for pushing user creation/deletion from the IdP to the application. Some MegatronLead deployments use SCIM in addition to JIT for stricter user-lifecycle management.

Pattern 3: Multiple IdPs. Organizations with multiple subsidiaries may have separate IdPs. MegatronLead supports multiple SSO connections; each maps its own groups to roles and scopes.

What to verify

After configuration:

• Test login with a non-admin user.
• Verify the user's role and scope are correct.
• Test login from outside the office to verify MFA is enforced.
• Verify deprovisioning: remove the user in the IdP, attempt login, expect denial.

These four checks confirm the integration is operationally sound.

For the broader security posture, see security and compliance.