📘

Please contact your OneSchema representative for more info on enabling SSO for your organization.

OneSchema supports single-sign-on (SSO) and Security Assertion Markup Language (SAML) authentication to manage authentication and access to the OneSchema dashboard.

When you set up a SAML authentication method, only users in your organization's identity provider will be able to log into to the application. By default, all other authentication methods will be disabled.

All SAML SSO configurations support "Just In Time" (JIT) provisioning, which allows OneSchema to create users when they log in for the first time.

We support several identity providers including Okta, Microsoft, and Google.

App icon

Optionally, add the OneSchema icon to the application you create in your identity provider so your users can easily find OneSchema on their app dashboard (for example the Okta End-User Dashboard or Microsoft My Apps). Download the image and upload it when you configure the application, as described in the steps below.

Download icon (PNG, 215 × 215 px)

Configuring Okta SAML / SSO

1. From the Okta Admin Dashboard, click Create App Integration in the Applications tab

2. Select SAML 2.0 and continue to the General Settings form, enter the name of your application as OneSchema. Optionally, upload the OneSchema icon as the App logo.
3. In the Configure SAML form:
   1. Input the acs_url as the Single sign-on URL. This will be provided by your OneSchema representative.
   2. Input the audience_uri as the Audience URI (SP Entity ID). This will be provided by your OneSchema representative.
   3. Select EmailAddress for Name ID format
   4. In Attribute Statements create two inputs:
      Name: firstName; Name format: Basic; Value: user.firstName
      Name: lastName; Name format: Basic; Value: user.lastName

4. Save and continue, indicating that this is an internal application on the last screen. Copy the Metadata URL from the Sign On Settings tab in your newly created Okta application and share this with your OneSchema representative.

Configuring Microsoft Entra ID SAML / SSO

1. In the Microsoft Entra admin center, go to Enterprise applications and click New application, then Create your own application. Name the application OneSchema, select Integrate any other application you don't find in the gallery (Non-gallery), and click Create.
2. In the new application, open Single sign-on and select SAML.
3. Edit Basic SAML Configuration:
   1. Input the audience_uri as the Identifier (Entity ID). This will be provided by your OneSchema representative.
   2. Input the acs_url as the Reply URL (Assertion Consumer Service URL). This will be provided by your OneSchema representative.
   3. Leave the other fields blank and click Save.
4. Edit Attributes & Claims:
   1. Under Required claim, open Unique User Identifier (Name ID) and set the Source attribute to user.primaryauthoritativeemail (or user.mail). The Name ID must be the user's email address; the default user.userprincipalname is often not an email address and will prevent users from logging in.
   2. Under Additional claims, delete the preconfigured claims and add the following three claims, leaving Namespace blank:
      Name: firstName; Source attribute: user.givenname
      Name: lastName; Source attribute: user.surname
      Name: id; Source attribute: user.objectid
   3. Click Save.
5. In the SAML Certificates section, copy the App Federation Metadata Url and share this with your OneSchema representative.
6. In Properties, optionally upload the OneSchema icon as the Logo and click Save. Confirm Assignment required? is set to Yes. Then, in Users and groups, assign the users or groups who should be able to log in to OneSchema. With assignment required, Entra ID blocks sign-in for users who are not assigned to the application.

Optional: Managing roles via SSO

By default, OneSchema creates new SSO users with the Developer role, and admins manage roles on the Team page. You can instead have your identity provider manage roles: your IdP sends the user's OneSchema groups in a groups attribute, and OneSchema uses them to set the user's role every time they sign in with SSO.

📘

Contact your OneSchema representative to enable role management via SSO. Configure the groups in your identity provider first and assign users to them, then share the group names with your representative.

Groups and roles

Create one group per OneSchema role you want to use, and assign users to them. We recommend these group names. If you use different names, keep the oneschema- prefix so the Okta group filter below still includes them, and share the names with your OneSchema representative. Group names are case-sensitive.

If a user is in more than one of these groups, they get the role with the highest precedence.

Configuring Okta

In your OneSchema SAML application, open SAML Settings and, under Group Attribute Statements, add:
Name: groups; Name format: Unspecified; Filter: Starts with oneschema-

Keep Name ID format set to EmailAddress.

Configuring Microsoft Entra ID

In your OneSchema enterprise application, open Single sign-on, edit Attributes & Claims, and click Add a group claim:

1. Select Groups assigned to the application, and set Source attribute to Cloud-only group display names (or sAMAccountName for groups synced from on-premises Active Directory).
2. Under Advanced options, check Customize the name of the group claim, enter groups as the Name, and leave Namespace blank.
3. Click Save, then assign the OneSchema groups to the application in Users and groups.

How OneSchema behaves

• On every SSO sign-in, OneSchema sets the user's role from their groups. Users who don't have an account yet are created with that role.
• Users who are in none of the configured groups can't sign in.
• Roles can't be changed on the Team page; they show as managed by your identity provider. You can still invite and remove users.
• Roles are only updated when a user signs in with SSO. If your organization also allows other sign-in methods, a user who signs in another way keeps the role from their last SSO sign-in.
• SSO sessions last up to 12 hours. Changes to a user's groups take effect at their next SSO sign-in.