Single sign-on (SSO)
Let users authenticate into Rescale with your corporate credentials. SSO applies to the whole organization. Once configured, every workspace authenticates through the same IdP; there is no per-workspace or per-department SSO.
The live documentation still carries a "Single Sign-On – Legacy" page. That configuration is deprecated, this page covers the current SAML setup. If you're on the legacy integration, contact your Rescale representative about migrating; don't follow the old instructions for a new setup.
Single sign-on (SSO) lets your users authenticate into Rescale with the same credentials they use for the rest of your corporate identity stack. This page walks organization administrators through configuring SSO with Okta, Google Workspace, or any SAML 2.0 identity provider (IdP), and covers the access policies, attribute mapping, and login auditing that come with it. SSO applies at the Rescale organization level, so once configured, every workspace in the organization authenticates through the same IdP.
Before you start
You must be an Organization Administrator to configure SSO. Configuration is done from the Rescale Organization Admin portal under Security > Single Sign-On. You also need administrative access to your IdP (Okta, Google Workspace, Microsoft Entra, or another SAML 2.0 provider) so that you can create and configure a new application.
Existing Rescale users keep access after you enable SSO, as long as their Rescale email matches the email released by the IdP. Existing API tokens continue to work. Rescale does not currently support merging two accounts that share the same email.
Configuring SSO in Rescale
- Open the Organization Administration portal and go to Security.
- Click the Single Sign-On tab, then click Configure Single Sign-On. If SSO was configured previously, click the gear icon to edit the existing setup.
- Choose Metadata exchange (recommended) or Manual configuration. Metadata exchange imports the IdP settings from a URL your IdP exposes, which eliminates most field-by-field copying.
- Import the Rescale metadata into your IdP using the link Rescale provides on this screen. If your IdP does not accept a metadata URL, click Show Details to view the individual values (Entity ID, Assertion Consumer Service, Sign-On URL, and Single Logout Service) that you need to paste into the IdP.
- Paste the IdP metadata URL into the Identity Provider's Metadata field and click Verify Settings.
- Continue to Attributes and map the IdP attributes that Rescale uses to build user profiles. Email address is required. Full name and username are optional, and username only applies if your organization needs a non-email identifier.
- (Recommended) Run a test login in a separate tab. A successful test login both confirms that the IdP and Rescale can communicate and surfaces the attribute names your IdP is releasing, which makes attribute mapping straightforward.
- Continue to Policies, set your access policy (see below), and save.
Rescale service provider URLs by region
Use the service provider URLs for the region your Rescale organization is hosted in:
If you are not sure which region your organization uses, check with your Rescale Solutions Architect or Customer Success contact before pasting these values into the IdP.
All four values have to come from the same region. A common failure is copying a Microsoft or Okta tutorial that illustrates the US platform while your organization is hosted in Europe or Japan. The setup then fails at the callback with an error that doesn't obviously point at the region.
Setting up Okta
- Sign in to the Okta admin console.
- Go to Applications and click Create App Integration.
- Choose SAML 2.0 and click Next.
- Name the application Rescale Platform. You can optionally upload the Rescale logo.
- In the SAML settings, enter the Sign-On URL and Audience URI for your region, taken from the service provider URLs above.
- Set Name ID format to
EmailAddressand Application username to Okta username. - In Attribute statements, release the attributes Rescale needs. At minimum, include email.
- On the final screen, select I'm an Okta customer and click Finish.
- Open the Sign On tab of your new Okta application and copy the Metadata URL.
- Return to Rescale and paste the Okta metadata URL into the SSO setup form.
Setting up Google Workspace
Google Workspace does not publish an IdP metadata URL, so you configure SSO with Rescale using Manual configuration.
- Sign in to the Google Admin console and go to Apps > Web and mobile apps.
- Click Add app > Add custom SAML app.
- Name the application Rescale Platform. You can optionally upload the Rescale logo.
- On the Google Identity Provider details screen, either download the IdP metadata or copy the SSO URL, Entity ID, and Certificate. You will paste these into Rescale.
- On the Service provider details screen, enter the service provider URLs for your region, from the list above. Set Name ID format to
EMAILand Name ID to Primary email. - On the Attribute mapping screen, map the attribute name Rescale expects to the Google field that holds the email address.
- Finish by granting access to the users or groups who should be able to sign in with the application.
- In Rescale, open the SSO setup form and select Manual configuration. Paste the Google Entity ID, Single Sign-On URL, and Certificate into the matching fields and save.
To sign in from Google, open the Google app launcher (the nine-dots icon), find the Rescale Platform tile, and click it.
Setting up a generic SAML 2.0 IdP
For Microsoft Entra (Azure AD) or any other SAML 2.0 IdP, use Metadata exchange whenever the IdP exposes a metadata URL. If your IdP requires manual entry, use the fields shown in the Show Details panel on the Rescale SSO form. Rescale requires the IdP to release at least the user's email address.
If you follow a Microsoft tutorial that hardcodes platform.rescale.com, swap in the correct regional domain (for example eu.rescale.com or platform.rescale.jp) everywhere it appears.
Choosing a sign-in and access policy
In Advanced Settings you can configure two policies that control who can reach Rescale through SSO:
- Sign-on options. Allow sign-in with SSO only, or with both SSO and email and password.
- Access policy. Choose Allow anyone from your organization to let any employee authenticated by your IdP create a Rescale account, or Only allow invited users to sign on to require that users first be invited through the workspace admin before they can sign in.
SSO overrides any existing Rescale password policy. For onboarding, invite new users through the Workspace Admin. To offboard a user, remove their access in the Members section of the workspace and disable them in your IdP.
Monitoring sign-in activity
After SSO is configured, the Organization Admin > Security > Single Sign-On page carries a Recent Sign in Successes and Failures table below the settings, with Email, Workspace, Date/Time, and Status columns. It's the first place to look when someone can't get in:
- A green check means the login succeeded.
- A red cross means the login failed. Expand the row for the failure reason.
- A yellow line means the login was incomplete. The user was redirected to the IdP but never came back. This usually means the user closed the tab; it is not always a problem.
Click any entry to open a chronological log for that user, which is useful when debugging attribute or certificate issues. Audit logs for login attempts are also available from the Security section.
Frequently asked questions
Does SSO apply to sub-organizations or only some workspaces? SSO applies to every workspace in the Rescale organization. You cannot enable it selectively per workspace.
Can I still use MFA with SSO? Yes. Your IdP's MFA protects the initial sign-in, and you can still require Rescale-side MFA as a second layer. See MFA.
Does SSO affect API tokens? No. Existing API tokens keep working after SSO is enabled.
Can Rescale map IdP groups to Rescale groups or projects? Not at this time.
Related
- Multi-factor authentication — layering Rescale MFA on top of your IdP's
- Access restrictions — limiting which IPs can reach the platform
- Invite and manage users — how the access policy changes whether invitations are needed
- Password policy — overridden once SSO is enabled