DocuSign/Okta and Shibboleth

[Royder, Kyle D]

Hello Marwan,

I recently integrated our IdP with Okta for use with DocuSign and  ran into the exact same issue and came to the same conclusion you have.  They fixed it on their side for us after I pushed for it.  Once Okta fixed the issue and the SAML request came in with Destination populated, things worked.  DocuSign and Okta are separate companies and seemed to be pretty disconnected when trying to integrate and get questions answered, so make sure you ask Okta directly and copy your DocuSign contact. 

This is our example SAML request AuthnRequest from Okta with destination populated for us:
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                     Destination="https://idp.its.utexas.edu/idp/profile/SAML2/POST/SSO"
                     ID="id33895944071249741540525824"
                     IssueInstant="2015-03-02T23:20:38.452Z"
                     Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://www.okta.com/saml2/service-provider/X</saml2:Issuer>
...

Also, just another gotcha.  Once we got passed that issue and we were setup to release email in subject NameID, we ran into a second issue where their side was setup with a NameIDPolicy other than <saml2p:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> in the SAML request.  They were able to change the format the response should be in on their side and that was correctly reflected in the next request.  So, I would also see what that value is currently set at the end of the SAML request.  This also took a few tries to get right since they said they haven't had to change it before for others.

Thanks,
Kyle

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Marwan Shaher
Sent: Monday, March 02, 2015 4:56 PM
To: users at shibboleth.net
Subject: DocuSign/Okta and Shibboleth

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
-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net