SSOGEN / SSO Applications / Docusign SSO: Sign In to Docusign Through SSOGEN
Integration
Docusign SSO: Sign In to Docusign Through SSOGEN
Docusign SSO with SSOGEN runs in three moves: prove you own the email domain, add SSOGEN as an identity provider in Docusign Admin, then require SSO for the domain. SSOGEN's default Name ID is already the stable identifier Docusign recommends.
Docusign SSO with SSOGEN signs people in to Docusign eSignature under your SSOGEN sign-in policy, with a second factor where the policy asks for one. Docusign is the SAML 2.0 service provider and SSOGEN is the identity provider.
The App gallery in SSOGEN has a DocuSign card that opens the registration wizard with the name, icon and protocol filled in and links to Docusign’s own guide.
Docusign ties single sign-on to the email domain, not to one account. That is why the domain claim comes first.
Two products, two places to configure
| Docusign product | Where SSO is set up | Who sets it up |
|---|---|---|
| eSignature (and other products under Docusign Admin) | Docusign Admin: Domains, then Identity Providers | An organization administrator |
| CLM | CLM Preferences, sub tab SAML SSO | A CLM Super Administrator, once |
Each one is a separate SAML application in SSOGEN with its own entity ID and assertion consumer service URL. People see two tiles in My Apps if they use both.
Set up eSignature in Docusign Admin and SSOGEN
- Claim the domain. In Docusign Admin open Domains and claim
acme.example. Docusign issues a token. Publish it in DNS as a CNAME record (Docusign’s recommendation) or a TXT record, then select Actions, Validate. Keep the token in DNS for as long as the domain belongs to your organization. - Register Docusign in SSOGEN. In the Admin Console open Applications, App gallery, and select DocuSign. Choose a Sign-in policy. Leave Identify the person by at its default and add the attributes from the next section.
- Add SSOGEN to Docusign. In Identity Providers, add one. Enter SSOGEN’s IdP entity ID as the issuer, the Single sign-on URL as the login URL, and upload the signing certificate. All three are on the application’s Integration tab in SSOGEN.
- Copy Docusign’s endpoints back. On the new identity provider select Actions, Endpoints. Docusign shows its entity ID, its assertion consumer service URL and a start URL. Enter the first two in SSOGEN’s Connection step and the start URL as the Launch URL.
- Assign, test, activate. Assign one person, run Test, read the assertion card, then select Activate application.
- Enforce. Back in Domains, select Actions, Manage Settings on the domain and require SSO for its users. Their Docusign passwords then stop working.
The SSOGEN screens are described step by step in Register a SAML application and Assign people, set the sign-in policy, test and activate.
Send a stable Name ID and three attributes
Docusign requires four values in every assertion: the Name ID, the email address, the first name and the last name. For the Name ID, Docusign advises against the email address, because addresses change and can be reissued. It recommends an employee ID or another unique identifier.
SSOGEN’s default choice, SSOGEN user ID, permanent (recommended), is exactly that. It is sent in format persistent, never changes and is never given to anyone else.
| Docusign needs | Set in SSOGEN, Identity sent to app |
|---|---|
| Name ID | Identify the person by: SSOGEN user ID, permanent (recommended) |
Add an attribute, value email |
|
| First name | Add an attribute, value given_name |
| Last name | Add an attribute, value family_name |
Give each attribute the name your Docusign identity provider settings map to email, first name and last name. The Test step then shows all four values with the person’s real data before anyone signs in.
Bindings, signing and the ACS URL
| Docusign setting | What to choose with SSOGEN |
|---|---|
| Send AuthN request by: redirect (GET) or HTTP POST | Either. SSOGEN’s single sign-on URL serves both bindings. |
| Sign AuthN request | Optional. If you turn it on, paste Docusign’s SSO certificate into the Signing certificate field in SSOGEN. SSOGEN does not require signed requests. |
| Assertion delivery | HTTP POST, which is how SSOGEN sends every assertion. |
| Assertion consumer service URL | The current format from Endpoints, which ends with the identity provider’s ID. |
An older ACS URL without that ID makes Docusign answer “The issuing identity provider is not registered with Docusign”. Copy the URL from Endpoints again and update the Connection values in SSOGEN.
Questions people ask
How do I set up Docusign SSO with SSOGEN?
Claim your email domain in Docusign Admin, register the DocuSign card in SSOGEN, add SSOGEN as an identity provider with its entity ID, sign-in URL and certificate, copy Docusign’s endpoints back, test the assertion, activate, then require SSO on the domain.
Why does Docusign ask for a domain claim first?
Docusign only lets the owner of an email domain change how its users sign in. Claiming the domain with a DNS token proves that ownership, so nobody else can point your users at their identity provider.
What happens to Docusign passwords when SSO is required?
Once the domain setting requires SSO, existing Docusign user names and passwords are no longer valid. People sign in through SSOGEN from the Docusign sign-in page or from their My Apps tile.
Does Docusign CLM use the same setup?
No. CLM has its own SAML configuration under Preferences, sub tab SAML SSO, set once by a Super Administrator. Register CLM as a second SAML application in SSOGEN with the values CLM shows.
Where to go next
- Hub. The SSO applications hub compares SAML and OpenID Connect and lists the other guides.
- Other applications. Step-by-step setups for other SaaS products are in the application guides.
- Acrobat Sign as well? Adobe SSO covers Acrobat Sign next to Creative Cloud and Experience Cloud.
Sources, all read 2026-11-15 (Docusign Support):