DocuSign Identity Provider

Having issues getting the DocuSign application working following these instructions: Duo Protection for for DocuSign with Duo Access Gateway | Duo Security

Getting this error when trying to access Docusign.
“The response assertion is missing a required attribute”

Still waiting for DocuSign support to get back to us so I thought I would check here is anyone was successful in setting this up.

Thanks!

Hi Nate, I found a post in the DocuSign community on how to solve the error “The response assertion is missing a required attribute”. Someone there was able to resolve this by doing the following:

  1. Fill out the user attributes and claims in Azure:
    • given name - user.givenname
    • surname - user.surname
    • email address - user.mail
    • name - user.userprincipalname
    • Unique User Identifier - user.userprincipalname
  2. Make sure that all users have a first name, last name, and email in the system.

Does that solution work for you? Please see the thread I linked for more details.

Any advice on how to do this with Azure? We are hybrid AD/Azure.

All users do have first/last names and email in the system. What’s concerning is that it looks like in Duo it only has the “Full Name” field. According to Duo areticle below, surname/last name not synced.

What Active Directory attributes are synchronized to Duo?

The following table lists the default Active Directory attributes synchronized to Duo, along with their corresponding Duo attribute mappings:

AD Attribute Duo Attribute
CN Group name
sAMAccountName Username
displayName User full name
mail User email address
telephoneNumber* Phone (type Mobile, platform Generic Smartphone)
mobile* Phone (type Mobile, platform Generic Smartphone)
info** Notes

Duo is not sending user attribute values imported via sync directly to Docusign SSO situations. Duo’s IDPs (DAG or Duo SSO) search for the attributes in the configured source directory and returns them in the SAML response to the service provider.

In the Duo Docusign instructions, did you add the mail, givenname, and sn attributes to your DAG AD authentication source’s config as mentioned in step 2 here?

Hello, we have added those attributes in Step 2 to our DAG. Issue remains. Thanks.

So you can enable debug logging for your DAG and then try to log in to DocuSign again.

Then, open up the dag.log and look for this…

  • find the lines that say LDAP getAttributes():. Are all the attributes you expect listed there and successfully found?

  • find the line that says Sending SAML 2.0 Response and look through all the XML of the saml response to get to the <saml:AttributeStatement> section. That section lists the attributes included in the saml response to DocuSign. Are all the attributes you expect listed there and do they have values?

If this doesn’t help you figure out why the attributes aren’t getting sent in the SAML response it’s a good idea to open a case with Duo Support.

Hello,

Not able to find " `LDAP getAttributes():" in the DAG log.

It does not look like the DAG is sending “givenName” and “sn” attributes. Here is what is sent in the saml:AttributeStatement

saml:Attribute Name=“sAMAccountName”
saml:Attribute Name=“userPrincipalName”
saml:Attribute Name=“mail”
saml:Attribute Name=“duo_username”
saml:Attribute Name=“emailaddress”

This is the DAG attributes entry:
mail,givenName,sn,sAMAccountName,userPrincipalName,objectGUID,extensionAttribute1

I’m not sure here. I double-checked the DocuSign JSON that gets uploaded to DAG and it includes surname and given name, so if found in the source directory they should be in the SAML response.

Your best next step is to open a case with Duo Support.

Spoke with Support, not sure what they did but while I was on the phone with them it started working. Thanks for your assistance.

Glad it is working now!

QQ: Do you mean DocuSign support or Duo support in your last response?

Sorry, I worked with Duo support. They claim they did nothing but miraculously started working when I was on the phone with them.

1 Like

Ah, interesting. There isn’t anything we can do from our end to change the config or response sent by your on-prem DAG (it’s not like it is connected to our service for us to push modifications). What it might have been is that something was cached and once that cleared itself it was OK. I’m mildly curious so I might try to find notes from your case on our end, but I am glad it is working now.