Shibboleth SP 2.4.3 and ExplictKey TrustEngine - SOAP 8443 vs other

[Cantor, Scott]

On 12/1/11 12:40 PM, "Marc Thornton" <joey.granville at gmail.com> wrote:
>
>Yes, we do build our own SP from source, unchanged except for packaging &
>"standardized" configuration files that we provide to our internal
>clients for installation consistency. This approach also allowed us, as
>you surmised, to drop in the OpenSAML digital signature vulnerability fix
>in a shorter timeframe, while retaining the same source release for the
>Shibboleth SP (and hence, assured SP configuration compatibility).

Just FYI, the SP already assures this. In fact, much of the internal
configuration content found in various elements of the files is for
plugins provided by the lower libraries. It's as likely to get a
regression in those as with the SP itself.

>That is what went through my head as I investigated this... although it
>also occurs to me that the SP could have changed how it initialized or
>made calls to  these supporting libraries in between releases.

It's possible, yes, but not likely. I can't think of any obvious way it
would manifest like this. I could absolutely understand a regression or
problem in the libraries themselves, but that would show up with the old
SP using them.

>Unfortunately, it doesn't look like it logs any certificate details until
>the (per the log) X509 Callback completes successfully.  Since it fails
>on the callback, no further information on the certificate is logged.

Must be something libcurl does, I guess, I never noticed. That's kind of a
hassle. If you're building at least some of it from source, I guess an
obvious possibility is to dump/log the certificate the callback is
evaluating. I can certainly look at adding that and/or point you to the
relevant spot, but it's not in the SP obviously.

>That is pretty much what i've been doing...
>   - Update SP's copy of idp-metadata to use 8445 for
>AssertionConsumerService
>   - Update IDP's copy of idp-metadata to use 8445 for
>AssertionConsumerService

You mean the ArtifactResolutionService?

>   - Update apache configuration Listen, VirtualHost and ServerName
>directives to identify 8445... restart it all... authentication fails at
>SAML Artifact lookup...
>
>Do the same with 8443 or 9443, identical self-signed web cert and key...
>success.

That's mystifying. I assume you did something to connect directly to that
port and just make absolutely certain Apache is serving up that
certificate? Browser or openssl s_client.

>Note that the certificate for the self-signed web server cert itself is
>not included in the IDP metadata, but that seems to be irrelevant as the
>ExplicitKeyTrustEngine only compares public keys components (modulus,
>exponent) to determine a match, never the certificate details.

That's true, yes. I wouldn't say it's a good idea to go that route since
basically no other software but ours does that (only we implement the
profile in question where that's codified). But for sanity checking sake,
did you try actually putting that certificate into the metadata?

-- Scott