An organization corresponds to a corporate customer of yours. If you sold your product to Apple, Nvidia, and Amazon, you’d have three organizations in SSOReady: one each for Apple, Nvidia, and Amazon.

Organizations belong to exactly one environment. You can have any number of organizations in an environment.

Within organizations, you can have any number of SAML connections and SCIM directories.

Properties

Organization ID

Every organization has an ID starting with org_..., for example:

org_ac4vpckpze4ugjm70lzkmtwd2

Organization IDs are universally unique.

Organization External ID

If you’re selling multi-tenant B2B software, you probably already have a concept that closely matches an SSOReady organization — usually, this is something named a “team”, “workspace”, “company”, or something similar.

For your convenience, SSOReady lets you assign organizations with an organizationExternalId. These external IDs are optional. They must be unique within an environment.

These external IDs are a convenience feature: they save you from having to add some sort of ssoready_organization_id property on your existing equivalent of an SSOReady organization. Instead, you can call SSOReady using the ID you have naturally on-hand as the organizationExternalId when using SAML or SCIM endpoints. When onboarding new enterprise customers, you set your ID for that customer as the External ID on the SSOReady organization.

Domains

Every organization must include a whitelist of domains. If you expect Apple’s employees to log into your product with @apple.com and @shazam.com email addresses, then set apple.com and shazam.com as the domains for Apple’s organization in SSOReady.

This whitelist of domains is used in two places:

• When processing SAML logins, the SAML user’s email address must be from the whitelist.
• When provisioning SCIM users, the SCIM user’s email address must be from the whitelist.

In both cases, this is a security mechanism. Although the SAML and SCIM protocols ensure the authenticity of messages between the service provider (your application, with SSOReady acting on your behalf) and the identity provider (your customer’s Okta/Google/Entra/etc.), neither protocol directly handles the possibility of a malicious customer (or their disgruntled IT admin) attempting to log in as a competitor within your product.

To shield you against such cross-tenant attacks, SSOReady requires a first line of defense by whitelisting the domains you expect a customer to be using. You are free to add additional controls, but for most applications this built-in domain whitelisting is sufficient.

SAML Connections

Organizations have any number of SAML connections that belong to the organization. You can create SAML connections in one of three ways:

1. By hand, using the SSOReady web application
2. By having your customers create them, using customer self-serve setup
3. Programmatically, using the Management API

SCIM Directories

Organizations have any number of SCIM directories that belong to the organization. You can create SCIM directories in one of three ways:

1. By hand, using the SSOReady web application
2. By having your customers create them, using customer self-serve setup
3. Programmatically, using the Management API

Customer Self-Serve Setup

Once you’ve created an organization, you can give your customers one-time self-serve setup links. Customers can visit these links to configure their SAML connections and SCIM directories.

You can learn more about customer self-serve setup here.