Intercept flows and adjustable auth levels

[Christopher Bongaarts]

Debated sending this to dev@ but figured there is probably enough 
user at -level content to justify the wider audience...

We have two uses cases that share some commonality for which I'd like to 
get some feedback on our approach.

One is the "expired password" situation.  In our case, password 
expiration is controlled by an attribute in our LDAP directory. When the 
password expiration attribute has a particular value, the password is 
expired for normal authentication, and can only be used to log in to 
change the password.  Ideally, the user would change their password, 
then be directed back to the original application where they are now 
logged in and ready to rumble.

The other case is one where we require users who have not set their 
password-reset secrets to set them.  There are two subflavors of this; 
one advisory (you have until Tuesday to set your secrets, set them now? 
(Set Secrets|Do it later)) and one mandatory (it's tuesday now.  you 
must set your secrets to continue.)  These status are also represented 
in an LDAP attribute.

Both cases involve "flows" that look like this:

- check username/password
- if ok, check the expired/must-set-secret flags
- If none are set, all is well, complete auth and send user to SP
- If one is set, present the user with a page (view) informing them of 
the situation
- In the advisory set secrets scenario, if the user chooses to continue, 
send them on to the SP normally
- In the other cases, the user is sent to the change password/set 
secrets application (which is Shib authenticated)
- The pw/secrets app sends the user back to the IdP for authentication
- The IdP should authenticate the user, recognize that it's the 
pw/secrets app, and authenticate the user, ignoring their expired or 
must-set-secret status, ideally leveraging SSO (as they've already 
authenticated almost-successfully once)
- The user changes passwords or sets secrets
- Ideally the SP would have some way to get the user back to the IdP to 
continue the authentication flow for the originally requested SP.
- The IdP would notice that the expired or must-set-secrets flag has 
been cleared, and SSO the user in to the original app.

IdPv2 couldn't handle this, as it only allows for one LoginContext at a 
time, and the login to the pw/secret app would overwrite the orignal 
app's context.  But v3 is an entirely different kind of griffon, so 
there may be new ways to get that to work.

What we did in v2 was, in our custom LoginHandler, to have our local SSO 
cookie store "is authed but only for the pw/secrets app" as a discrete 
authentication type, enforced by checked the entityID of the SP.  This 
got us most of the way - the user was still dead-ended after setting 
their password or secrets, but if they returned to the original app 
manually, the IdP would upgrade their cookie and let them in.

For v3, I'm pretty confident I can set up post-auth intercepts similar 
to the ContextCheck sample to trap the expired/must-set-secret flags and 
direct the user into an appropriate subflow, including the "continue 
anyway" route of the advisory set-secrets path.

What I'm trying to figure out at this point is how to handle 
authentication and/or "SSO" to the pw/secret app, perhaps by setting a 
proprietary URI in a Principal object in the AuthenticationResults 
(which basically mimics the custom auth type we used in v2). And then, 
figuring out how to trigger re-evaluation of the AuthenticationResults 
in the SubjectContext after the user has completed their task.

So my questions would be:

- Where might one put something to "upgrade" an existing 
AuthenticationResults by re-reading the user's LDAP entry? Perhaps doing 
it in a customized LDAP authn flow that could skip requesting a password 
when an existing AuthnResults is present but upgradeable?

- Is it necessary/desirable to call out a custom auth type in the 
AuthenFlowDescriptor if no SP will ever assert it for matching?

- Is there some way to pick up a flow where it left off?  Perhaps as 
information in a dynamic link to our pw/secrets app (so it has a URL to 
return the user to when finished)?  Maybe Spring has some magic that 
allows this?


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