Applications that autorefresh

[Chad La Joie]

Well, if the SP is redirecting automatically that means they're using
eager sessions.  I would recommend changing the SP to use lazy
sessions and to display a "Your session has timed out, please click
here to login again" page when appropriate.

To your other question, the IdP's profile handlers and its
authentication engine are separate things.  What you're suggesting
would require that the authentication engine understand the serialized
state and know how to deserialize it.  That would make an already
complex beast (the authentication engine) more complex and would
prevent new protocols from being added to the IdP without updating the
authentication engine as well.

On Mon, Jul 16, 2012 at 5:19 PM, Christopher Bongaarts <cab at umn.edu> wrote:
> [I'm starting this thread here in case of workarounds, but I'm happy to
> move to dev@ if it starts to drift towards code fixes...]
>
> Suppose not-so-hypothetically we had a Shib-protected application that
> many users keep open in their browser all day, and it has a META REFRESH
> or equivalent mechanism that causes the protected page to be reloaded
> periodically.
>
> At a certain point, the user's authentication will time out on the SP
> side, and the user will be sent back to the IdP to reauthenticate.  The
> SP's session timeout is set longer than the IdP's timeout (8 vs. 3
> hours), so SSO will not activate, and the IdP puts up a form to let the
> user authenticate again.
>
> The problem is that the user left their browser open and went home.
>
> The user comes back in the next day, finds the window for the
> application and sees that they need to log in.  But by now, the
> loginContext has expired at the IdP, and the user is not only faced with
> an error message after trying to log in, they are stranded and can't get
> back to the SP unless they start all over again.
>
> Has anyone encountered a similar situation?  Has anyone come up with any
> clever workarounds or fixes?
>
> In this particular case, I control the (only) IdP, and can suggest
> settings for the (Shibboleth 2.4.x) SP that would likely be implemented,
> but I'm also curious about the general case.
>
> Brainstorming a bit, would it make sense to try to "serialize" some or
> all of the loginContext into the login form so that some or all of its
> state could be preserved across the evening?  Would the SP side have to
> tweak something to keep relay state and such around that long?
>
> In our old SSO system, the "return to..." state was included in the
> login form, so users could simply enter their credentials and they were
> right back where they left off.
>
> --
> %%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
> %%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
> %%  University of Minnesota    %%  +1 (612) 625-1809    %%
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered