# Using Single Sign On

### Configuring Custom SSO Providers (e.g., Okta) with emSigner

<figure><img src="https://1693119202-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FXNKpOPGIHdEkmaF2RQso%2Fuploads%2FUdmg7IxeHsJ3fRrqaGLD%2Fimage.png?alt=media&#x26;token=b0590c8b-1941-418c-beaa-8d2e9286651b" alt=""><figcaption></figcaption></figure>

#### Overview

emSigner supports integration with **custom Identity Providers (IdPs)** such as **Okta**, **Ping Identity**, **Auth0**, or other SAML 2.0–compliant platforms. This allows organizations to authenticate users using their existing enterprise identity infrastructure while maintaining emSigner’s security, auditability, and compliance controls.

This menu can be accessed from the "Identity Provider" option available in Admin Settings under the Settings section.

***

#### Supported Protocol

* **SAML 2.0**
* Authentication requests can be sent using **POST** or **GET.**
* emSigner acts as the **Service Provider (SP).**
* Your enterprise IdP (for example, Okta) acts as the **Identity Provider (IdP).**

***

#### Prerequisites

Before configuring a custom SSO provider:

* Administrative access to your Identity Provider (for example, Okta Admin Console)
* A configured **SAML application** in the IdP for emSigner
* SSO enabled for your organization in emSigner
* The email address configured as the **unique user identifier** in both emSigner and the IdP

***

#### Identity Provider Configuration in emSigner

The **Identity Provider** screen in emSigner is used to register your IdP details. Each field is described below.

***

**1. Identity Provider Metadata URL**

* **Optional but recommended**
* A URL that hosts the IdP’s SAML metadata XML
* emSigner can automatically retrieve:
  * Issuer
  * Login URL
  * Logout URL
  * Signing certificate

If provided, you may use **Auto-fill** to populate fields automatically.

**Example (Okta):**\
`https://<your-okta-domain>/app/<app-id>/sso/saml/metadata`

***

**2. Identity Provider Issuer**

* The **Entity ID** of your Identity Provider.
* This value uniquely identifies the IdP in SAML assertions.
* Must exactly match the Issuer configured in the IdP.

***

**3. Authentication Request Method**

Defines how emSigner sends authentication requests to the IdP.

* **POST** (recommended)
* **GET**

Select the method supported and configured in your IdP.

***

**4. Identity Provider Login / Redirect URL**

* The **Single Sign-On (SSO) URL** of your Identity Provider.
* Users are redirected to this URL during login.
* Provided by your IdP’s SAML configuration.

***

**5. Logout Request Method**

Defines how emSigner sends logout requests.

* **POST** or **GET**
* This should match the IdP’s logout endpoint configuration.

***

**6. Identity Provider Logout URL**

* The **Single Logout (SLO) URL**, if supported by your IdP.
* Enables centralized logout across applications.
* Optional, but recommended for enterprise environments.

***

**7. Certificate**

* Paste the **X.509 signing certificate** provided by the Identity Provider
* Used by emSigner to:
  * Verify SAML assertion signatures
  * Ensure message integrity and authenticity

> Ensure the certificate is kept up to date before expiry.

***

#### IdP-Side Configuration (Example: Okta)

When configuring emSigner as a SAML app in your IdP:

* **Assertion Consumer Service (ACS) URL**: Provided by emSigner
* **Entity ID (Audience URI)**: Provided by emSigner
* **NameID format**: Email address
* **NameID value**: User’s primary email
* **Attribute mapping**:
  * Email → emSigner user identifier

***

#### User Login Flow

Once configuration is complete:

1. The user enters their **email address** on the emSigner login page.
2. emSigner identifies that a custom SSO provider is configured for the domain.
3. The user is redirected to the Identity Provider (e.g., Okta).
4. Upon successful authentication, the user is logged in to emSigner.

***

#### Security & Compliance Notes

* emSigner does **not store IdP passwords**.
* All authentication decisions are handled by the Identity Provider.
* Existing IdP controls such as **MFA**, **Conditional Access**, and **device trust** continue to apply.
* Login events are recorded in emSigner audit logs for traceability.

***

#### Troubleshooting

**Users not redirected to IdP**

* Verify the domain-to-IdP mapping in emSigner
* Ensure email domain matches the configured IdP

**Authentication fails**

* Confirm Issuer and ACS values match exactly
* Verify certificate validity and format

**Access denied after login**

* Check user assignment in the IdP
* Review IdP MFA or policy restrictions

***

#### Need Assistance?

For environment-specific ACS URLs, metadata validation, or help onboarding custom SSO providers such as Okta, Ping, or Auth0, please contact emSigner Support or raise a ticket through the Support Portal.