Shibboleth SP 2.4.3 and ExplictKey TrustEngine - SOAP 8443 vs other

[Marc Thornton]

Minor update:

In further testing, I found an issue with my Apache configuration when I
initially tested 9443... with everything properly configured, 9443 does
work... 8445 (our previous configuration) continues to give failures.
 Other comments inline.


On Thu, Dec 1, 2011 at 11:38 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 12/1/11 11:05 AM, "Marc Thornton" <joey.granville at gmail.com> wrote:
>
> >We have recently upgraded to Shibboleth SP 2.4.3 from Shibboleth SP
> >2.3.1.  Supporting libraries had been previously upgraded to 2.4.3
> >"levels" to resolve the XML signature vulnerability, hence only the
> >Shibboleth SP software has been upgraded in this pass.
>
> Unless you were building from source, you couldn't use the newer libraries
> with a 2.3.1 SP. So I assume you did that, but just making the point in
> case there's something off about your build, and because that leaves open
> to question what the build process is.
>
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).

>We are using artifact resolution to transport our assertions, hence
> >SOAP/TLS validation is part of the authentication process.
>
> Since it comes up from time to time, any reason for that?
>
Our client base of Service Providers is completely internal to our network.
 We decided early on that the increased security of providing assertion
details over SOAP was worth the overhead of firewall rules/connectivity
between the various systems on the same network.  We would never have
considered it had we been serving external Service Providers.


> >Since upgrading to Shibboleth SP 2.4.3, the ExplicitKey TrustEngine seems
> >to work only for validating SOAP/TLS over port 8443.. attempts to
> >validate against the same web server certificate over 8445 or 9443 fail
> >for no apparent reason. I've confirmed that ExplicitKey TrustEngine gave
> >us a successful match over non-8443 ports on the previous release.
>
> The SP on top has nothing to do with this step. The TLS is OpenSSL, the
> HTTPS is libcurl, the cert evaluation (the trust engine) is xmltooling,
> and the metadata is opensaml. So if you had some particular version of
> those working, and then upgraded only the SP on top, none of that would
> change.
>
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.

>The section of logs at debug level is below:
>
> I don't see any sign of session resumption, so all I can say is, whatever
> cert it's getting back is not what's in the metadata.
>
> I thought libcurl on DEBUG would log the cert from the handshake though.
> It's not there?
>
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.

Are you using the official packages at this point?
>
Yes, all packages other than the Shibboleth SP are official packages.


> I don't know if it's possible to do it, but I would also try swapping
> which endpoint is which on the IdP end, and see if it consistently fails
> with that port, or instead with the certificate.
>
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
   - 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.

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.  Since the
cert in the IDP metadata and the web server cert are generated based on the
same private key, they share the same public key as well.  (I think I
gained a few more gray hairs until I figured that particular piece of
information out)

-- Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20111201/2df75f2a/attachment-0001.html