Setting Up SSO
Prerequisites, the setup process, SAML settings, and going live
Setting up SSO is an exchange of SAML metadata between your organization and Deque. Neither party requires access to the other's systems.
Prerequisites
Before you begin, ensure you have:
- Administrator access to your identity provider
- The list of Deque products in scope
- Every email domain your users sign in with, including subdomains
- A test user who already exists in your identity provider
- Technical contacts who can configure SAML and test the connection
The Setup Process
Setup runs in three phases. For IdP-initiated login, the process repeats once for each Deque product.
| Phase | Responsibility | Description |
|---|---|---|
| 1 | Deque | Prepares the connection and sends you the values you need |
| 2 | You | Configure a SAML 2.0 application, then send Deque your metadata |
| 3 | Deque | Completes the configuration and confirms the connection is ready to test |
Requesting SSO
Contact helpdesk@deque.com or your Deque representative with the following:
- Your organization name
- Every email domain in scope
- The Deque products in scope
- Your identity provider
- Whether you want SP-initiated or IdP-initiated login
- Your technical contacts
Deque then sends you a Service Provider Entity ID and SP metadata (XML) for each product. For IdP-initiated setups, you receive one Entity ID for each product.
Choosing Your Login Flow
Deque supports two SSO login flows. Choose based on your organization's identity provider capabilities:
| Flow | User Experience | Configuration | Provider-Specific Setup |
|---|---|---|---|
| SP-Initiated | User logs in at Deque's login page | Simpler: Deque provides metadata, you import it | No provider-specific configuration needed |
| IdP-Initiated | User launches Deque from IdP's app portal | More involved: You configure SAML in your IdP | Required for Okta, Entra ID, PingFederate, others |
Both flows are secure and SAML 2.0-compliant. Proceed to the section matching your choice below.
SP-Initiated Flow Configuration
For SP-initiated login, Deque manages the Service Provider configuration. Your role is to import Deque's metadata into your identity provider.
SAML Settings for SP-Initiated Login
Only one SAML setting is unique to your organization:
| Setting | Value |
|---|---|
| Name ID format | Email address |
| Name ID value | The user's work email address |
The Name ID must be the user's work email address, and it must match the address they have in Deque. If your identity provider sends a username, an employee ID, or an address at a different domain, sign-in fails or the user is returned to the login page repeatedly. This is the most common setup problem, so confirm the value before testing.
Metadata Import
Import the SP metadata (XML file or URL) that Deque provided:
- If your identity provider has a "metadata import" or "metadata URL" option, use Deque's metadata URL directly.
- Otherwise, download the XML file and upload it to your identity provider.
- Your IdP will auto-populate most settings; no additional SAML configuration is required.
After importing Deque's metadata, proceed to Testing below.
IdP-Initiated Flow Configuration
For IdP-initiated login, you manually configure a SAML application in your identity provider using Deque's metadata.
Selecting the Entity ID Value
The Entity ID is the entityID attribute of the md:EntityDescriptor element in the metadata file Deque provided. Its value ends with /clients/<client name>. For example:
https://auth.deque.com/.../axe.<your-domain>/endpoint/clients/axe-login-idpDo not use the value that ends at /endpoint with nothing following it. The metadata file contains both values, and the shorter one will break sign-in.
Use the full value ending in /clients/<client name> exactly as it appears in the file. Do not shorten or edit it.
This single value is used in two places: the Entity ID and the Reply URL (or ACS URL). Enter the same value for both fields.
SAML Settings for IdP-Initiated Login
These settings apply to every identity provider for IdP-initiated login:
| Setting | Value |
|---|---|
| Entity ID / Audience URI | The Entity ID value ending in /clients/<client name> |
| Reply URL / ACS URL | The same Entity ID value |
| Name ID format | Email address |
| Name ID value | The user's work email address |
| Signing | Sign the SAML assertion |
| Encryption | None |
The Name ID must be the user's work email address, and it must match the address they have in Deque. If your identity provider sends a username, an employee ID, or an address at a different domain, sign-in fails or the user is returned to the login page repeatedly. This is the most common setup problem, so confirm the value before testing.
Attribute Mapping
Send the following attributes so that first and last name are imported on first sign-in:
| Attribute name | Value |
|---|---|
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname |
First name |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname |
Last name |
The attribute name format differs by provider. Okta and Microsoft Entra ID use Unspecified; PingFederate uses urn:oasis:names:tc:SAML:2.0:attrname-format:uri. If the format is set incorrectly, names are not imported and users are asked to enter them on first sign-in.
Assigning Users
Assign the users and groups who should have access. Most identity providers block sign-in for users who are not assigned. Assignment controls who can authenticate; it does not grant access to Deque products.
Provider-Specific Configuration
Follow the guide for your identity provider:
Any other SAML 2.0-compliant provider is supported. Use the SAML settings above and consult your provider's documentation for the location of each field.
Sending Deque Your Metadata
After configuring your identity provider, send Deque your metadata. Send either a metadata URL or an exported XML file; both contain the values Deque requires:
| Item | Location in your metadata |
|---|---|
| Single Sign-On service URL | The Location attribute of the md:SingleSignOnService element |
| Signing certificate (X.509) | The ds:X509Certificate element |
| Entity ID / Issuer | The entityID attribute of md:EntityDescriptor |
For IdP-Initiated Login Only: IdP-Initiated Start URL
In addition to your metadata, send Deque your IdP-initiated start URL. This value is not included in your metadata and must be sent separately:
| Provider | Location |
|---|---|
| Okta | Applications, then your application, then General, then App Embed Link |
| Microsoft Entra ID | Enterprise applications, then your application, then Properties, then User access URL |
| PingFederate | Your runtime base URL followed by /idp/startSSO.ping, without query parameters |
Deque then imports your SSO URL and certificate, enables signature validation, and confirms when the connection is ready to test. The connection remains disabled until you go live, so it cannot affect your users' existing sign-in.
Testing
Where possible, test against a QA or staging instance of your identity provider first. If you subsequently move to production, send Deque your production metadata and the connection is rebuilt from it.
Confirm the following:
- The user reaches your sign-in page and authenticates, including multi-factor authentication.
- The user returns to Deque and arrives in the product.
- The user's name and email address are correct on their Deque profile.
- A user without an existing Deque account is created correctly.
- A user with an existing Deque account completes the account link successfully.
Account Linking
Users who already have a Deque login must confirm the link between their Deque account and your identity provider on their first SSO sign-in. Deque sends a confirmation email, and the user selects the link to complete the process. This occurs once for each user.
Prepare your users before go-live. During testing, capture the linking screens so you can provide your users with a short walkthrough. Tell them explicitly:
- Do not change the email address on the profile page shown after the first SSO sign-in.
- Do not use the Google or GitHub sign-in buttons. Enter your work email address and continue.
Going Live
Once testing succeeds and your users have been notified, tell Deque when to enable the connection permanently. From that point, every user on the enabled domain signs in through your identity provider.
Base URLs
Use the base URL for your region or dedicated instance.
| Hosting option | Base URL |
|---|---|
| SaaS, US region | https://axe.deque.com |
| SaaS, EU region | https://axe-eu.deque.com |
| SaaS, Australia region | https://axe-au.deque.com |
| SaaS, Frankfurt region | https://axe-frankfurt.deque.com |
| Private cloud and on-premises | Your dedicated instance URL |
