Post-Authentication User "Intercept"

Aaron Cargo acargo at
Wed Apr 27 19:44:19 EDT 2016

Good evening all-

I've been subscribed to the Shib users list for about a year now and have
learned a tremendous amount by reading the conversations hosted here.
Thanks to all who participate and contribute - I'm writing to ask your

We're in the very early stages of a rebuild of our University intranet
platform. Until about 6 months ago (when we deployed Shibboleth), the
existing system also handled some semblance of an SSO system for our web
resources. Because this system was "home brew", the previous administrators
had used it to effectively intercept certain users upon login for a variety
of reasons - data collection, account restrictions, notifications, etc -
and redirect those users to a specified URL prior to their original
destination. Whether the idea of impeding access to our web resources is a
good one or not, it's become part of the business rules we live by and a
fair few processes have become dependent on that ability.

To make a long story short, removing the authentication role from our
intranet rendered our existing "block code" system somewhat ineffective,
and we're hoping to move a small portion of this to our Shib deployment.

In an ideal scenario, after successfully authenticating a user, the IDP
would query our block-code api, with the user's distinct name or id number,
and receive a response indicating whether the user should be 'intercepted'
- and if so, to what forwarding address they should be sent. The
"intercepting" address should also be given some indication of the user's
original destination, so that once they've completed whatever task is
blocking their access, they can be redirected.

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.

In short:

   1. Is the IDP the correct place to attempt this? Or am I barking up the
   wrong tree?
   2. Is 'post-authentication workflow' what I'm looking for here, and if
   so, is that the correct terminology to be researching?
   3. Does anyone have any experience implementing something along these
   lines, and have any suggestions/feedback/"gotchas" to share?

Apologies if I've overlooked obvious documentation on the subject - I
promise I've made a good faith effort to RTFM. :)

Thanks in advance,

Aaron Cargo
*Senior Web Developer*
Seton Hill University
acargo at
(724) 552-4386
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list