Set Up Domain-Based Single Sign-On (SSO) – Proof Help Center

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
Definitions
What to expect after SSO is enabled
Requirements
Before you set up

🎯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.
Gives you full control over user provisioning from your identity provider.
Helps with the seamless integration of Proof into your existing processes.
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!

Definitions

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).

What to expect after SSO is enabled

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

Former Proof passwords will no longer work.
- Owners and admin users with Command Center access are an exception. They will have the option to use a password to login.
Former Proof usernames will no longer work if those usernames do not match existing usernames in your organization’s IDP.
Individuals with your email domain will not be able to create new separate accounts on the Proof platform.
If any users with your email domain already have a separate account on the Proof Platform they will not be able to access the platform if they are not provisioned on your IDP.

If you have any users in your organizations with domains you do not have authority over, you cannot enforce SSO for them. We highly recommend enabling MFA for the organization they have access to.

Requirements

Your company must be a Proof Command Center customer:
- See Command Center Overview for more information.
You must have authority over a domain to verify with Proof.
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.).

Before you set up

You need data from your Identity Provider (IDP).

Option A: Most commonly, you can use a metadata file (.xml) from your Identity Provider (IDP). Some common guides:
- Okta
- Microsoft Azure
Option B: If you don’t have the option to download a metadata file from your IDP, you will need the following details:
- Entity ID
- X509 public certificate
- Single sign-on (SSO) URL
- SSO request binding
- [optional] single log-out (SLO) URL and request binding

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

You need a metadata file (.xml) from your Identity Provider (IDP) - some common guides:
- Okta
- Microsoft Azure
You must have a Proof-verified domain. See Domain Verification for instructions.

Set up SSO with Proof

Click the 9-dot grid in the upper left corner of your account and select Command Center.
Click Access from the menu on the left.
Select Identity providers.
Click Configure new identity provider from the upper right corner.
Type an internal name for your configuration.
- This can be whatever you’d like, preferably something easy for you and other admins to use. Many align it with the name of their IDP.
Select a method for providing your metadata.
- If you select an XML file, drag and drop or click to upload the metadata file (.xml) from your IDP.
- If you select manual entry, provide all of the required fields from your identity provider, including:
  - Entity ID
  - X509 public certificate
  - SSO URL
  - SSO request binding
  - Single log out is optional
Click Process.
Your SAML configuration details are displayed. The 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.
After reviewing, click to save. Your SAML configuration is not active yet; no users will be impacted at this stage.
Review in detail:
- You have at least one (1) certificate visible that is in the “Active” state.
- If you or your metadata provided a Single Log–Out (SLO) URL, SLO will be on for your domain users. This means that when a user logs out of their identity provider, we log them out of Proof.
- You can delete and replace your metadata file or edit your configuration details if any of the information needs to be changed.
After reviewing, click to save. Your SAML configuration is not active yet; no users will be impacted at this stage.
Proceed to the next part to activate.

Activate your SAML configuration

To activate this SAML configuration:

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.
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:

Entity (or Issuer) ID: https://api.proof.com/saml/consume
Assertion Consumer Service (ACS) URL: https://api.proof.com/saml/consume
SP metadata URL: https://api.proof.com/saml/metadata
- Also available as a file - see attachment at the bottom of this article “proof_saml_metadata.xml”
SAML Attributes
- These attributes sent from the IDP to SP help Proof provision accounts on the fly, assign specific roles (organization admin, organization notary), and create users in the desired child organizations.

SSO user attributes

Proof has default attributes for your SAML configurations which can be found below. If your IDP does not support sending Proof these specific attributes (e.g. your IDP can only send a user's first name as "given_name", not "first_name" as required), you must configure custom attribute mapping in Proof.

To map custom attributes, ensure you’re starting on the “identity providers” view within the “Access” tab of Command Center. If you’ve begun the process of setting up SSO you should have your identity provider visible in this view.

Click Configuration details for the relevant identity provider.
Click Actions in the top right corner and select Configure attribute mapping.
Use Add custom mapping for each attribute you’d like to add.
- You do not need to add the default mappings, just add each attribute that you need to uniquely set up.
- The value you enter for your IDP’s attribute is case sensitive.
- You can remove any custom attribute before the next step.
Click Save changes.

Note: These changes will take effect immediately. If your SAML configuration is in active use with corresponding verified domains, the new attributes will have immediate impact.

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