DocuSign SSO issues on Dev environment.

[Cantor, Scott]

On 11/30/16, 4:17 PM, "users on behalf of Dr_Natas" <users-bounces at shibboleth.net on behalf of Juan.Rios at csuci.edu> wrote:

> One word "Docusign".

6 words: tell me the specific SAML requirements.

What do you *need* the IdP to do? If you can't answer that, then Docusign failed to document their system, but I can't psychically derive the requirements. I use Docusign, but we have Okta in the middle because that was the legacy Docusign platform, so I don't know the requirements of their newer one.

> Can someone take a look at my saml-nameid.xml to verify that it looks good. 

Tell me the requirements.

You are using "unspecified". Don't.
 
Second, you don't generally need to use conditions there. Just filter the underlying attribute as required.
    
Third, I can't think of anything good coming from calling a resolved attribute "NameID". That's horrendously confusing. Don't do that. 

> Alaska University discovered that Docusign forces you to disable encryption. 

The best way to disable encryption for any SPs that don't have keys in their metadata is to set idp.encryption.optional to true. Avoids any need for relying-party overrides in 90% of cases, simplifying things considerably.

> Self Note: Debugging is on for my test environment. Revert back to Info only. 

Just stop using DEBUG on every category. That's much harder to follow. Spring logging is off for a reason.

> Some how I don't think my settings for my Attribute-Resolver.xml are up to par. 

Well, they don't make sense, no. You're using a deprecated feature to tell it to encode a value that apparently contains an employee ID to a transient Format identifier. That's inappropriate. It may or may not be causing problems, but that would depend on what exactly the IdP is sending over, which you can get from the logs or by using aacli with the --saml2 option.

>    Code for "metadata-provides.xml"

Do not load metadata from a remote source without a signature verified with a key obtained out of band. That's not secure, certainly not without limiting the validity window. And you almost certainly will need to change it anyway, because that's where you should specify the required NameID Format you need to send it. Their metadata probably won't contain that, so you need to get it out of band, verify it, and then adjust it appropriately and load it locally. That's how you deal with the vast majority of vendors.

> Disabling Encryption for "relying-party.xml"

You don't need to do that as I noted earlier, and if you modify the metadata to request the appropriate NameID Format, you won't need an override at all.

>  I enabled these just in case, but it still didn't work. 

Doing anything "just in case" is a recipe for failure. If you don't understand it, don't touch it, ask what it means first if the documentation doesn't explain what it means adequately.

-- Scott