Duo Single Sign-On for Generic SAML Service Providers

About Duo Single Sign-On

Duo Single Sign-On is our cloud-hosted SSO product which layers Duo's strong authentication and flexible policy engine on top of an application's login using the Security Assertion Markup Language (SAML) 2.0 or OpenID Connect (OIDC) authentication standards. Duo Single Sign-On acts as an identity provider (IdP), authenticating your users using existing on-premises Active Directory (AD) or any SAML 2.0 IdP and prompting for two-factor authentication before permitting access to your service provider application.

Duo Single Sign-On is available in Duo Premier, Duo Advantage, and Duo Essentials plans, which also include the ability to define policies that enforce unique controls for each individual SSO application. For example, you can require that users of one application complete two-factor authentication at every login, but only once every seven days when accessing a different application. Duo checks the user, device, and network against an application's policy before allowing access to the application.

Configure Single Sign-On

Before configuring your service provider application you'll first need to enable Duo Single Sign-On for your Duo account and configure a working authentication source.

Once you have your SSO authentication source working, continue to the next step of creating the SP application in Duo.

We've already added a number of popular SaaS applications to Duo pre-configured for use with Duo Single Sign-On. These applications have "Single Sign-On (hosted by Duo)" next to their name. If you want to protect a cloud service that we don't have listed by name, you can use our Generic SAML Service Provider application.

When configuring an application to be protected with Duo Single Sign-On you'll need to send attributes from Duo Single Sign-On to the application. Active Directory will work with no additional setup, but if you used a SAML idenity provider as your authentication source please verify that you configured it to send the correct SAML attributes.

Below you can see the five (5) default bridge attributes that automatically map certain attributes from your authentication source. These bridge attributes are required and cannot be edited. You can also create custom bridge attributes.

Bridge Attribute	Active Directory	SAML IdP
<Username>	sAMAccountName	Username
<Email Address>	mail	Email
<Display Name>	displayName	DisplayName
<First Name>	givenName	FirstName
<Last Name>	sn	LastName

Create Your Cloud Application in Duo

1. Log on to the Duo Admin Panel and navigate to Applications.

2. Click Protect an Application and locate the entry for Generic SAML Service Provider with a protection type of "2FA with SSO hosted by Duo (Single Sign-On)" in the applications list. Click Protect to the far-right to start configuring Generic SAML Service Provider. See Protecting Applications for more information about protecting applications in Duo and additional application options. You'll need the information on the Generic SAML Service Provider page under Metadata later.

3. The Metadata section is where you can get SAML identity provider information about Duo Single Sign-On to provide to your service provider.

Name	Description
Entity ID	The global, unique name for Duo Single Sign-On. This is sometimes referred to as "Issuer".
Single Sign-On URL	The authentication URL for Duo Single Sign-On. This is sometimes referred to as "SSO URL" or "Login URL". This URL can also be used to start IdP-initiated authentications.
Single Log-Out URL	The logout URL for Duo Single Sign-On. This is sometimes referred to as "SLO URL" or "Logout Endpoint". This field is optional.
Metadata URL	This URL can be used by service providers to download the XML metadata from Duo Single Sign-On.
SHA - 1 Fingerprint	The SHA-1 fingerprint of the SAML certificate. Sometimes service providers will request a fingerprint instead of uploading a SAML certificate.
SHA - 256 Fingerprint	The SHA-256 fingerprint of the SAML certificate. Sometimes service providers will request a fingerprint instead of uploading a SAML certificate.
Certificate	The certificate used by the service providers to validate the signature on the SAML response sent by Duo Single Sign-On. Click the Download Certificate button to download a crt file.
SAML Metadata	The XML SAML Metadata used by service providers to configure the service provider with settings from Duo Single Sign-On. Click the Download XML button to download a xml file.

Configure Your Service Provider

You'll need to provide some information about Duo Single Sign-On to your cloud application provider, like URL information, a metadata file, a certificate file, or a certificate fingerprint. You can find this information in the Metadata section at the top of the application page in the Duo Admin Panel.

Refer to your service provider's SSO configuration guide for instructions.

Update Your Cloud Application in Duo

1. Return to the application page in your Duo Admin Panel.

2. Enter information provided by your application into the Service Provider section:

   Name	Description
   Metadata Discovery	If your service provider makes a metadata URL or file available you can import that information instead of manually entering it in Duo.   To configure the service provider using a URL, select Metadata XML URL from the drop-down, paste in the URL provided by your service provider application into the Metadata XML URL field, and click Populate to fill in the service provider configuration fields with information retrieved from the service provider.   To configure the services provider using an XML file, select Metadata XML file from the drop-down and use the Choose File button to select an XML file you downloaded from your service provider to import.   Leave the drop-down set to None (manual import) to populate the fields by copying information from your service provider and pasting it into the Duo Admin Panel.
   Entity ID	The service provider identifier.
   Assertion Consumer Service (ACS) URL	The URL where your service provider receives SAML assertions. You can click Add an ACS URL if your service provider supplies more than one URL. The field will change to show additional options to specify optional Index and isDefault fields per URL. If you are unsure about these settings, leave them blank. Please refer to your Service Provider for ACS URL details.
   Single Logout URL	Optional: The URL where your service provider receives SAML logout responses.
   Service Provider Login URL	Optional: The URL for IdP-initiated logins if your service provider specifies one. This URL will be used when doing an IdP-initiated login from Duo Single Sign-On by either navigating directly to the "Single Sign-On URL" from the metadata section or clicking this application's tile in Duo Central.
   Default Relay State	Optional: If your service provider requires a specific RelayState parameter, enter it here.

   

3. Use your application's SSO instructions to complete the SAML Response section:

   Name	Description
   NameID format	Format of NameID when sent to the service provider.
   NameID attribute	The authentication source attribute used to identify the user to the service provider. This attribute is sent as the NameID. This is often a user's e-mail address. You can select our pre-configured attributes which will automatically pick the correct attribute based on your authentication source from the drop-down or use your own.
   Signature Algorithm	Select the encryption strength supported by your service provider. Defaults to SHA-256.
   Signing Options	Here you can toggle if you'd like to sign the SAML response and assertion by checking the boxes next to Sign response and Sign assertion. They are both checked by default.
   Assertion encryption	If your service provider supports encrypted assertions check the Encrypt the SAML assertion box, upload the encryption certificate obtained from the service provider, and choose the service provider's Assertion encryption algorithm and Key transport encryption algorithm options. Consult your service provider documentation to learn which algorithms it supports.
   Map attributes	If your service provider requires specific attributes sent, you can map the authentication source attributes to the required names here. On the left side you can select our pre-configured attributes which will automatically pick the correct attribute based on your authentication source from the drop-down or use your own and on the right side type the new attribute name you want sent to your service provider. Consult your service provider's documentation for the required attribute names.
   Create attributes	If your service provider requires an attribute with a specific value, you can define that here. Enter the new attribute name on the left, and the static attribute value on the right. Consult your service provider's documentation for the required attribute names.
   Role attributes	If your service provider requires an attribute related to the roles or groups of a user, specify that in the "Role attributes" section. Type the Attribute Name required by the service provider, and then under Service Provider’s Role type the value of the attribute that should be sent and under Duo Groups select the Duo Groups a user should be part of to get that role added to their SAML response.
   Attribute Transformations	Attribute Transformations is an advanced feature that allows you to modify the IdP attribute value before putting it into the SAMLResponse. See how to use attribute transformations.

   

4. You can adjust additional settings for your new SSO application at this time — like changing the application's name from the default value, enabling self-service, or assigning a group policy.

5. Scroll down to the bottom of the page and click Save.

Attribute Transformations

Attribute transformations is an advanced feature that allows you to modify an attribute value before it is sent to the SAML service provider. The most common reason to modify an attribute is that the service provider requires an attribute in a certain format that isn't available from your authentication source. An example is that some service providers offer sandbox environments but require that the username end in .sandbox. This isn't something you'd typically have stored in your authentication source so you wouldn't be able to protect that sandbox account using SSO. Attribute transformations solves this problem by allowing you to modify your attributes.

Attribute transformations work by operating on a list of rules from top to bottom to transform an attribute into exactly what you need. The attribute selected on the first line is used as the primary attribute to be transformed. All rules after the primary attribute was specified will continue to modify this same attribute. The list of rules can be seen below.

When specifying attributes you can use either the direct attribute name from your authentication source or one of the five bridge attributes. When using a bridge attribute type in the exact bridge attribute name as seen in the table at the top of the page, such as: <Email Address>.

When creating a transformation rule you can use it to create a temporary attribute. Temporary attributes create variables via the transformation language then can be reused for more complex transformations. When you create a temporary attribute and give it a name, you can then specify that temporary attribute by name in subsequent rules.

Each rule should be on its own separate line and go in order from top to bottom of how you'd like the attribute transformed.

Rule format is:

$RULE_NAME $OPTION="$OPTION_VALUE"

A rule can have more than one option and the option name must always be followed by an = and the option value encapsulated in quotes.

Rule Name	Description	Options
use	Always used as the first rule to define the primary attribute to modify. The attribute name should always be surrounded by quotes.	No options.
prepend	This rule allows you to prepend static text or the value of another attribute from your authentication source to the start of your primary attribute.	text: Static text to add to the start of the attribute. Must use this or additional_attr but not both. Example: prepend text="admin-" additional_attr: The name of another authentication source attribute to add to the start of your primary attribute. Must use this or text but not both. Example: prepend additional_attr="sAMAccountName"
append	This rule allows you to append static text or the value of another attribute from your authentication source to the end of your primary attribute.	text: Static text to add to the end of the attribute. Must use this or additional_attr but not both. Example: append text="@example.com" additional_attr: The name of another authentication source attribute you'd like to add to the end of your primary attribute. Must use this or text but not both. Example: append additional_attr="domain_name"
insert_before	This rule allows you to add static text or the value of another attribute from your authentication source before a delimiter that you specify.	delimiter: The character(s) used to identify where to add text before. It can be repeated to allow delimiting by more, logically inclusive, character(s). Required. text: Static text to add before the delimiter. Must use this or additional_attr but not both. Example: insert_before delimiter="@" text="-admin" additional_attr: The name of another authentication source attribute you'd like to added before the delimiter. Must use this or text but not both. Example: insert_before delimiter="@" additional_attr="sAMAccountName"
insert_after	This rule allows you to add static text or the value of another attribute from your authentication source after a delimiter that you specify.	delimiter: The character(s) used to identify where to add text after. It can be repeated to allow delimiting by more, logically inclusive, character(s). Required. text: Static text to add after the delimiter. Must use this or additional_attr but not both. Example: insert_after delimiter="@" text="example" additional_attr: The name of another authentication source attribute you'd like to added after the delimiter. Must use this or text but not both. Example: insert_after delimiter="@" additional_attr="domain_name"
keep_before	This rule removes text from your attribute after the delimiter, keeping only what was before it.	delimiter: The character(s) used to identify where to split the text and keep only what was before it. It can be repeated to allow delimiting by more, logically inclusive, character(s). Required. Example: keep_before delimiter="@"
keep_after	This rule removes text from your attribute before the delimiter, keeping only what was after it.	delimiter: The character(s) used to identify where to split the text and keep only what was after it. It can be repeated to allow delimiting by more, logically inclusive, character(s). Required. Example: keep_after delimiter="@"
make_uppercase	Uppercases the entire text of the attribute.	No options
make_lowercase	Lowercases the entire text of the attribute.	No options
format_ad_groups	This rule automatically filters Active Directory groups from their LDAP path name to only contain the group names.	filter: When specified, will only return group names that contain the word specified in the filter. You may use filter or startswith but not both. It can be repeated to allow filtering by more, logically inclusive, words. Optional. Example: format_ad_groups filter="admin" explicit: Can be used with option filter. When set to true will only return a group name that exactly matches the filter name. Optional. Example: format_ad_groups filter="admin-aws" explicit="true" startswith: When specified, will only return group names that start with the word specified. You may use startswith or filter but not both. It can be repeated to allow filtering by more, logically inclusive, words. Optional. Example: format_ad_groups startswith="enterprise" ignorecase: Can be used with options filter and startswith. When set to true will return all groups that match options with ignored case. For example, format_ad_groups filter="admin" ignorecase="true" will also return ADMIN if this group exists. Optional.
remove	This rule allows you to remove the first or all occurrences of static text or the value of another attribute from your authentication source to your primary attribute.	text: Static text to remove from the attribute. Required. Must use this or additional_attr but not both. Example: remove text="@example.com" additional_attr: The name of another authentication source attribute you'd like to remove from your primary attribute. Required. Must use this or text but not both Example: remove additional_attr="domain_name" all: When set to true will remove all occurrences. Optional. Example: remove text="_" all="true"

Examples

Below are some examples of different scenarios and how you can transform the attributes to solve your problem.

Example 1

A service provider requires that all your email addresses end in .sandbox but you don't have an attribute in your authentication source that does.

You have an email attribute named mail and your user's email is jdoe@example.com

use "mail"
append text=".sandbox"

• Line 1 picks the mail attribute from your authentication source to use for all rules below it. The example user's mail attribute value is jdoe@example.com.
• Line 2 appends the static text value specified to the end of the mail attribute. This changes the example value to jdoe@example.com.sandbox

Example 2

You need to change the domain of an email address attribute to be from example.com to acme.com.

You have an email attribute named mail and your user's email is jdoe@example.com.

use "<Email Address>"
keep_before delimiter="@"
append text="@acme.com"

• Line 1 picks the mail attribute from your authentication source to use for all rules below it. The example user's mail attribute value is jdoe@example.com.
• Line 2 keeps only the text before the delimiter character @. This changes the example value to jdoe.
• Line 3 appends the text value to the end of the mail attribute's value. This changes the example value to jdoe@acme.com.

Example 3

You need to transform email addresses into usernames.

You have an email attribute named mail and your user's email is j_doe@example.com.

use "<Email Address>" 
keep_before delimiter="@" 
remove text="_"

• Line 1 picks the mail attribute from your authentication source to use for all rules below it. The example user's mail attribute value is j_doe@example.com.
• Line 2 keeps only the text before the delimiter character @. This changes the example value to j_doe.
• Line 3 removes the text value specified from the mail attribute's value. This changes the example value to jdoe.

Example 4

You want to create an attribute that has a "no-reply" email address for a department, but no such attribute value exists in your identity store.

You have a custom department attribute that contains department names, and your email domain is example.com.

First, create a temporary attribute rule with the temporary attribute name set to noreply_prefix:

use "department"
append text="-no-reply"

• Line 1 picks the department attribute from your authentication source, with an example value of sales.
• Line 2 appends the text value -no-reply to the end of the department attributes value, resulting in the temporary attribute noreply_prefix with the value sales-no-reply.

Next, create a normal transformation rule to create the claim using the resulting email address via transformation:

use "noreply_prefix"
append text="@example.com"

• Line 1 uses the noreply_prefix attribute created by the temporary attribute transformation rule preceding this rule in the stack.
• Line 2 appends the email domain example.com to the temporary attribute's value, resulting in the email address sales-no-reply@example.com

How to enable attribute transformations

1. Next to Attribute Transformations check the box for Enable User Attribute Transformations. New options will appear below.

2. On the left-hand side under Transformation Rules you can use the rules above to fill out the textbox with how you'd like to transform an attribute.

3. If you want to use this rule to create a temporary attribute, select the Use as temporary attribute option on the right-side of the rules editor, and specify the name you want to use for the resulting attribute in the Temporary Attribute Name box.

4. If not creating a temporary attribute, then on the right-hand side you can either check the box next to Set this as my NameID attribute to use the transformed attribute as your NameID attribute or under SAML Response Attribute type the new attribute name you want sent to your service provider.

   Note: You can only set one attribute transformation to the NameID attribute at a time. This will replace your NameID attribute value you specified further up the page.

5. If you'd like to add additional attributes to transform click Add another transformation.

Preview Transformation Response

Use the "Preview Response" tool to test the outcome of your transformation rules and see what will be sent in the SAML response.

1. Provide values for attributes used in transformations in the Test Input box. Enclose attribute values in quotes.

   If you're transforming AD groups, you will need to enclose the AD group values in quotes and separate multiple groups with commas.

2. After you specify all values for attributes used in transformation rules, click Test Transformation Rules. If all transformation rules are correct, the "Transformed Output" section shows the transformed attributes with rules applied.

   Validation errors for any transformation rules will be shown underneath the "Test Input" area. If any of the test input values provided are incorrect, you will see an error message describing which provided attributes are incorrect. Correct the transformation rule or test input information and try the test again.

Duo Universal Prompt

The Duo Universal Prompt provides a simplified and accessible Duo login experience for web-based applications, offering a redesigned visual interface with security and usability enhancements.

Universal Prompt	Traditional Prompt

We've already updated the Duo generic SAML service provider application hosted in Duo's service to support the Universal Prompt, so there's no action required on your part to update the application itself. If you created your generic SAML service provider application before March 2024, you can activate the Universal Prompt experience for users from the Duo Admin Panel. generic SAML service provider applications created after March 2024 have the Universal Prompt activated by default.

If you created your generic SAML service provider application before March 2024, it's a good idea to read the Universal Prompt Update Guide for more information, about the update process and the new login experience for users, before you activate the Universal Prompt for your application.

Activate Universal Prompt

Activation of the Universal Prompt is a per-application change. Activating it for one application does not change the login experience for your other Duo applications.

The "Universal Prompt" area of the application details page shows that this application is "Ready to activate", with these activation control options:

• Show traditional prompt: Your users experience Duo's traditional prompt via redirect when logging in to this application.
• Show new Universal Prompt: (Default) Your users experience the Universal Prompt via redirect when logging in to this application.

The application's Universal Prompt status shows "Activation complete" here and on the Universal Prompt Update Progress report.

Should you ever want to roll back to the traditional prompt, you can return to this setting and change it back to Show traditional prompt. However, this will still deliver the Duo prompt via redirect, not in an iframe. Keep in mind that support for the traditional Duo prompt ended for the majority of applications in March 2024.

Universal Update Progress

Click the See Update Progress link to view the Universal Prompt Update Progress report. This report shows the update availability and migration progress for all your Duo applications. You can also activate the new prompt experience for multiple supported applications from the report page instead of visiting the individual details pages for each application.

Verify SSO

You can log into most applications using SSO by visiting their website directly.

You can log into your application using Duo Central, our cloud-hosted portal which allows users to access all of their applications in one spot. Link to your application in Duo Central by adding it as an application tile. Once the tile has been added, log into Duo Central and click the tile for IdP-initiated authentication to your application.

If your application supports IdP-initiated login, you can also use the Single Sign-On URL located under the "Metadata" section at the top of the application page in the Duo Admin Panel.

When you log into an application provided by Duo's Single Sign-On, you will be redirected to Duo Single Sign-On to begin authentication.

Active Directory Login

With Active Directory as the Duo SSO authentication source, enter the primary username (email address) on the Duo SSO login page and click or tap Next.

Enter the AD primary password and click or tap Log in to continue.

Enable Duo Passwordless to log in to Duo SSO backed by Active Directory authentication without entering a password in the future.

SAML Login

With another SAML identity provider as the Duo SSO authentication source, Duo SSO immediately redirects the login attempt to that SAML IdP for primary authentication. Users do not see the Duo SSO primary login screen.

Duo Authentication

Successful verification of your primary credentials by Active Directory or a SAML IdP redirects back to Duo. Complete Duo two-factor authentication when prompted and then you'll return to the service provider application to complete the login process.

* Universal Prompt experience shown.

If your application doesn't support IdP-initiated login you can modify the Service Provider Login URL on the application's page in the Duo Admin Panel to redirect to a different URL during IdP-initiated login.

You can also log into service provider application using Duo Central, our cloud-hosted portal which allows users to access all of their applications in one spot. Link to service provider application in Duo Central by adding it as an application tile. Once the tile has been added, log into Duo Central and click the tile for IdP-initiated authentication to service provider application.

Congratulations! Your your relying party application users now authenticate using Duo Single Sign-On.

See the full user login experience, including expired password reset (available for Active Directory authentication sources) in the Duo End User Guide for SSO.

Enable Remembered Devices

To minimize additional Duo two-factor prompts when switching between your service provider application and your other Duo Single Sign-On SAML applications, be sure to apply a shared "Remembered Devices" policy to your SAML applications.

Troubleshooting

Need some help? Try searching our Knowledge Base articles or Community discussions. For further assistance, contact Support.