IDP Interaction With Multiple Attribute Filter Sources?

[Wessel, Keith]

That's correct, from my experience, and as the one who runs that federation that Roberto's consuming filters from. You can have the same SP in both files, and the filters are compiled into one attribute filter policy. If you want to override what's coming from the automatically generated attribute filter file, just set up deny rules in your local attribute filter file to cancel out the first.

This also makes it easy to release additional attributes that aren't available in the federation without having to repeat the federation's configuration.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Wednesday, June 20, 2018 1:26 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: IDP Interaction With Multiple Attribute Filter Sources?

On 6/20/18, 2:20 PM, "users on behalf of Ullfig, Roberto Alfredo" <users-bounces at shibboleth.net on behalf of rullfig at uic.edu> wrote:

> We have two sources for attribute filters. One is from a federation and the other is from the standard local file. 
> Currently, SP entity IDs are exclusive to one or the other. If the SP 
> entity ID is in both does one filter take precedence over the other? How are the filters processed? Thanks!

Rod would know for sure and he's probably offline for the day, but I believe it's just a pile of policies processed in sequence so there's no distinction there. I don't think order ever matters because it's just "all allows" and then "all denies", so it's immutable to the order, mercifully.

There's no concept of SPs being exclusive to a policy. It's not like metadata and it's definitely not like the relying-party override feature. Policies can reference an SP in a hundred different ways and all of them are evaluated in every case, not just one.

That's why I'm fairly sure that it will turn out to be much more efficient to build policy around attributes and not around SPs. 10 policies with a complex requirement rule to evaluate is likely faster than plowing through 200 policies with simple rules (not to mention much simpler to maintain). But I don't have numbers to prove that.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net