Login diversions

[Chad La Joie]

So, various comments on this.

First, IdPv3 does have a much more flexible and pluggable way of
adding new stuff to a given request processing flow through it's use
of Spring WebFlow.  You can go look at the documentation for that to
see what the flow definition files look like.

Second, the IdP is *not* an identity management system and it never
will be.  I personally would not trying to do account management taks
in-flow at the IdP.  For one customer who wanted something like this I
specifically recommended that they simply pop open a new window that
had the password management aspects of their IdM system and, at the
end, close that window (now they're back at the IdP authn window).
The user then logs in with their new account/password.  Forcing the
user to type in the password immediately after creating/changing it
helps reinforce the learning of it which is a good thing.

Lastly, what you're talking about specifically is the creation of yet
another custom SSO protocol.  We won't be doing that in the IdP
either.

On Fri, Nov 4, 2011 at 13:08, Christopher Bongaarts <cab at umn.edu> wrote:
> 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    %%
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net
>



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