Very slow processing of attribute-filter.xml with many AttributeFilterPolicy elements

Anders Lördal Anders.Lordal at
Thu Nov 27 09:56:54 EST 2014

If you need 378 different attribute sets then my suggestion would be that you distill them down to common denominators and make categories from those.
Sure you get to assign multiple categories per SP but at least you don’t have to make one for every SP.

So it's basically the same idea as using attribute bundles but without the need to specify the entityID of the SPs in the filters, just decorate the SP with categories in the federation registry.

And on the upside when you get the support for these categories in your IDPs you can add SPs without reconfiguring the filters in the IDPs.

Anders Lördal

-----Original Message-----
From: users-bounces at [mailto:users-bounces at] On Behalf Of Lukas Hämmerle
Sent: den 27 november 2014 15:09
To: Shib Users
Subject: Re: Very slow processing of attribute-filter.xml with many AttributeFilterPolicy elements

On 27.11.14 13:50, Anders Lördal wrote:
> What about going for entity categories? Then you can define some
> categories for smaller attribute bundles and then tag the SPs.

True, but quite some (see my previous mail) bundles would have to be
defined I guess. What would help (in combination with entity categories)
is if our IdPs were using IdP 2.4 or newer so that we could use [1].
This is however the case only for a bit more than 50% of our IdPs use
Shibboleth 2.4 or newer.

Best Regards


Lukas Hämmerle, Central Solutions
GÉANT Project Task Leader "Enabling Users"
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 05, direct +41 44 268 15 64
lukas.haemmerle at,
To unsubscribe from this list send an email to users-unsubscribe at
[Högskolan i Gävle]

Högskolan i Gävle, 801 76 Gävle • 026 64 85 00 •<>

För en hållbar livsmiljö för människan

University of Gävle, SE-801 76 Gävle, Sweden • +46 (0) 26 64 85 00 •<>

More information about the users mailing list