IdP attribute filter strategy

[Cantor, Scott]

On 6/8/15, 4:09 PM, "users on behalf of Jeffrey Crawford" <users-bounces at shibboleth.net on behalf of jeffreyc at ucsc.edu> wrote:

>My goal is to use entity attributes to determine which attributes are released. For my locally managed metadata I just add the EntityAttributes to our copy of the metadata.

Right, but what I need to know is *what* is broken.

The filter is not broken that I can see. So what is? What is it that is supposed to be triggering on what you're adding that isn't triggering?

The consent engine does not care about EntityAttributes, so that statement made no sense to me unless what you meant is that you're trying to create a RelyingParty override to override a ProfileConfiguration bean to turn on the consent flow.

>For incommon I'm trying to use the metadata filter as described to "virtually" add these same attributes so they trigger the attribute filter rules based on the entityID's (This is only done to entities that don't request attributes) Each attribute value will trigger a particular filter rule.

Ok, then that's not the consent engine at all, that's the filter engine. So maybe the EntityAttribute-based filter rule is broken.

>That way sp1 would have attr-1 attr-2 attr-3 and attr-4 be released, where sp2 only gets attr-2 and attr-4. However it behaves as though only the first match wins, the others don't have attributes
> added that then match to attribute filters.

You have this backwards, that's what I'm telling you. The attributes *are* added. The bug is not there, it's at the other end.

I don't know how you would be able to conclude that the attributes are or are not added, other than by trying to use them. What I'm saying is, the bug is in what's using them, and so that requires that I know what's using them to pin down the location of the mistake.

I actually looked at the RP override conditional logic and I'm actually fairly sure it does look at every Attribute it finds, not just the first one. So I would be interested to see if you can create such an override in relying-party.xml based on one of the tags that you don't think is being added. I think it will work.

I have not looked at the filter plugin yet.

-- Scott