wish list: ability to define reusable blocs in SP configuration

[Guillaume Rousse]

Le 06/08/2018 à 14:57, Cantor, Scott a écrit :
>> We deploy SP on authenticating reverse proxies, meaning each SP manage a
>> lot of different applications (approximatively 40 currently), each in a different
>> virtual host. What makes those applications different is the exact set of
>> trusted IdPs:
> 
> That is not how it works. You don't limit trust by application, you control access with attributes. You should not  limit the metadata to specific virtual hosts. So that's one problem that's easy to fix and is entirely self-inflicted. You do not need overrides for this.
Thats would work, indeed, but also reduce the amount of isolation 
provided by strict trust relationship management. Given than 
applications are managed by other teams, I'm effraid suddenly changing 
SP filtering behaviour just because it make life easier for the 
federation team won't make us very popular. Even with "that's not now it 
is supposed to work" as argument :)

BTW, this organisational issue aside, how do you distinguish between 
different federations, with just attribute-based filtering ? Some kind 
of SP-set 'is-member-of' attribute ?

>> For each of those set, we have to define a different list of metadata files, and
>> a different discovery service URL.
> 
> That last one I may have overlooked. I can see if that's doable if it's not already possibly to use a content-driven rule for setting the DS URL, but I would note that it's already possible with a little rewriting or scripting with Apache, just route all of them to a fixed DS and then do a further delineation from there.
I fear than switching from SP-based routing to Apache-based routing 
would just be moving complexity from one part to another, with 
additional binding with different pieces of software moreover. I'd be 
more interested in a content-based rule on SP side, here, instead of 
hardwiring an application list on DS side.

>> I'm ready to fill an formal enhancement request on Jira for this feature if it
>> can be considered feasable and useful.
> 
> It's not necessary to solve your problem and it would be years if ever before any more enhancements ever got done.
OK, that's exactly why I described the problem here first. I'm still 
interested in DS URL routing enhancement, tough.
Regards.
-- 
Guillaume Rousse
Pôle SSI

Tel: +33 1 53 94 20 45
www.renater.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3637 bytes
Desc: Signature cryptographique S/MIME
URL: <http://shibboleth.net/pipermail/users/attachments/20180806/f4197db6/attachment.p7s>