Intercept refactoring complete

Cantor, Scott cantor.2 at osu.edu
Thu Nov 6 14:05:48 EST 2014


I think this is done, and I've replaced a bunch of one-off "hooks" for 
adding subflows with the general intercept scheme Tom built for consent, 
including the inbound security policy step that does the checks on the 
inbound SAML messages.

There's a master list of the intercept flows of all types, but the actual 
activation of a flow (or flows) is now done with a lookup function that 
returns the flow IDs to turn on, and there are functions to pull that from 
the appropriate profile config slots depending on where it's being done.

That means a couple of useful things, one being that any place we add 
support for intercepts, we can run any number of subflows, not just one, 
and secondly we can add additional "hook" points easily without much new 
configuration.

Currently there are three intercept points, after message decode, before 
message encode, and after authentication and attribute lookup in the two 
SAML SSO flows.

I've managed to keep all the SAML security flow material hidden in 
system/, so it should be as invisible as before, and it's fairly hard to 
unintentionally turn them off, which was a concern I had converting those 
flows into intercepts.

-- Scott



More information about the dev mailing list