assertion not always signed

[Cantor, Scott]

On 1/13/17, 8:44 PM, "users on behalf of Rich Graves" <users-bounces at shibboleth.net on behalf of rgraves at carleton.edu> wrote:

> Just one server, pretty simple. What knob in logback.xml would be best to trace that?

The audit log would show a different entityID on the different responses if it were something that simple. I would be modifying the audit log to include the most detail possible on the request, response, all bindings used, etc. and comparing them in case something unusual shows up. You can always temporarily add a separate audit format while it's being looked into without affecting your regular audit handling if that's getting parsed by something.

If there were a bug I can't imagine it not showing up by now, but if you're running 3.3, get a trace with everything down to the bare metal on DEBUG and file it, I guess. Since you have response signing off, I guess if there's a bug, it could be something unrelated to the *reason* it would sign, but a quirk in the spot where the signing occurs that's preventing it for some reason. I can't imagine what, but that seems like the only plausible cause.

Like any bug, the problem is reproduction. If you have to run at full DEBUG that just kills performance, it needs to be deterministic to have a prayer at catching it. I guess you could try the async appender thing in logback, we have all that wired up for enabling, supposedly that helps a lot on DEBUG for a live system.

> For want of a cat to swing around at midnight, I guess we could reconfigure the Office365 end to use HTTP-Redirect and
> see if things improve?

There's nothing in a SAML request to signal signing behavior at either layer.

-- Scott