01-13-2022 12:45 PM
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!
Solved! Go to Solution.
01-21-2022 06:19 AM
Sorry, I worked with Duo support. They claim they did nothing but miraculously started working when I was on the phone with them.
01-14-2022 06:35 AM
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:
Does that solution work for you? Please see the thread I linked for more details.
01-20-2022 05:30 AM
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.
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 |
User email address | |
telephoneNumber* | Phone (type Mobile, platform Generic Smartphone) |
mobile* | Phone (type Mobile, platform Generic Smartphone) |
info** | Notes |
01-20-2022 06:35 AM
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?
01-20-2022 08:45 AM
Hello, we have added those attributes in Step 2 to our DAG. Issue remains. Thanks.
01-20-2022 01:47 PM
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.
01-21-2022 04:37 AM
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
01-21-2022 05:47 AM
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.
01-21-2022 05:53 AM
Spoke with Support, not sure what they did but while I was on the phone with them it started working. Thanks for your assistance.
01-21-2022 06:08 AM
Glad it is working now!
QQ: Do you mean DocuSign support or Duo support in your last response?
01-21-2022 06:19 AM
Sorry, I worked with Duo support. They claim they did nothing but miraculously started working when I was on the phone with them.
01-21-2022 06:29 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide