Salesforce error when authing against Shibboleth

[Cantor, Scott]

On 8/8/14, 5:17 PM, "Ben Branch" <BBranch at uco.edu> wrote:
>
>It appears that the problem I have been experiencing is an issue with
>attribute releasing.

Then they have a serious bug in their validation reporting tool. Possible,
certainly.

>  I thought I had this configured properly, but it appears I do not.  I
>can't get the aacli.sh script to work ( I get java errors about a
>classpath) to test this.

That doesn't imply anything about attribute release to a service. Your
logs will tell you anything you need to know about that.

>Does the SSL cert that is loaded into Tomcat need to be the same one that
>is used by the IDP itself (the idp.crt used for metadata needs to be the
>same cert used for SSL)?

The back channel SOAP port generally uses the same keypair, but doesn't
have to. That has nothing to do with most SAML 2 SPs (or anything but
legacy Shibboleth in fact), they don't rely on queries to get attributes.

>  Currently, I have a wildcard certificate loaded on this server, and I
>do not have the idp.jks loaded on any other ports. Do I just need to
>create a new port connector in my Tomcat configuration and load idp.jks
>onto that port?

If you don't need SOAP suport, then you don't deploy or support it, don't
put it in the metadata, and it's irrelevant. If you need SOAP support, you
need to configure it properly, and that includes using a key which you
provide in the metadata, whether it's the same as your signing key or not.

Under no circumstances should you ever use a commercial certificate on any
SAML facing service endpoints.

>Testshib.org SP Log: http://pastein.com/Kn7pyttK
><http://pastebin.com/Kn7pyttK>

That's a SAML 2 query, which means it's just wasting its time. You don't
need to support that. You didn't release any attributes in the first
place, and that just causes a superfluous query because of the way the SP
is configured by default, and because your metadata includes the query
endpoint.

-- Scott