IDP Interaction With Multiple Attribute Filter Sources?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

IDP Interaction With Multiple Attribute Filter Sources?

Ullfig, Roberto Alfredo

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!

 

---

Roberto Ullfig - [hidden email]

Systems Administrator

Enterprise Architecture and Development | ACCC

University of Illinois - Chicago

 


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: IDP Interaction With Multiple Attribute Filter Sources?

Cantor, Scott E.
On 6/20/18, 2:20 PM, "users on behalf of Ullfig, Roberto Alfredo" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: IDP Interaction With Multiple Attribute Filter Sources?

Wessel, Keith William
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 <[hidden email]> On Behalf Of Cantor, Scott
Sent: Wednesday, June 20, 2018 1:26 PM
To: Shib Users <[hidden email]>
Subject: Re: IDP Interaction With Multiple Attribute Filter Sources?

On 6/20/18, 2:20 PM, "users on behalf of Ullfig, Roberto Alfredo" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: IDP Interaction With Multiple Attribute Filter Sources?

Rod Widdowson
In reply to this post by Cantor, Scott E.
> 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

Mea maxima culpa I meant to reply last week.

TL;DR This is absolutely correct.  The details are explicit in [1]

/R

[1] https://wiki.shibboleth.net/confluence/display/IDP30/AttributeFilterConfiguration#AttributeFilterConfiguration-Semantics

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