Skip to content

Onboarding Enterprise SSO

This guide is for partners who already have an identity provider (IdP) and want their team to sign in to Vellocity with it. Setup is a short, two-sided exchange: your IT team registers a SAML application in your IdP, and the Vellocity team scopes a federation to your organization.

Admin-assisted today

Federation is currently configured with the Vellocity team — you don't need a Vellocity admin login to set it up. Self-service federation is on the roadmap.

The two-sided flow

Your IT team:

  1. Create a SAML 2.0 application in your IdP.
  2. Configure it with the ACS URL and SAML audience we provide (1).
  3. Map the standard identity attributes (email, first name, last name, display name).
  4. Assign the users or groups who should have Vellocity access.
  5. Send us your IdP's metadata URL.

The Vellocity team:

  1. Create your organization — verified email domains, seat plan, and seat limit.
  2. Register your identity provider, scoped to your organization, using your metadata URL.
  3. Set your allowed email domains and enable just-in-time provisioning.
  1. We provide your unique ACS URL and SAML audience during onboarding — they identify your Vellocity federation endpoint. The placeholders below show their shape.

Once both sides are done, your users sign in with their work email → Vellocity detects the SSO domain → your IdP authenticates them → they're provisioned into your organization and granted your seat plan.

Universal values

Every IdP needs the same two values from Vellocity, plus the same attribute mapping. We give you the exact values during onboarding — don't guess them.

Field Shape Notes
ACS URL (Reply URL / Single Sign-On URL) https://<your-cognito-domain>.auth.us-east-1.amazoncognito.com/saml2/idpresponse Where your IdP posts the SAML assertion.
SAML audience (Entity ID / Audience URI) urn:amazon:cognito:sp:<your-user-pool-id> Identifies the Vellocity service provider.

Attribute mapping — Vellocity reads these SAML claims. The email claim is required for provisioning:

SAML claim Maps to Required
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress User email ✅ Yes
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname First name Recommended
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname Last name Recommended
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name Display name Recommended

Per-IdP walkthroughs

Entra ID (formerly Azure AD) is available on every Microsoft 365 tenant, including the free tier.

  1. In the Microsoft Entra admin center, go to Identity → Applications → Enterprise applications → New application → Create your own application.
  2. Name it (e.g. Vellocity), choose Integrate any other application you don't find in the gallery (Non-gallery), and create it.
  3. Open the app → Single sign-on → SAML.
  4. Edit Basic SAML Configuration:
    • Identifier (Entity ID) = the SAML audience we provide.
    • Reply URL (Assertion Consumer Service URL) = the ACS URL we provide.
  5. Under Attributes & Claims, confirm the claims include the user's email address, given name, surname, and name. The default Entra claim set already uses the schemas.xmlsoap.org URIs above; make sure the unique user identifier / email carries the user's email.
  6. Under Users and groups, assign the people or groups who should have Vellocity access.
  7. In SAML Certificates, copy the App Federation Metadata Url.
  8. Send that metadata URL to the Vellocity team.
  1. In the Okta Admin Console, go to Applications → Applications → Create App Integration → SAML 2.0.
  2. Give the app a name and (optionally) logo, then continue.
  3. Configure SAML:
    • Single sign-on URL = the ACS URL we provide. Leave Use this for Recipient/Destination checked.
    • Audience URI (SP Entity ID) = the SAML audience we provide.
    • Name ID format: EmailAddress. Application username: Email.
  4. Add Attribute Statements mapping the user's email, first name, last name, and display name to the four claim URIs in the table above.
  5. Finish the wizard, then assign the app to the appropriate people or groups.
  6. On the app's Sign On tab, find Identity Provider metadata and copy its URL.
  7. Send that metadata URL to the Vellocity team.

IAM Identity Center custom SAML apps are console-only — they can't be created through the AWS API — so every step here is in the AWS console.

  1. In the IAM Identity Center console, go to Applications → Add application → I have an application I want to set up → Application type: SAML 2.0 → Next.
  2. Give it a Display name (e.g. Vellocity).
  3. Under Application metadata, choose to enter values manually:
    • Application ACS URL = the ACS URL we provide.
    • Application SAML audience = the SAML audience we provide.
    • Submit.

  4. On the application page, choose Actions → Edit attribute mappings and set:

    Attribute Maps to Format
    Subject ${user:email} emailAddress
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress ${user:email} unspecified
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname ${user:givenName} unspecified
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname ${user:familyName} unspecified
    http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name ${user:name} unspecified

  5. Choose Assign users and add the people who should have Vellocity access.

  6. Copy the IAM Identity Center SAML metadata file URL from the application page.
  7. Send that metadata URL to the Vellocity team.

OIDC instead of SAML

If your IdP is easier to federate over OpenID Connect (for example Google Workspace or a custom OIDC issuer), we support that too. Instead of a metadata URL, you'll provide your issuer URL, client ID, and client secret, and register the same email/name attribute mapping. Ask your Vellocity contact for the OIDC onboarding values.

What happens after setup

Once your provider is registered and scoped to your organization:

  1. A teammate goes to the Vellocity login page and clicks Sign in with Enterprise SSO (or types their work email, which is detected as an SSO domain).
  2. They're redirected to your IdP and authenticate there.
  3. On return, Vellocity provisions their account if it's their first sign-in, assigns them to your organization by email domain, and grants your organization's seat plan.

If you'd like to require SSO for your domains (so work accounts can't sign in with a password), see SSO enforcement.

Test with one user first

Assign the app to a single pilot user in your IdP and confirm the round-trip before rolling it out to everyone. If the pilot user's email domain matches a verified domain on your organization, they'll be provisioned and seated automatically.