Domain-based single sign-on (SSO) enables an organization's users to log in to multiple applications using a single username and password.
The process below is part of a multistep process to set up domain-based single sign-on. Click a link below to review that step of the process, or read the domain-based single sign-on overview here, which includes what to expect after this process is complete.
- Verify your domain
- Set up single sign-on in your Proof account
- Set up SAML configurations with your identity provider for SSO → You are here
Proof SAML data
The identity provider (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
- 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.
Set up SAML configurations with your identity provider
The default attributes for your SAML configurations 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.
If you’ve begun the process of setting up SSO you should have your identity provider visible in this view.
- Click the dot grid in the top left corner.
- Select Command Center.
- Click Access from the left navigation panel.
- Select Identity providers from the Access page menu on the left.
- Click Configuration details for the identity provider you'd like to edit.
- Click Actions in the upper right corner.
- Select Configure attribute mapping.
- Click + Add custom mapping to add an attribute.
- Select the desired attribute from the dropdown menu.
- Type the value for your IDP's attribute.
- Click Save changes.
- Repeat for each custom attribute as needed.
- You do not need to add the default mappings, just add each attribute that you need to uniquely set up.
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:
⚠️ 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:
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. This is helpful for companies that have a root organization with subsidiaries that may include multiple parent/child organizations:
|
| 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:
More than 1 language can be selected. e.g.: [en], [en, es] |