Uncaught Exception while proxying to Azure

The second change has been reverted, as it causes problems with our auditing code and without more work actually breaks the response handling during the InResponseTo check. It wasn't really part of the original problem.

OK, that would explain a number of things.  🙂  I went back and re-ran it with SAML tracr and am seeing it being set now in Chrome.  So I'm chalking it up to a bad validation procedure on my end.

I've fixed the primary bug and shored up the behavior of the servlet on replay, so this is as robust as it will get, but the actual "title" of the issue is just fact. If the container session times out or is simply reset/changed because of cookie behavior, the IdP is going raise the "no such flow" exception and that will always be the case. The only fix here was just to make sure it's a controlled exception and not a runtime error.

The session timeout here is of course up to the deployer, that's not an IdP setting. But setting it too long will consume more memory of course.

I've played around a bit artifically and managed to reproduce a couple of different aberrant results by manually replaying specific URLs in the flow sequence. One of them can trigger the exception about the class already being added to the tree that I did fix.

With Firefox at least, I'm not seeing any practical way to actually reproduce this as a user because the whole sequence is redirects up until I hit my (proxied) IdP, so the back button just goes straight to the very beginning and skips over the intervening steps that cause problems.

My guess is perhaps Chrome is different, or that if Azure happens to use the POST binding for the request step, that might introduce more opportunity for a back button bug.

In any case, if I replay the right URL, I can get it to attempt to pass through the external servlet a second time as part of the same conversation and trigger the exception, which is now patched anyway. I think this is an artifact of the flow being "paused" by that external redirect and so the state of the conversation actually hasn't advanced yet. It's rather like reloading the login form, which just re-executes the same view state and updates the s number.

The other interesting side effect is that if I patch that bug, or if I just directly replay the external servlet request URL, it re-encodes the same AuthnRequest, which triggers a replay error on my proxied IdP. I suspect Azure does not do anything about replay, but it's easy to notice with a compliant IdP.

Because of where signing happens, I'm inclined to go in and perhaps adjust things so that some of the AuthnRequest fields are set in the servlet in realtime so that this kind of replay of the request should actually work.

You're not looking at the IdP, you're looking at our Jira (the domain is ours, not yours).

I meant web.xml, if you changed it and then upgraded to a version with the filter you'd have to add the filter yourself to get it installed.