intermittent IDP failure

[Cantor, Scott]

On 1/28/13 1:22 PM, "Steven Carmody" <steven_carmody at brown.edu> wrote:
>
>The typical situation has a user logged into 3+ Shib-enabled SPs, and
>switching between them.  At some point, the IDP presents the user with
>an error screen. We *think* the underlying error from the logs is:
>
>No SAMLRequest or SAMLResponse query path parameter, invalid SAML 2 HTTP
>Redirect message

Well, that usually is a back button issue. It's not something you can
prevent, which is why I catch them and handle all back button issues
generically. It is a problem in the logs, but it's not something you can
handle from a user experience point of view other than by saying that's
what happened.

>We think what happens is the user logs into an SP; the next time they
>access that SP they actually get sent to a different machine in the
>cluster; that machine has NO SAML session, so it sends the user to the
>IDP. Under normal circumstances, SSO at the IDP would handle this. But,
>for unknown reasons, sometimes the user is presented with the error.

No, I don't think so.

>The logs don't contain the HTTP command that the SP actually sent to the
>IDP (I suppose we could sit apache in front of our IDPs, and use the
>apache logs to capture that info). But, I have no reason to believe that
>the SPs aren't sending the query parameter when they clearly send it
>most of the time.

You don't have to run Apache to get server access logs, that's the job of
your web server. I run Jetty and I configured it to give me the logs I
wanted.

>There's strong local suspicion of terracotta as the source of the
>problem... a couple of people edited their desktop /etc/hosts file to
>point to just one of the IDPs (rather than the load balancer), and they
>ran all day without the problem.

Try hitting the back button.

The other option is that you have a web proxy that is destroying request
information, but it's far more likely that you're accessing the SSO
service with no login context set and no parameters, and that's the error
you get when you do that.

It's also possible that you have an issue with your cluster and the login
context state, but I don't run Terracotta, so I couldn't comment on what
to look for.

-- Scott