Overview
Learn about using Single sign-on (SSO) for your organization.
SSO enables an organization's users to log in to multiple applications using a single username and password. With SSO, account + credential management is not handled by Proof but instead by your “Identity Provider” (IDP). The IDP will manage user accounts plus grant & revoke access to the Proof application.
| Benefits | Notes | Prerequisites | Configuring | Testing |
🎯Primary Audience: Proof for Business
Benefits
- Users within your organization can easily use Proof without repeatedly entering a password!
- SSO can be used for parent → child companies.
- SSO helps with the seamless integration of Proof into your existing processes.
SSO also offers “account provisioning”. Proof user accounts are created on the fly when the organization’s users access the Proof application from their IDP. This streamlines onboarding organization members!
Notes
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.
- Proof usernames will no longer work if those usernames do not match existing usernames in your organization’s IDP.
Prerequisites
- You must have an Identity Provider (IDP):
- Examples include but are not limited to Okta, Microsoft Asure, Google IdP
- If you are unsure, ask your internal technical contact (IT, engineer, etc.)
- The IDP must support Security Assertion Markup Language (SAML) 2.0:
- Proof does not currently support OpenID (sometimes referred to as OAuth)
- Your organization must be on a "Pro" Tier Pricing Plan
- SSO is not available for trial plans.
Configuring SSO
Proof is called the “Service Provider” (SP), and the entity you work with to create, maintain, and manage your identity information is called your "Identity Provider" (IDP). Examples of IDPs include Okta and Microsoft Azure.
Configuring SSO is bidirectional: The IDP needs to configure the SP’s SAML data, and the SP needs to configure the IDP’s SAML data.
Prod IDP Configuration
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.
| Attribute Name | Attribute Description |
| nameid required | unique immutable identifier for the user |
| first_name required | User’s first name |
|
middle_name optional Note: 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 An array of roles. Possible values are admin, notary, or employee. If omitted, the default role of "employee" will be assigned to the user. This also applies to existing users (e.g., an Admin user would lose their admin privileges if “admin” is not specified for them). |
Assign specific roles to a user:
|
| organization_id optional |
A Proof organization external ID. If specified, the user will be added to that organization. They'll be added to the organization where SSO was configured if unspecified. e.g. or_ojw8gkq This enables SSO with child organizations. |
| notary_state optional - required if roles include notary |
The abbreviation of the notary’s state of operation. e.g. notary_state: AZ, notary_state: az |
| notary_languages optional - required if roles include notary |
An array of languages spoken by the user (notary). Supported values are en and es. e.g.: [en], [en, es] |
SP Configuration
The customer should provide Proof with the following information:
- Entity ID
- Target URL
- X509 client certificate
If the customer prefers, configuration is possible by only providing Proof a metadata URL or metadata file.
An organization admin can enable SSO and enter this information in Settings Team Security:
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
The IDP needs to configure the following Proof SAML data:
- Entity (or Issuer) ID: https://api.fairfax.proof.com/saml/consume
- Assertion Consumer Service (ACS) URL: https://api.fairfax.proof.com/saml/consume
- SP metadata URL: https://api.fairfax.proof.com/saml/metadata
- Also available as a file - see attachment at the bottom of this article “proof_fairfax_saml_metadata.xml”
Still have questions you can't find answers to? Click the chat icon in the corner of your screen to start a chat, email us at support@proof.com!
CONFIDENTIAL. © 2022-2023 Notarize, Inc. (dba Proof.com)