scripting the resolver with Velocity "Template" attribute defintion

[Brent Putman]

On 2/15/17 3:31 PM, Peter Schober wrote:
>
> I did consider opening an RFE to make the restriction of "same number
> of values" at least optional/configurable. Does that make sense to
> others as well?

Hmmm.  I couldn't remember exactly how the template attribute def works
with multiple dependencies, so I went and read the code.  I think I'd
make a slightly different proposal: That the current implementation
just doesn't make any practical sense for the case of multiple
dependencies with multiple values.

It's fine if you've got just 1 dependency (with either 1 or many
values).  It's also fine if you've got multiple dependencies with 1
value each (or maybe *at most* 1 value each).

But the multiple dependencies with multiple values case seems an issue
to me.  Say you have dependency d1 with values (foo, bar, baz), and d2
with (x, y, z), with each set of values in that iteration order.  As
near as I can tell, the template is going to get executed 3 times, with
the following values:

(foo, x)
(bar, y)
(baz, z)

Since the value ordering is arbitrary, that doesn't seem very useful. 
It doesn't cover all the cases, that is, the other combinatorical
permutations.  What if you needed to process the case of (foo, y) or
(baz, x)?  I have trouble imagining that the arbitrary combinations
based on the arbitrary ordering of the values make any sense.

So off-hand I started to say: It perhaps should not support the case of
multiple dependencies with multiple values at all.

But then it occurs to me, maybe what it should do is: Instead of
producing tuples via a simple loop over values having the same
cardinality, it should produce the Cartesian product.  In other words
it should produce all the combinatorical permutations:

(foo, x)
(foo, y)
(foo, z)
(bar, x)
....
(baz, z)

You would then use conditionals in the template to filter out and keep
only those combinations you wanted.  Given that this would be a highly
specialized case, I'd argue it should not be turned on by default. 
This support would be turned on explicitly by the deployer when she
knows the nature of the attributes in question and can then write the
appropriate template.

Thoughts?

--Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170215/de651a64/attachment.html>