wish list: ability to define reusable blocs in SP configuration
guillaume.rousse at renater.fr
Mon Aug 6 10:42:28 EDT 2018
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.
Tel: +33 1 53 94 20 45
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3637 bytes
Desc: Signature cryptographique S/MIME
More information about the users