Login diversions

[Christopher Bongaarts]

In the process of converting our IDM infrastructure from our existing 
web SSO service to Shibboleth, we have a couple places where our 
existing workflow isn't fully supportable with the Shib IdP.  I suspect 
these scenarios might be more generally applicable, and if so there may 
be ways that IdP 3 could be structured to work with them.  (Or maybe 
there are better ways to achieve the same functionality...)

When a user forgets their password, we prompt them to answer of set of 
questions whose answers they previously shared with us.  Upon answering 
correctly, they are then prompted to enter a new password.  At this 
point, they should be considered SSO-authenticated and not have to 
reenter their password to log in to other sites.

The catch is, the password changing service is moving to Shibboleth 
authentication.

Our current strategy: we reuse our existing SSO cookie to indicate that 
the questions were answered correctly, and the user is then considered 
fully authenticated by our custom IdP LoginHandler.  Then,  we look at 
the SP that is requesting authentication.  If it is the password 
changing application SP, then the authentication succeeds and the user 
can proceed with the password change.  If not, they are shown an error 
page.  We're punting on "forcing" the user to change password 
immediately - if they choose not to, then they will have to go through 
the hassle of answering the shared-secret questions again on their next 
login.

The main problem remaining in this case is that the user gets dead-ended 
after changing their password, because the login context from the 
original SP's authen request would be lost in the process of getting 
logged in to the password changing SP.

To me this seems like one aspect of a more general case: of 
authentication requests being interrupted or diverted, requiring the 
user to authenticate to another SP to perform some action before the 
original authentication can be continued.

One way to support this would be to have a "stack" of login contexts. 
When you divert someone to a second SP, the new login context doesn't 
overwrite/replace the first one, but is added to it.  You might need to 
have some signaling in the protocol to indicate to the SP that when it 
is "finished", it should send the user back to a designated endpoint on 
the IdP so that they can complete the previous authen request and get 
back to the original requesting SP.

I'm also interested in alternative ways to handle this, as long as it's 
not "build your password changing app into the IdP". ;)
-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%