Skip to main content
Single sign-on lets your members sign in to Share Of Model with your own identity provider (IdP) instead of a Share Of Model password. You configure it yourself, from the organisation settings, without opening a ticket. Share Of Model acts as the service provider (SP). Your IdP authenticates the user and asserts their identity; Share Of Model resolves that identity to a member of your organisation and issues its own session.

SAML 2.0

Okta, Microsoft Entra ID, Google Workspace, OneLogin and most enterprise identity providers.

OpenID Connect

Modern OAuth 2.0 based sign-in. Use it when your identity provider does not offer SAML.

​
Prerequisites

  • You are an Organization Owner — see User Roles & Workspaces.
  • Single sign-on is enabled for your organisation. It is rolled out per organisation; contact your account manager if you do not see the tab.
  • You can administer your identity provider (create an application, read its metadata).
  • You own the email domains your members sign in with. Personal email domains (Gmail, Outlook, and similar) cannot be used.
One identity provider per organisation. Domains are verified by the Share Of Model team before single sign-on can be activated — see Email domains.

​
Where to find it

Open Settings from your profile icon, select your organisation, then open the Single sign-on tab. It has two sections:

​
Configuration statuses

Your configuration moves through four statuses, shown at the top of the Sign-in section.
Any change to an identity provider field sends the configuration back to Draft. Re-run the connection test and activate it again.

​
Set up single sign-on

The Set up single sign-on wizard walks through six steps. You can leave and resume at any point — nothing is applied to your members until you reach Activate.
1

Choose a protocol

Pick SAML 2.0 or OpenID Connect. Use SAML unless your identity provider does not offer it.
2

Configure the identity provider

Import the SAML metadata published by your identity provider, either by Metadata URL or by pasting the XML.Share Of Model parses the document and shows the detected settings before saving anything: entity ID, single sign-on URL, and the fingerprint and expiry of each signing certificate. It also detects the provider (Okta, Entra ID, Google) and pre-fills the matching attribute mapping.Open Advanced to adjust the attribute mapping — see Attribute mapping.
3

Copy the service provider values

This step exposes the values your identity provider needs. Each field has a copy button, and the signing certificate can be downloaded.The {slug} is derived from your organisation name and never changes. Always copy the exact values from the interface rather than typing them.
4

Add your email domains

Add every domain your members sign in with, for example acme.com. Each domain shows as Pending until the Share Of Model team verifies it, then as Verified.See Email domains for what verification gates.
5

Test the connection

Click Test connection. A secondary window opens on your identity provider and you authenticate as yourself.
  • Success — the window closes and the step lists every attribute received: email, first name, last name and groups. Check that the email matches the member’s Share Of Model address.
  • Failure — the step shows a sanitised error. Fix the identity provider settings and test again.
A test never issues a session and never creates a member. It is safe to run as often as needed, and it works before your domains are verified.
6

Activate

Review the summary — protocol, identity provider, domains — then click Activate single sign-on. Members can now sign in through your identity provider, while passwords and Google sign-in keep working.To make it the only way in, turn on Require single sign-on.

​
Identity provider guides

The same guides are available in the interface, in the Service provider step.
1

Create a SAML app integration

In the Okta admin console open Applications, choose Create App Integration and select SAML 2.0.
2

Paste the service provider values

Use the ACS URL as Single sign-on URL and the entity ID as Audience URI. Set the Name ID format to EmailAddress.
3

Add attribute statements

Map email, firstName and lastName. Add a group attribute statement if you want to use group mappings.
4

Import the Okta metadata

From the Sign On tab copy the metadata URL and import it in the identity provider step.
5

Enable the Share Of Model tile

Assign the application to your users, and set the Default RelayState to the Share Of Model path you want to open after sign-in.

​
Attribute mapping

Share Of Model needs an email for every sign-in, and optionally a first name, last name and group list. Defaults are pre-filled from the detected provider and can be overridden under Advanced.
The email is the only identifier Share Of Model trusts. For OpenID Connect the email claim is required and an email_verified claim set to false fails the sign-in — sub, upn and preferred_username are never used as fallbacks.

​
Email domains

A domain can belong to only one single sign-on configuration across the whole platform, and personal email domains are rejected. Domain verification is performed by the Share Of Model team. It gates two things:
  • Activation of the configuration.
  • Requiring single sign-on for those domains.
Testing does not require verification, since a test issues no session.
Changing the domains of an active configuration resets verification, turns Require single sign-on off and sends the status back to Tested. Have the new domains verified, then activate again.

​
Require single sign-on

The Require single sign-on switch on the status card forces members of your verified domains through your identity provider. Password and Google sign-in start returning an error that redirects them to your provider. The switch stays disabled until the configuration is Active and the domains are Verified. Two exemptions prevent the requirement from locking out accounts that are not yours:
  • users who also belong to another organisation,
  • Share Of Model staff.
If your identity provider becomes unavailable while single sign-on is required, your members cannot sign in. Contact support — the Share Of Model team can disable the requirement for your organisation.

​
Provisioning and roles

The Provisioning card controls what happens to a user who signs in successfully but is not yet a member. Just-in-time provisioning still respects your organisation’s user quota; sign-in fails with quota_exceeded once it is reached.

​
Group mappings

Map a group sent by your identity provider to a Share Of Model role. Each mapping targets either the organisation or one workspace.
1

Send groups from your identity provider

Add the group attribute statement (Okta) or groups claim (Entra ID), and make sure the Groups attribute in the advanced mapping matches it.
2

Add a mapping

In the Provisioning card click the add button, enter the identity provider group name, choose Organization or Workspace, pick the workspace if needed, then pick the mapped role.
Groups sent without a mapping are recorded and ignored. A member who no longer matches any organisation-level mapping falls back to the default organisation role — the membership itself is not removed. Removing access is the job of SCIM deprovisioning or of an Organization Owner.

​
The sign-in experience

On the sign-in page, the member clicks Continue with Email or SSO and enters their email. If the domain is configured, a Continue with SSO button appears; if single sign-on is required, it is the only option offered.Members who last signed in with single sign-on land directly on a Continue with SSO screen, with Choose another method revealing the other options.

​
Maintenance

Service provider certificate

Generated by Share Of Model, valid for three years. Rotate the service provider certificate in the Danger zone issues a new key pair — upload the new certificate to your identity provider straight away.

Identity provider certificate

Several signing certificates can be configured at once, so you can roll over on your side. Re-import the metadata after any change.

​
Disable single sign-on

Disable single sign-on in the Danger zone sets the status to Disabled and turns off the requirement. Members sign in with a password or Google again. The configuration is kept, so you can activate it later without redoing the setup.

​
Troubleshooting

Failed sign-ins come back to the sign-in page with an error code. The same codes appear in the connection test.

​
Limits

  • One identity provider per organisation.
  • Encrypted SAML assertions are not supported — leave assertion encryption off in your identity provider.
  • No SAML Single Logout. Revoke access by deactivating the member, through SCIM or in Members.
  • Domain verification is manual, performed by the Share Of Model team.
  • Not available for Pencil organisations.

​
What’s next

SCIM Provisioning

Sync members and groups automatically from your directory.

User Roles & Workspaces

The roles you can map groups to.

Security & Compliance

How identity and access are secured.

API Keys

Programmatic access, separate from single sign-on.