[Shib-Users] The certificate requirement on the browser

[wz qiang]

hello,
I was testing my sp and idp installation against TestShib2.0.
I installed idp (under tomcat, port 8443) and sp (under apache httpd, port 443) on the same machine. The Login profile is IP cheking. Everything seems well.
But I have a question when I test my idp against TestShib 2.0. 
The tomcat config is :
   <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" disableUploadTimeout="true"
               acceptCount="100" scheme="https" secure="true"
               clientAuth="true" sslProtocol="TLS"
               keystoreFile="/home/scratch/wzqiang/shibboleth-idp/apache-tomcat-6.0.18/conf/keystore.ImportKey"
               keystorePass="aa1122"
               truststoreFile="/home/scratch/wzqiang/shibboleth-idp/apache-tomcat-6.0.18/conf/keystore.ImportKey"
               truststorePass="aa1122" truststoreAlgorithm="DelegateToApplication" />

I switch off the ClientAuth for  shibboleth.SAML2SSOSecurityPolicy  in relying-party.xml

On the browse, when I access https://sp.testshib.org and test against my idp, the browser requires certificate. But it seems I can use any pkcs12 certificate (no matter it is trusted by the trusted keystore configured in tomcat).
So I would ask is that the keystore configuration in tomcat does not effect any way? And the certificate on the browser is also does't effect?

The other question is about the "shib-cert.jar" (need configuring truststoreAlgorithm="AnyCert"). Is this package the same as the "DelegateToApplication"?

Thanks
Weizhong Qiang

[Nate Klingenstein]

Weizhong,

You need to look at the port 443 configuration to understand why there is a check for a certificate being presented to your client.  I bet there's something wrong there.  The port 8443 configuration won't result in this prompt, because your browser never contacts the IdP on that port.  You should probably turn ClientAuth back on unless you're going to use certificate-based user authentication in the future.

The keystore configuration determines what Tomcat will present to the client.  The truststore configuration determines what Tomcat will trust.  DelegateToApplication( the same as AnyCert, with a more appropriate name) tells Tomcat to trust any certificate at all.  That makes the truststore configuration meaningless, because the IdP will do the certificate checks against metadata.

Take care,

Nate.

[wz qiang]

hello,

On Mon, Sep 8, 2008 at 11:49 PM, Nate Klingenstein <n...@internet2.edu> wrote:

Weizhong,

You need to look at the port 443 configuration to understand why there is a check for a certificate being presented to your client.  I bet there's something wrong there.

It is not relevant to the 443 (httpd). But it seems it does not require browser certificate any more with the ClientAuth (for SAML2 SSO profile) switched off. The former problem I reported could be caused by the cache in the browser cache.
 

 The port 8443 configuration won't result in this prompt, because your browser never contacts the IdP on that port.  You should probably turn ClientAuth back on unless you're going to use certificate-based user authentication in the future.

With the ClientAuth (for SAML2 SSO) switched on, it requires a certificate on browser. Since now I an only using the IP checking Login Handler, I think I just switch it off curretly.
 

The keystore configuration determines what Tomcat will present to the client.  The truststore configuration determines what Tomcat will trust.  DelegateToApplication( the same as AnyCert, with a more appropriate name) tells Tomcat to trust any certificate at all.  That makes the truststore configuration meaningless, because the IdP will do the certificate checks against metadata.

The metadata only include the peer certificate, so it is only for cheking the validity of message's signature, it is not for message authentication because no trusted certificate is included here?

Thanks
Weizhong
 

[Nate Klingenstein]

Weizhong,

The trust in Shibboleth is derived from verification of the peer's certificate, just like in any other certificate-based system.  The only difference here is that Shibboleth checks the certificate presented by the service provider against the service provider's metadata, rather than Tomcat checking the certificate presented in TLS against its own truststore.  Shibboleth can use either the signature of the XML message itself, or a certificate presented during the TLS handshake.

Take care,

Nate.