DocuSign/Okta and Shibboleth

[Kanuch, Andrew]

I don't have a working solution yet, but I'm having the exact same issue as you, and getting the exact same canned responses.

________________________________________
From: users-bounces at shibboleth.net <users-bounces at shibboleth.net> on behalf of Marwan Shaher <Marwan.Shaher at Colorado.EDU>
Sent: Monday, March 2, 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