Shibboleth Developers

[Christopher Bongaarts <>]

Here's a pair of use cases:

(1) A user creates a "guest" account using a web form where they specify 
an email address (and other demographic data) and set up a new password 
in our system.  We want the user to be able to immediately access SPs 
(at least the ones that allow guest access) without having to reenter 
their password.  In other words, the act of account creation should be 
considered a valid "authentication".

(2) We have a one year expiration policy on our standard passwords. 
When a user's password expires, they enter a grace period where they can 
only authenticate to the password changing application.  Once they 
change their password, their authentication should revert to the 
standard level so they can access all SPs again.  Like in case 1, they 
should not have to reenter their new password - the act of changing the 
password should be considered a valid authentication action (in this 
case, upgrading from password-change-only authentication to full 
authentication).

In both cases there is a need to communicate from a process outside the 
IdP to the IdP that the user is authenticated (or "differently" 
authenticated).  Is there a mechanism in the IdP that could be used to 
implement this?

I can think of two general strategies for implementing this.  The first 
is to use the same sort of mechanism we currently use with our 
cookie-based web SSO: the account creation and password change 
applications are both under our control, so we have them explicitly set 
the user's authentication cookie when they complete.  Since we are 
planning to have our Shib IdP interoperate with our SSO cookie, we could 
continue to use that as the mechanism for communicating the 
authentication actions to the IdP.

A second strategy would be to expose a web service (a RESTful servlet on 
the IdP perhaps) that allows trusted applications to mess around with 
the IdP session objects.  I'm a little fuzzy on how the session stuff 
works under the hood, so I don't know if this is feasible.  The main 
advantage of this over the previous strategy is that it does not require 
that the account creation and password change applications to be able to 
set a cookie that the IdP can read.  It also is more amenable to adding 
additional "action is required on a particular SP before general login 
is permitted" scenarios down the road.

Are these reasonable solutions?  Should I be looking at this another way?

Thanks,
--
%%  Christopher A. Bongaarts   %%  

          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%