Post-Authentication User "Intercept"

[Cantor, Scott]

On 4/27/16, 7:44 PM, "users on behalf of Aaron Cargo" <users-bounces at shibboleth.net on behalf of acargo at setonhill.edu> wrote:



>I recall reading something on this list about post-authentication workflows (similar to how attribute consent works?) but can't seem to locate documentation that describes this in a way that correlates in my head to what I'm looking to do.

I'm not sure I can point you anywhere you haven't seen, but...

https://wiki.shibboleth.net/confluence/display/IDP30/ProfileInterceptConfiguration

And more recently on the development side, https://wiki.shibboleth.net/confluence/display/IDP30/ProfileHandling

>1. Is the IDP the correct place to attempt this? Or am I barking up the wrong tree?

Well, I'm not going to get into "correct", but if you want to do it, you can.

>2. Is 'post-authentication workflow' what I'm looking for here, and if so, is that the correct terminology to be researching?

They're called "interceptors" (or "intercepts" every time I forget the actual name in the code), and the ones that run after authentication are the ones that are the most useful and least risky to screw around with.

They're Spring web flows. If the existing examples aren't usable, you have to learn enough Spring and SWF to be able to write one, that's just how the system is built. It's not hard, but if you're not a Java person, or don't have time to learn the ins and outs, it isn't an automatic thing. This just isn't a scripting language based system.

>3. Does anyone have any experience implementing something along these lines, and have any suggestions/feedback/"gotchas" to share?

I have lots. I added one to the trunk that's not in the documentation yet that checks for an expiring password attribute and displays a page in the middle of the flow, as yet another example people can copy, and that's a simpler example of one that includes a view template than the attribute consent one is. It's in the 3.3 snapshot build.

I can't really just teach you SWF in an email, it's just not that simple to explain. What you're after here isn't hard, it would involve writing a Java bean that implements our ProfileAction interface to query your service, and then signal an event to the flow definition that would branch to an externalRedirect to somewhere else, with a parameter that includes the flowExecutionUrl variable that resumes the flow to pick it back up.

You could see an example of that particular idea in the External authn flow (system/flows/authn/external-authn-flow.xml), close to that anyway.

-- Scott