wish list: ability to define reusable blocs in SP configuration

[Guillaume Rousse]

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
> services?
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 + 
additional IdP

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 
reverse-proxy.

> 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 
investigating, indeed.

>> 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.

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/84fb7bcb/attachment.p7s>