wish list: ability to define reusable blocs in SP configuration
guillaume.rousse at renater.fr
Mon Aug 6 10:12:30 EDT 2018
Le 06/08/2018 à 14:52, Peter Schober a écrit :
> * Guillaume Rousse <guillaume.rousse at renater.fr> [2018-08-06 14:28]:
>> 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: [...]
>> For each of those set, we have to define a different list of metadata files,
>> and a different discovery servicef URL.
> Why? For authorization there more appropriate methods than metadata
> filtering, i.e., literally performing authorisation in httpd's
> configuration (require ...).
> And who says you absolutely must offer 4 different IDP discovery
One single service, actually, with different URL mappings to different
set of metadata, each of these accepting multiple boolean parameters for
non-federated additional IdPs, ie:
- https://discovery.renater.fr/renater for education-research federation
- https://discovery.renater.fr/renater?cru=yes for education-research
federation + additional IdP
- https://discovery.renater.fr/renater for edugain federation
- https://discovery.renater.fr/renater?cru=yes for edugain federation +
That's still four different URLs for a SP configuration.
> Now, I can understand offering two (local fed only,
> local+interfederation), but I certainly wouldn't stand up an extra DS
> only to add a single IDP to the extra DS instance.
> (Applications with specific requirements can certainly stand up their
> own IDP DS? E.g. the Shib EDS consists of only HTML and JS and
> therefore can be integrated anywhere. It can also do filtering in its
> on configuration and so does not require pre-filtered metadata from
> the SP.)
Applications are managed by different teams, with differents priorities,
constraints and understanding of federation mecanics. Our current policy
is to have a unique and actively managed centralized DS, instead of
multiple out of date and inconsistent application-specific ones
(embedded or not). Exactly for the same reason we centralize SP under
> So I'd only offer the superset of these two Discovery Services and
> live with the fact that someone may be able to pick an IDP that later
> is not authorised to access the resource. (That will probably become
> the norm with more centralized IDP discovery services going
> forward. And having 1 additional IDP in a set of hundreds or thousands
> will hardly be the end of the world for anyone.)
Sure, if we were the only final users, and the only one to pay the price
for this kind of compromise. However, I fear than presenting a superset
of IdPs actually supported would just degrade user experience, and add
pressure on technical support (which is also one of our tasks). We
already handle too much lost users unable to figure out which technical
support they should adress to when something doesn't work automagically...
An alternative would be to intercept the fatal error, and display a
human-readable page explaining to the user he probably selected a
non-authorized IdP for this service, and encourage him to check exact
term of access before asserting something is broken. That may be worth
>> I'm ready to fill an formal enhancement request on Jira for this
>> feature if it can be considered feasable and useful.
> Personally I'd suggest you stop causing so much trouble for yourself,
> for very little actual gain. Then all of those problems go away.
I'm paid for handling this kind of troubles, actually :) Whereas I may
suggest other compromises between technical complexity and overall
result, I can't just decide alone on this matter.
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