SSO & Authentication

SSO single sign-on ContextQA configuration — set up SAML SSO with Okta, Azure AD, or Google Workspace, and manage authentication for the entire organization.

Who is this for? Engineering Managers, IT Administrators, and VPs of Engineering configuring team access, authentication, and enterprise security controls.

Single sign-on (SSO) in ContextQA: An authentication configuration where ContextQA delegates user authentication to an external identity provider (IdP) via SAML 2.0, allowing team members to log in with their existing corporate credentials without maintaining a separate ContextQA password.

Managing separate credentials for every SaaS tool creates security risk and support burden. ContextQA supports three authentication modes — form login, Google OAuth, and SAML SSO — giving organizations the flexibility to use the authentication model that matches their security policy. This page covers all three modes and provides setup guidance for SAML SSO with the most common identity providers.

Authentication options in ContextQA

Mode	Description	Best for
Form Login	Email address and password stored in ContextQA	Small teams, development environments, service accounts
Google OAuth	Sign in with an existing Google account via OAuth 2.0	Teams using Google Workspace as their primary identity
SAML SSO	Delegate authentication to any SAML 2.0-compatible identity provider	Enterprise organizations with centralized identity management (Okta, Azure AD, etc.)

All three modes can coexist in a single organization during a migration period. Once SAML SSO is configured and tested, most organizations disable form login and Google OAuth to enforce IdP-managed authentication.

Where to configure authentication

Authentication configuration lives at:

Settings → Auth Configuration

The route is /settings/auth. This section is visible only to users with the Organization Admin role.

The Auth Configuration page shows which authentication methods are currently enabled and provides configuration panels for each mode.

Configuring SAML SSO

SAML SSO requires coordination between ContextQA (the Service Provider, or SP) and your identity provider (the IdP). The general process is:

Step 1: Gather the ContextQA SP metadata

1. Navigate to Settings → Auth Configuration.

2. In the SAML SSO section, click View SP Metadata or download the metadata XML file.

3. Note the following values from the metadata (you will need these when configuring your IdP):

   • Entity ID (SP): Identifies ContextQA to your IdP

   • Assertion Consumer Service (ACS) URL: The URL your IdP sends the SAML assertion to after authentication

   • Single Logout Service URL (if your IdP supports SLO)

Step 2: Configure ContextQA in your IdP

The exact steps vary by IdP. The common fields are:

• SP Entity ID: Use the value from ContextQA's SP metadata

• ACS URL (Reply URL): Use the value from ContextQA's SP metadata

• Name ID format: emailAddress (ContextQA uses email as the user identifier)

• Attribute mappings:

  • Email → email or http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

  • First name → firstName or equivalent

  • Last name → lastName or equivalent

Step 3: Enter IdP metadata in ContextQA

1. In your IdP, locate the SAML metadata URL (also called the federation metadata URL or IdP metadata URL). Alternatively, download the IdP metadata XML.

2. Return to Settings → Auth Configuration → SAML SSO.

3. Paste the IdP Metadata URL into the designated field, or upload the metadata XML.

4. Click Save.

Step 4: Test the SSO login

1. Open a new private/incognito browser window.

2. Navigate to the ContextQA login page.

3. Click Sign in with SSO.

4. Enter your organization's email domain (or use the SSO login URL provided by ContextQA).

5. Complete authentication in your IdP.

6. Verify that you are redirected back to ContextQA and logged in successfully.

Do not disable form login until SSO is confirmed working for at least one non-admin user.

Supported identity providers

ContextQA supports any SAML 2.0-compliant identity provider. The following providers have been validated:

Identity Provider	Notes
Okta	Use the SAML 2.0 app integration template. Set Name ID to email format.
Azure Active Directory (Azure AD / Entra ID)	Use "Enterprise Application" → "Non-gallery application" → SAML setup. Set the Unique User Identifier claim to user.mail.
Google Workspace	Use Google Admin Console → Apps → Web and mobile apps → Add custom SAML app.
Generic SAML 2.0	Any IdP that supports SAML 2.0 SP-initiated flow with email as the Name ID will work.
OneLogin	Add ContextQA as a SAML connector application.

For IdP-specific step-by-step guides, refer to your identity provider's documentation for adding a custom SAML application.

What happens to existing users when SSO is enabled

When SAML SSO is enabled:

• Users who were already logged in remain logged in until their session expires. On next login, they will see the SSO option.

• Users with existing form login credentials can still log in via form login until form login is explicitly disabled in Auth Configuration.

• New users provisioned through the IdP are created in ContextQA on first login if just-in-time (JIT) provisioning is enabled. They receive the default role configured in Settings → User Management.

• Users not in the IdP (for example, service accounts with form login) will be unable to authenticate if form login is disabled. Always create service accounts before disabling form login.

Service account best practices for MCP server connections

The ContextQA MCP server authenticates via the standard credential mechanism. When configuring MCP server connections:

Use a dedicated service account, not a personal SSO account. Personal SSO accounts are subject to IdP session expiry, MFA prompts, and deprovisioning when employees leave. A service account with form login credentials provides stable, predictable authentication for automated systems.

Create the service account before enabling SSO-only mode. If you plan to disable form login after enabling SAML SSO, create the service account first and verify it can authenticate via form login. Then configure SSO for human users while the service account continues to use form login.

Assign the minimum required role. The MCP server requires sufficient permissions to execute tests and read results. The QA Engineer role is typically appropriate. Do not assign Organization Admin to a service account unless admin-level MCP operations are explicitly needed.

Rotate service account credentials periodically. Set a calendar reminder to rotate the service account password every 90 days (or per your organization's credential rotation policy). Update the MCP server configuration immediately after rotation.

Store credentials in a secrets manager. Do not hardcode the service account email and password in configuration files or Jenkinsfiles. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or equivalent) and inject the credentials at runtime.

User management after SSO configuration

After SSO is configured, user management still happens in Settings → User Management (route: /settings/user-managemant). The SSO configuration controls how users authenticate, but role assignments, team memberships, and feature access are managed within ContextQA regardless of authentication method.

Users provisioned via JIT SSO receive the default role. To change a user's role, navigate to Settings → User Management, find the user, and update their role assignment.

Frequently Asked Questions

Can I use both SAML SSO and Google OAuth at the same time?

Yes. Multiple authentication methods can be active simultaneously. This is useful during migrations or when some users (such as service accounts) need form login while human users authenticate via SAML. Go to Settings → Auth Configuration and enable or disable each method independently.

What happens if my IdP is unavailable?

If SAML SSO is the only enabled authentication method and the IdP is unreachable, users cannot log in. To prevent a total lockout, always maintain at least one form login admin account or keep form login enabled as a fallback. Review your IdP's SLA and uptime guarantees before disabling form login entirely.

Does ContextQA support SCIM for automated user provisioning?

SCIM support availability depends on your subscription tier. Contact ContextQA support for current SCIM capability status and configuration guidance.

How do I get the ContextQA login URL for SSO users to bookmark?

The ContextQA login page supports SSO initiation. The URL is the standard portal URL. Users click Sign in with SSO and enter their email to be redirected to the IdP. Some IdPs also support IdP-initiated SSO, which allows users to click the ContextQA tile in the IdP portal to authenticate directly.

Related

• Roles and permissions

• Team management

• MCP server configuration

• User management settings

Enterprise-ready: SSO, RBAC, and centralized access management. Book an Enterprise Demo → — Get a walkthrough of enterprise controls, SSO setup, and compliance features for your organization.

**Enterprise-ready: SSO, RBAC, and centralized access management.**