Shibboleth IdP Issuer

[Kevin P. Foote]

On Wed, 13 Mar 2013, Rawlinson, Philip (rawlinpa) wrote:

>> "more likely your IdP environment is misconfigured and not handling client TLS."
>
> Based off of Scott's feedback, we have been investigating our TLS settings. We are running Tomcat6, not fronted by Apache, and our server.xml has the Connector configurations from https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepare
>
> To recap, we are working on trying to get a SAML1 connection working on our IdP, but we seem to be having an issue with client certificates getting through our load balancer (F5 BigIP). The error we get is a TLS issue where the SP (using EZProxy) is not trusted by our Shibboleth IdP. From what we understand, the issue is the Attribute Authority is using a self-signed cert on the backend, which matches our InCommon Metadata certificate per what is recommended, but our front-end IdP/AA URL is using an InCommon signed certificate.
>
> When we removed SSL handling on BigIP as a test, the user gets a prompt for a client certificate in their browser. If you present a certificate, there is a proper SAML1 trust between our IdP and the SAML1 SP and the attributes are successfully communicated to EZProxy. However, this is not possible as we obviously do not want actual users to have to present a certificate to authenticate. It seems as though BigIP will drop the Client Certificate because it does not require it, but our SAML1 client does require it to be passed through, so we were in a bit of a bind. Does anybody know of a way to pass a client certificate through BigIP even when it is not really needed? We are posting this to the F5 forum as well, but perhaps someone here has experienced a similar problem before or has another idea to fix our issue.
>

The way I have (and I think that is recommended) my load-balancer set up
is to process the normal (browser) ssl traffic at the balancer.
Usually something like "Terminate SSL at load balancer". This is for
port 443 ..

The second VirtualServer at the load-balancer (port 8443) is ssl pass through 
which just passes the traffic through to the backend.

Not sure if this is what your getting at or if this is what you have
tried .. But 8443 traffic should just flow 'straight through' the load
balancer on second VS.

------
thanks
  kevin.foote