Shibboleth Developers

[Scott Cantor <>]

> Browsers apparently don't put an entry into their history in this case, so
> that in the common case of constantly-refreshing pages history entries
won't 
> proliferate.  So if the user hits weblogin and already has logged in,
hence
> is redirected back to the target, there is no history entry, so using the
> back button will take the browser to whatever was before the weblogin
page.

I wonder if that would be workable with the SAML profiles or not. Might be
worth a look.

> If the user hasn't logged in before, hence sees the weblogin page, then it
> does show up in history, and will be seen by the user when using the back
> button from the target.  But since pubcookie communicates the login
> request info from target to weblogin in a cookie, and that cookie gets
> cleared by a regular return to the app, when the back button is used the
> user gets to weblogin with no request info.

How does that work? A shared domain cookie? What happens if the target
doesn't share a domain with the weblogin server?

(I realize these are generic pubcookie questions, so feel free to answer
RTFM, just curious.)

> So unfortunately I don't think any of this mechanism applies to Shib.

Not directly, but it all goes into the pot.

> It occurs to me that request state could be cached in cookies in the
> browser to avoid having to maintain it on the HS, and then it would
> naturally go away when the browser closed.  I suppose that might lead to
> cookie-store explosion on the browser though if someone visited the HS a
> lot.

Yes, I'd have to think about that. With a reasonable expiration attached to
the state it's probably manageable. In any case, there should be sufficient
building blocks in the 2.0 profiles to implement many of these mechanisms if
somebody chooses to.

-- Scott