Shibboleth Developers

[Brent Putman <>]

Scott Cantor wrote:

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?
    

I think that's the key point here. Can Tomcat have different client auth
rules for different ports?
  

I don't know the answer off-hand.  But that assumes that one wants to run front-channel vs. back-channel stuff on different ports.  Which is largely going to be the as we well know, due to often differing requirements for the cert that's used, but it's not 100%.  So that may be the solution here for this specific case, but IMHO isn't really a general solution for the problem I mentioned.

Regardless, should this be "fatal" anyway? My client auth rule doesn't fail
a request if it can't validate the cert, it just doesn't set the secure flag
in the policy for that request.

  

Yeah, I don't know, we can discuss.  I think I modeled the logic after what Chad had originally started, but it actually doesn't necessarily seem wrong to me that it is fatal.  BTW, it is in fact the case for the IdP that for *all* the crypto-related security policy rules currently (client cert, XML signature, simple signatures): if the relevant thingy is present in the request, causing the rule to run its main logic, and it doesn't pass the trust engine, the rule treats it as fatal and throws a SecurityPolicyException.