Can an intercept trigger a re-resolution of attributes?

[Cantor, Scott]

On 8/1/16 5:34 PM, Christopher Bongaarts wrote:
> 
> This got me closer, i think.  I noticed that some flows use alternate
> lookup/context strategies, and some leave them unspecified (default?).

Yes. Most of the actions have plug points that make them reusable in
different situations, whether we personally needed to use them that way
or not.

The one you have to be wary of is the creation/lookup strategy for the
AttributeContext, because that's where the data's going to end up.

> So with this bean definition in my intercept beans.xml file:

You have to bear in mind that the beans have different behaviors in some
cases depending on what's already there in the tree, so they can do
unusual things sometimes. But using it like that would be conflicting
with the standard attribute resolution process.

What you want to do is use your intercept to resolve a specific
attribute at the beginning of the flow, using some kind of alternate
location in the tree for the eventual AttributeContext.

> I also get this error
> message every time I click continue:
> 
> 2016-08-01 16:18:54,550 - ERROR
> [net.shibboleth.idp.attribute.context.AttributeContext:113] - Unfiltered
> attributes have already been set in this flow.

Probably a quirk of the bean, it's probably not clearing the old
AttributeContext. It's not typical for one of the contexts to really
guard against that kind of operation, but that was one of the earliest
built and probably pre-dates most of my design work. Having it log that
is not really appropriate, but neither is the ResolveAttributes bean
implemented very safely.

> Both of these sound to me like I should be using some sort of temporary
> attribute context within the intercept, but I'm not quite sure where it
> should go in the Giant Context Tree, or how to specify it (perhaps
> defining more shibboleth.ChildLookup(orCreate) beans).

p:setAttributeContextCreationStrategy-ref=
"shibboleth.ChildLookupOrCreate.AttributeContext"

I don't know where you could really put it that's appropriate, but
ironically putting it directly under the root is not actually going to
conflict, the official attributes are left under the
RelyingPartyContext. Which the above should do.

> Or maybe I just need to re-run the resolver/filter one more time after
> the intercept finishes?  (Seems like yet another red flag that I should
> be doing this in a login flow instead of an intercept.)

I really suggest you avoid doing this as part of "standard" attribute
resolution. Maybe it's slightly more efficient, but it's concpetually a
lot cleaner to just do it as a dedicated attribute lookup in your
intercept (which will loop), and plus you don't have to bother with
filtering.

Which isn't to say it isn't a better fir for a login flow, but you
really don't want to waste time on that when it's so much easier in the
next version.

-- Scott