Inventive AI SSO/SAML requirements

Single Sign-On (SSO) with SAML is the fastest way to roll out Inventive AI across sales, proposal, and security teams without creating another set of passwords to manage. This guide outlines the concrete SSO/SAML requirements, supported identity providers, and configuration expectations so your IT and security teams can evaluate and implement Inventive cleanly.

What Inventive AI Supports for SSO/SAML

Inventive AI provides SAML 2.0–based SSO designed for enterprise environments that need tight access control around sensitive RFPs, RFIs, and security questionnaires.

At a high level:

Protocol: SAML 2.0
IdPs supported:
- Google Workspace
- Microsoft Entra ID (Azure AD) / Microsoft 365
- Okta
- Other SAML 2.0–compatible identity providers
Model: Service Provider (SP)-initiated and IdP-initiated SSO (depending on your configuration)
Security posture:
- SOC 2 Type II–aligned practices
- End-to-end encryption
- Role-based access controls (RBAC)
- Tenant isolation and zero data retention with model providers

Your identity provider remains the system of record for authentication; Inventive uses SAML assertions to establish sessions and map users into the right roles inside the platform.

Prerequisites for SSO/SAML with Inventive AI

To enable SAML SSO, you’ll need:

An enterprise subscription or contract that includes SSO
- SSO is typically available for teams that manage cross-functional access (sales, proposal, InfoSec, legal) and require centralized IT control.
A SAML 2.0–capable identity provider
- Supported and commonly used IdPs:
  - Google Workspace SAML apps
  - Microsoft Entra ID / Azure AD
  - Okta
- Any other IdP that can:
  - Issue SAML 2.0 assertions
  - Sign assertions with a certificate
  - Provide standard NameID and attribute mappings
A verified Inventive AI tenant / workspace
- Your organization must have:
  - A primary domain (e.g., yourcompany.com)
  - An owner / admin account that can coordinate SSO rollout with Inventive Support
IT / Security contact for configuration
- Someone who can:
  - Configure SAML in your IdP
  - Validate domain ownership if required
  - Approve access policies (e.g., who can login, MFA enforcement)

Required SAML Configuration Details

When you set up SAML SSO with Inventive AI, you’ll be exchanging a small set of URLs and certificates between your IdP and Inventive.

From Inventive AI to Your IdP

Inventive will provide (exact names/paths may vary by environment):

Assertion Consumer Service (ACS) URL / SSO URL
Where your IdP sends the SAML response after authentication.
Entity ID (SP Identifier)
A unique URI that identifies Inventive as the Service Provider.
NameID format expectations
- Usually: emailAddress
- The email should match the user’s email in Inventive or be mappable to it.

These details are typically shared via your onboarding documentation or directly from Inventive Support.

From Your IdP to Inventive AI

Your identity team will provide Inventive with:

IdP SSO URL (Single Sign-On Service URL)
The endpoint Inventive redirects users to for login.
IdP Entity ID
Unique identifier for your IdP in the SAML ecosystem.
X.509 certificate
Used to verify the signature on SAML assertions.
- Must be valid and not expired
- Should be included in PEM/BASE64 format
NameID format and mapping
- Typically set to user email (emailAddress)
- Must map to the primary login identifier used in Inventive

Once these are exchanged, Inventive configures your tenant to trust your IdP for authentication.

Recommended SAML Attributes and Claims

While Inventive can work with minimal attributes (primarily email), most customers get smoother role management and onboarding by passing a few standard attributes.

Commonly used attributes:

Email
- Attribute name: email, mail, or similar
- Purpose: Primary user identifier in Inventive
Full name
- given_name / firstName
- family_name / lastName
- Used for user display and collaboration features
Groups or roles (optional but recommended)
- Example: groups or roles claim containing IdP group names
- Can be used to drive role mapping (e.g., Admin, Proposal Manager, Viewer) when configured with Inventive Support

You don’t need to expose passwords or sensitive user attributes—only what’s necessary for identity, display, and role mapping.

Authentication, MFA, and Access Control Expectations

Inventive AI is designed to sit cleanly inside your existing access control stack.

MFA & Session Security

MFA enforcement is done at your IdP
- Inventive relies on your SAML IdP to enforce multi-factor authentication policies.
Inventive staff access
- Internally, Inventive enforces 2FA for staff accessing production systems and audits access regularly.
Session management
- SAML SSO sessions are established in Inventive based on a successfully validated assertion.
- Session length and re-auth triggers can be tuned in coordination with your IdP timeout settings.

Role-Based Access Controls (RBAC)

Role management in Inventive AI is designed to protect sensitive proposal and security data:

User roles
- Admins
- Standard / general users
- Other role types depending on your configuration
Scopes of control may include:
- Who can create new projects
- Who can connect new knowledge sources (e.g., Google Drive, SharePoint, Notion, Confluence, Salesforce, Slack)
- Who can manage exports and submissions

Access is “least privilege” by default: only staff responsible for maintenance and system upkeep have access to internal systems, and that access is regularly audited.

Security & Compliance Posture Around SSO

When you connect Inventive via SSO/SAML, you’re connecting into an environment built specifically for sensitive RFP and security workflows.

Key security properties:

SOC 2 Type II alignment
- Controls and processes audited for security, availability, and confidentiality.
End-to-end encryption
- Data encrypted in transit (TLS) and at rest.
Role-based access controls and SSO (SAML)
- Access governed by your identity provider and Inventive’s internal roles.
Tenant isolation
- Your workspace is logically separated from other customers.
Zero Data Retention (ZDR) with model providers
- When Inventive calls models (e.g., OpenAI, Anthropic), providers retain no data, adding an extra layer of protection for your RFPs, SecQs, and internal documents.

For InfoSec and procurement teams, this means SAML SSO is one part of a larger, audited control surface—rather than an isolated feature bolted on afterward.

Typical SSO/SAML Implementation Flow

Most customers complete SAML SSO rollout in a few steps:

Align on scope and IdP
- Confirm your IdP (Google, Microsoft, Okta, or another SAML provider).
- Confirm which user groups should have access at launch (e.g., proposal team, sales engineers, InfoSec).
Exchange configuration details
- Inventive shares ACS URL, SP Entity ID, and expected NameID format.
- Your IT team shares IdP SSO URL, IdP Entity ID, and X.509 certificate.
Create Inventive AI SAML application in your IdP
- Configure:
  - SAML 2.0 settings
  - NameID (email)
  - Attributes (email, name, groups if used)
- Assign groups/users to the app.
Configure and test in a staging/limited rollout
- Inventive enables SSO for your tenant in a controlled mode.
- A small group of users tests:
  - SP-initiated login from Inventive
  - IdP-initiated login from your IdP app (if you choose to support it)
- Validate:
  - Proper role assignment
  - Correct display of names and emails
  - Access to expected projects and knowledge sources
Enforce SSO (optional)
- Once validated, you can work with Inventive to:
  - Require SSO for your domain
  - Restrict or disable password-based login, depending on your security posture
Scale to the broader org
- Add more groups (e.g., all AEs, SEs, proposal coordinators).
- Tune roles and permissions as needed.

Frequently Asked Questions About SSO/SAML Requirements

Do we have to use SSO/SAML with Inventive AI?

No. Smaller teams sometimes start with email/password or other basic auth. However, for any organization managing sensitive RFPs, security questionnaires, or regulated data, SSO with SAML is strongly recommended for:

Centralized user lifecycle management (joiners/movers/leavers)
MFA enforcement
Alignment with internal security and audit requirements

Can we restrict Inventive access to specific groups via SSO?

Yes. Group-based access control is typically handled in your IdP:

Assign only specific groups (e.g., “Proposal Team,” “InfoSec,” “Sales Engineering”) to the Inventive SAML app.
Optionally pass group attributes in the SAML assertion to help drive role mapping in Inventive.

How does SSO interact with Inventive’s internal security controls?

SSO governs who can enter the platform. Inside Inventive, RBAC governs what they can do:

SSO ensures the user is authenticated and belongs to your organization.
Inventive roles and permissions determine access to:
- Projects
- Knowledge sources (e.g., Google Drive, SharePoint, Notion, Confluence, Salesforce, Slack)
- Admin settings, exports, and integrations

What happens if our SAML certificate rotates or expires?

When your IdP certificate changes:

You’ll need to update the X.509 certificate shared with Inventive.
Coordinate with Inventive Support to schedule a cutover window if necessary.
This ensures SAML assertions remain valid and SSO continues uninterrupted.

Is there any data stored in the IdP as part of this integration?

No. Your IdP remains the source of identity and authentication. Inventive consumes SAML assertions and does not write data back into your IdP.

How SSO/SAML Fits Into Inventive’s RFP & SecQ Workflow

From a workflow perspective, SSO is the front door to a tightly controlled environment where your teams:

Upload RFPs, RFIs, or security questionnaires (Word, Excel, PDF).
Let the AI parse and structure the questions into a project workspace.
Connect the Unified Knowledge Hub
- Google Drive, SharePoint, Notion, Confluence
- Salesforce, Slack, Jira
- Websites, past RFPs, legacy spreadsheets
Generate context-aware drafts with the AI RFP Contextual Engine.
Review, verify, and refine
- Sentence-level citations and confidence ratings for every answer
- Gap-flagging instead of hallucinations
- Conflict detection across responses
Export to submission-ready formats (Word, Excel, PDF).

SSO ensures the right people can do this work quickly—without compromising access control or compliance expectations.

Next Step

If you’re ready to review SSO/SAML requirements in the context of your specific IdP and security policies, we’ll walk your IT and security teams through the exact configuration for your environment.

Get Started