Skip to Content.
Sympa Menu

shibboleth-dev - RE: First complaint - got resolved

Subject: Shibboleth Developers

List archive

RE: First complaint - got resolved


Chronological Thread 
  • From: Scott Cantor <>
  • To: 'RL 'Bob' Morgan' <>
  • Cc: 'Shibboleth Design Team' <>
  • Subject: RE: First complaint - got resolved
  • Date: Fri, 26 Jul 2002 19:20:00 -0400
  • Importance: Normal
  • Organization: The Ohio State University

> Right, we have a looping problem in pubcookie when the
> authentication assertion-equivalent doesn't verify (usually
> due to clock skew at the target, which is an issue for Shib
> too). Seems to me there is a necessity for mod_shire (or
> someone) to be able to display an error page to the user in
> case of assertion failure, since handing back to the app will
> likely cause a loop.

Normally it does, but in a production system, one tends to try and hide
that sort of thing and automatically "solve" the problem for the user if
there's a high percentage chance that a redirect will take care of it.

I got around loops in my system by including an error parameter and a
timestamp in the redirect, so that the central system could recognize
certain kinds of conditions and short circuit obvious loops.

We don't have those at the moment, so I'm trying to be more careful, but
in the general case that the error is caused by *this assertion* such
that getting a new one will help, redirecting back seems harmless.

Contrast that with, say, the case where the issuer is untrusted.
Redirecting back isn't going to fix that, so you stop and report the
problem. Frankly, time is tricky. An expired assertion or IssueInstant
TTL is probably time skew, but could also be caused by the replay cache
expiring the entry because the message is no longer worth worrying over,
so a reloaded POST could also trigger that error.

If it's really time skew, a redirect will probably loop. If not, you
lose a chance to fix the problem, but that's why I'd like to see what I
can do to the form. With a GET-based system, you just expire the
redirects, so the Back button always hits the server again, where you
can detect the problem and do something useful, like send some HTML with
an onLoad event that sends the browser to history(-1).

It may be that I can simulate something similar, if I play with it a
while.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at

http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--




Archive powered by MHonArc 2.6.16.

Top of Page