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