DocuSign/Okta and Shibboleth

Marwan Shaher Marwan.Shaher at Colorado.EDU
Mon Mar 2 17:56:13 EST 2015


Hello all,
Does anyone have a working DocuSign, using Okta as an intermediary, 
implementation working in their environment? We are trying to integrate their 
SP with our test IdP environment, running Shibboleth ver. 2.4.4 . We are 
releasing email address to them as a NameID and had to turn off encryption for 
their SP per their requirements. 
When a test user tries to go the DocuSign demo link, instead of getting 
redirected to our Idp login page, the user is presented with an error page by 
our Idp indicating that the "Message did not meet security requirements".
We are seeing this in the Idp logs:
-- begin: log 1 ----
"WARN  e.i.m.s.i.p.saml2.SSOProfileHandler - Message did not meet security 
requirements
org.opensaml.xml.security.SecurityException: SAML message intended destination 
(required by binding) was not present" 
-- end: log 1 ----

The AuthnRequest from Okta is signed, but it is missing the "Destination" xml 
attribute and value, as the log shows below:
--- begin: log 2 ----
<?xml version="1.0" encoding="UTF-8"?><saml2p:AuthnRequest 
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" 
ID="id85693470438946851668805830" IssueInstant="2015-02-25T22:27:04.149Z" 
Version="2.0">
   <saml2:Issuer 
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://www.okta.com/saml2/service-provider/sp2x0eh4lIUXZHMYYHUM</saml2:Issuer>
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
.....
.....
--- end: log 2 ----

>From what we've gathered from the"Binding for the Oasis SAML v2" document at 
http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf  if the 
SAML request is signed, which it is in this case, then it MUST have the 
"Destination" xml attribute and value (line 661). We've taken this information 
back to DocuSign and they came back with "This is the same configuration that 
we are using for the 12 or so other higher ed institutes that have it setup 
successfully." We seem to think that this is happening way early on at the 
SAML request, that there is really no configuration change that we can do on 
our end to make this work. Are we missing something here or should we continue 
to push the SP to fix it from their side?
We appreciate any insight about this.

Thank you,

- Marwan


More information about the users mailing list