Shibboleth Developers

["Scott Cantor" <>]

> 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.

There is no general solution though unless the server supports TLS
renegotiation, and Tomcat doesn't.
 
> 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.

I think it will lead to confusing and brittle error handling. I let the
profile handler decide how to handle it, which permits security to be
applied at different layers at different times if it's called for. I have a
different perspective because I know that a Java SP HAS to do some of the
things I did in order to work. If your rules don't permit for, for example,
signed assertions and no security at the outer layer, they won't work later.

>  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.

I have flags that control that behavior. TLS is a different animal in that
the crypto is always done for you, and all you're checking is trust. If I
had that distinction in my signature processing, I would have split the
error handling and treated trust failures as a silent ignore. Even so, I
still permit it to pass if the deployer chooses. At the end of the process,
the profile will know whether authentication worked or not.

-- Scott