Shibboleth Developers

[Paul Hethmon <>]

On 9/7/10 7:48 PM, "RL 'Bob' Morgan" 
<>
 wrote:

> It is most likely within the capabilities of a site-developed login
> handler to do this kind of thing.  It may be an issue that as far as I
> know a single login handler gets invoked per request, so having a
> potentially large set of post-authn checks would mean modifying the login
> handler for each one.  Perhaps some way of chaining handlers would be
> useful.

Bob,

This is essentially what I do in my commercial offering. My login handler
receives additional information about the user during authentication. In my
case, it's stuff like the user needs to go to the enrollment agreement or
this user must change their password now. Based on that information, the
login handler can make a decision about whether to have Shib establish a
session or redirect the user to an alternate location.

It sounds like you have a larger potential pool of alternate things to have
the user do and/or check about the user than I do. It seems that either
hooking into the authentication process and having it return the information
would work at the expense of a potentially complex set of requirements and
conditions. Your idea of chaining login handlers sounds feasible too. The
first one in the chain might do the actual authentication while the
subsequent ones might only check authorization factors.

It would be possible to build that chain yourself I think as well. So your
Shib login handler gets the authentication request from Shib and does the
base authentication of the user. It then goes through its configured
"sub-handlers". Those could be loaded via Spring or you could go a simpler
route, something like just reading either context parameters or a separate
configuration file for a list of sub-handlers. Make them implement the
interface you design that gets the available information and returns the
data necessary for the main login handler to make a decision.

One thought here. If a user who is restricted to some SP by policy first
establishes a session with an allowed resource, what happens if they use SSO
to then establish a session with the dis-allowed resource? To be complete,
it seems you might have to either hook in or replace the previous session
login handler. Otherwise, on an SSO request, the user would never see your
login handler code executed.

Hmm, can you release attributes to that cloud service that either allows the
user access or denies access? So put that issue outside of the login
handler. For your use cases, it then looks simpler, has the user agreed to
the necessary agreements, if not, force them.

Just some thoughts, there are always ways to skin the cat.

Paul