Skip to main content

Domain-Based SSO

Casey Birkholz
  • Updated

Overview

Learn how to set up Single Sign-On (SSO) based on your organization's domain.

SSO enables an organization's users to log in to multiple applications using a single username and password. With SSO, account and credential management is not handled by Proof but instead by your “Identity Provider” (IDP). The IDP will manage user accounts, including granting and revoking access to the Proof application.

Benefits Notes Prerequisites Configuring Testing 
🎯Primary Audience: Command Center Customers
ℹ️ SSO applies to the users within your organization. Signers cannot use SSO.

Benefits

  • Single Sign-On (SSO) is the most secure authentication method you can require for your users.
  • SSO gives you full control over user provisioning from your identity provider.
  • SSO helps with the seamless integration of Proof into your existing processes.
  • SSO requirements apply across all users with your domain.
💡 SSO also offers “just-in-time provisioning”. Provision a user within your identity provider, and they will be able to easily access the Proof platform with the appropriate role. This streamlines onboarding organization members!

Notes

For the purposes of setting up your SSO:

  • Proof is called the “Service Provider” (SP).
  • The entity you work with to create, maintain, and manage your identity information is called your "Identity Provider" (IDP).

Once SSO is enabled, all users of an organization must sign in to Proof via SSO:

  • Former Proof passwords will no longer work.
    • This rule does not apply to organization admins.
  • Former Proof usernames will no longer work if those usernames do not match existing usernames in your organization’s IDP.

Prerequisites

  1. Your company must be a Proof Command Center customer:
  2. You must have authority over a domain to verify with Proof.
  3. You must have an Identity Provider (IDP):
    • Examples include but are not limited to Okta, Microsoft Azure, and Google IDP.
    • If unsure, ask your internal technical contact (IT, engineer, etc.).

Configuring SSO

Configuring SSO is bidirectional: The SP metadata must be configured in the IDP, and the IDP metadata must be configured in the SP.

Before setup
  1. You need a metadata file (.xml) from your Identity Provider (IDP) - some common guides:
  2. You must have a Proof-verified domain. See Domain Verification for instructions.
Set up SSO with Proof
  1. When you first log in to Proof, click the waffle menu (6 dots) next to Proof for Business in the upper-left corner and select Command Center.
  2. As an Owner or Admin, you'll see Access as an option in the left-hand navigation panel:
    • Click Access to open this tab.
  3. Under the Access menu, select Identity providers under
  4. Click from the top-right corner of your screen and type an internal name for your configuration. This can be whatever you’d like it to be, something that will be easy for you and other admins to use. Many align it with the name of their IDP.
  5. Drag and drop or click to upload the metadata file (.xml) from your SP.
  6. Click
  7. You'll see data processed from your metadata file. Your SAML configuration is not active yet; no users are impacted at this stage. Please review in detail:
    • You should have at least one (1) certificate visible that is in the “Active” state. Your metadata provided this.
    • If your metadata includes a Single Log–Out (SLO) URL, SLO will be on for your domain users. This means that when a user logs out of their SP, we log them out of Proof.
    • You can delete and replace your metadata file if any of the information needs to be changed.
  8. After reviewing, click to save. Your SAML configuration is not active yet; no users will be impacted at this stage.
  9. To activate this SAML configuration, you must connect it to a verified domain:
    • Click Domains from the Access menu (one panel in from the left)
    • Select your chosen Domain, which must be in a “Verified” status
    • Select “Details and Policies”. Click to select “Domain-based single sign-on (SSO)”
    • Select the Configuration you created from the drop-down and save:
      • Note the details of the configuration, including JIT provisioning, routing logic for new users, and which users will also have access to a password.
  10. Once you click Save, the SSO configuration will be live and applied to all users on the Proof platform with your domain.
Set up SSO with your Identity Provider (IDP)

The IDP needs to configure the following Proof SAML data:

Attribute Name Attribute Description
nameid required A unique immutable identifier for the user
first_name required User’s first name

middle_name optional

❗We strongly advise customers to send us the middle names of their users to help them go through KBA if signing documents.
 User's middle name
last_name required User’s last name
name optional User’s full name e.g., “John Patrick Smith Jr.”
email required User's email

roles optional but recommended

If omitted, the default role is assigned to the user:

  • Default role = "employee"

 

⚠️ This applies to new and existing users (e.g., an Admin user would lose their admin privileges if “admin” is not specified for them).

An array of roles. Posible values are:

  • Admin makes that team member an organization’s admin in Proof
  • Notary makes that team member an In-House Notary for that organization
  • Employee makes that user a team member

Assign specific roles to a user.

It’s possible to send multiple values, e.g., [employee, notary], [employee, admin], [notary, admin], etc.
organization_id optional

A Proof organization external ID.
[e.g. or_ojw8gkq]

This is helpful for companies that have a root organization with subsidiaries that may include multiple parent/child organizations:

  • If specified, the user is added to that organization.
  • If not specified, the user is added to the organization that configured the SSO.
notary_state optional - required if role(s) include notary

The abbreviation of the notary’s state of operation. (The state in which the notary is commissioned.)

e.g. notary_state: AZ, notary_state: az
notary_languages optional - required if role(s) include notary

An array of languages spoken by the user (notary). Supported values are:

  • en = English
  • es = Spanish

More than 1 language can be selected. 

e.g.: [en], [en, es]

Testing

  • New customers: If you aren't already using the Proof platform, testing may occur in Production.
  • Existing customers: It is mandatory to test on Fairfax. The Fairfax organization must match the same parent/child organization structure as expected in Production.
Fairfax IDP Configuration for Testing

The IDP needs to configure the following Proof SAML data:

Back to Top

© 2023-2024 Notarize, Inc. (dba Proof.com) All Rights Reserved.

Related articles