Salesforce error when authing against Shibboleth

Ben Branch BBranch at uco.edu
Fri Aug 8 17:42:32 EDT 2014


> 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.


So...then do I just comment out these 2 lines in my idp-metadata.xml?  Or is there something more that I need to do?  I have an LDAP Data Connector configured and what I believe to be properly configured attribute-filter and resolver.

<AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://casdev.uco.edu:8443/idp/profile/SAML1/SOAP/AttributeQuery"/>
<AttributeService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://casdev.uco.edu:8443/idp/profile/SAML2/SOAP/AttributeQuery"/>

Ben Branch
UNIX/Linux Administrator
University of Central Oklahoma
ITIL Foundation v3, Network+, RHCSA

100 N. University Drive, Box 122
Edmond, OK 73034
D: 405.974.2649 | M: 405.550.6804 | bbranch at uco.edu | www.uco.edu

"I am wiser than this man, for neither of us appears to know anything great and good; but he fancies he knows something, although he knows nothing; whereas I, as I do not know anything, so I do not fancy I do. In this trifling particular, then, I appear to be wiser than he, because I do not fancy I know what I do not know."  - Socrates


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, August 08, 2014 4:26 PM
To: Shib Users
Subject: Re: Salesforce error when authing against Shibboleth

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

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
**Bronze+Blue=Green** The University of Central Oklahoma is Bronze, Blue, and Green! Please print this e-mail only if absolutely necessary!

**CONFIDENTIALITY** -This e-mail (including any attachments) may contain confidential, proprietary and privileged information. Any unauthorized disclosure or use of this information is prohibited.


More information about the users mailing list