Shibboleth Developers

[Brent Putman <>]

 wrote:
> At 1:03 PM -0500 12/12/07, Scott Cantor wrote:
>>
>> An SSO request doesn't need Apache or Tomcat to pass in the certificate,
>> it's inside the message (or it's a redirect and it isn't there ever).
>>
>
> looking at the IdP logs:
>
> 1) the msg went here:
>
> stc-test11.cis.brown.edu:8443|/profile/saml2/Redirect/SSO|
>
> 2) after decoding, the security processing starts:
>
> 12:47:06.277 INFO
> [org.opensaml.common.binding.security.SAMLProtocolMessageXMLSignatureSecurityPolicyRule:99]
> - SAML protocol message was not signed, skipping XML signature processing
>
> 12:47:06.278 DEBUG
> [org.opensaml.common.binding.security.BaseSAMLSimpleSignatureSecurityPolicyRule:63]
> - Evaluating simple signature rule of type:
> org.opensaml.saml2.binding.security.SAML2HTTPRedirectDeflateSignatureRule
>
> 12:47:06.280 DEBUG
> [org.opensaml.common.binding.security.BaseSAMLSimpleSignatureSecurityPolicyRule:86]
> - HTTP request was not signed via simple signature mechanism, skipping
>
> 12:47:06.281 DEBUG
> [org.opensaml.common.binding.security.BaseSAMLSimpleSignatureSecurityPolicyRule:63]
> - Evaluating simple signature rule of type:
> org.opensaml.saml2.binding.security.SAML2HTTPPostSimpleSignRule
>
> 12:47:06.282 DEBUG
> [org.opensaml.common.binding.security.BaseSAMLSimpleSignatureSecurityPolicyRule:80]
> - Rule can not handle this request, skipping processing
>
> 12:47:06.296 DEBUG
> [org.opensaml.ws.security.provider.ClientCertAuthRule:135] -
> Attempting client certificate authentication using context issuer:
> https://stc-test11.cis.brown.edu/Shibboleth.sso/Metadata
>
> 12:47:06.307 DEBUG
> [org.opensaml.xml.security.trust.ExplicitKeyTrustEngine:68] -
> Attempting to validate untrusted credential
>
> and fails......


Yeah, this log flow clearly indicates that there is a client TLS cert
being presented in the request.  If there wasn't a client cert, that
would be indicated by a different log message on DEBUG.  So that doesn't
jib with the fact that this appears to be HTTP-Redirect, unless things
are seriously horked up, or.......

Could be that the browser is the thing presenting the client cert here,
not the SP (in fact has to be, unless there is serious horked-up-ness). 
This has occurred to me as a potential problem, esp for the IdP but also
the SP, but I had not had a chance to test out yet.  We may need to make
the inclusion of the client cert auth rule in the effective security
policy dependent on whether it's a front channel or back channel
binding.  If it's front channel, then the client browser might
legitimately be presenting a client cert to the IdP (or less obviously
to the SP) because that might be how users authenticate to the IdP.  But
the existing client cert rule can't handle that, obviously.  So we may
need 2 security policies - one for the front-channel case, one for
back-channel. 

Don't know if that's the issue here, but could be.  Maybe the Tomcat
SSL/TLS config is causing Tomcat to require the cert (from the browser
perspective), as where our standard Apache config doesn't?