destroying user IdP session as part of profile intercept flow
Scott Koranda
skoranda at gmail.com
Thu Feb 4 10:13:38 EST 2016
> > If I want to use a somewhat smaller hammer, is there any reason I
> > cannot look at the SubjectContext, find the mutable map of
> > authentication results it holds, examine the authentication
> > results to find one I am targeting, and then remove that one
> > from the map?
>
> Well, you said session, so that's a different issue really.
Yes, understood. I grabbed for the large hammer first but then
thought better of it and want to see if I can be more precise.
> For example, keeping the session but losing one result,
> doesn't really change the identity associated with the
> session if that comes into play somewhere or if the user
> comes back again. The default behavior now is generally ok
> with that, since an identity switch just auto-destroys the
> original session, but still it's just a different operation.
>
> Also, no, destroying a result sitting in the session doesn't
> impact that request at all, actually. It won't appear to
> have any affect except for preventing SSO in the future via
> that result.
Preventing SSO in the future via that result is precisely what
I want to do for this use case. Thanks.
> You're preventing the persistence, but not the
> use of that result that one time.
>
> > The goal is to use an intercept flow to invalidate an
> > authentication result that just happened so that it cannot
> > be used again until the associated authentication flow
> > happens again.
>
> So you specially are ok with it being used that one time?
Yes.
> If so, you might want to look at a goofy feature that I
> can't actually recall why I included. There's a
> predicate/condition you can inject in the flow descriptor
> bean in general-authn.xml that controls the serialization of
> a result of that flow. Don't know if your condition is
> "static" or not, though, if not it wouldn't work as a
> condition there.
I always appreciate such "hooks" but I don't think it will
work in this instance since I need resolved user information
(a set of attributes about a user) to be factored into the
condition.
Doing this with an intercept flow is appealing because I can
easily craft the condition there.
Thanks,
Scott K
More information about the users
mailing list