SP 3 and reverseProxy

Guillaume Rousse guillaume.rousse at renater.fr
Mon Oct 29 12:15:23 EDT 2018


Le 29/10/2018 à 16:38, Jehan PROCACCIA a écrit :
> On 29/10/2018 10:15, Guillaume Rousse wrote:
>> Hello.
>>
>> We (GIP RENATER, the french NREN) currently have approximatively 30 applications behind a cluster of two reverse-proxy, configured in active-passive setup. From our experience, having the service providers managed by the people in charge of running applications is a nightmare in term of maintenance and evolution, as they generally have different priorities as yours, so the decoupling is a huge gain for us. For instance, we managed the SP version switch on those proxies from 2.x to 3.x in less than one month, whereas some old standalone SPs are still using old metadata URLs we are trying to deprecate since 2 years now...
> 
> you talk about "reverse-proxy", as Peter and Scott responded to me, in order not to confuse my objectives (factorizing SP deployement to a single proxy) , your architecture should be called "forward proxy" , do you agree ?
Those proxies are fronting our public applications, which are not 
directly exposed to internet. Usually, that's refered to as 
'reverse-proxy', whereas 'forward-proxy' usually meaning caching proxies 
on the client side.

>> The only adverse effect we had sofar was not performance or reliability (that's a cluster, we can add new nodes in just a couple of hours, or change the load balancing algorithm), rather the concentration of application-specific issues in a single point, while having to isolate each application from others, that makes the whole SP configuration quite complex. For instance, we currently have a 4-minutes starting metadata loading delay at startup, because of the multiple metadata sets required by different applications. And rather than just the pure number of applications to handle, I currently feel the number of specific configurations as an hard limit to this architecture: having 100 applications using the same metadata, and the same sessions parameters, seems easier than 12 using 12 slightly different setup.
> 
> that seems to fulfill my objectives, but I am still confuse when you talk about "multiple metadata sets required by different applications"
> on your central Proxy SP deployement, do you have to specify overrides for each application and hence have to publish metadatas for each of them ?
We do have to specify override for each application trusting a different 
set of IdPs than the base set, because we prefer to use metadata-based 
filtering instead of attribute-based filtering to manage 
federation-level access control. You have full discussion on this topic 
on the ML archive, with various attempt to
https://marc.info/?l=shibboleth-users&m=153355852413495&w=2

But that's unrelated to metadata publishing: wether using their own 
dedicated SP or not, each of those application has to publish its own 
metadata anyway, using its own EntityId, because they have different 
descriptions, access conditions, etc... For the external world, this is 
almost transparent, exactly as HTTP virtual hosts hosted on the same host.

> did you wrote a doc/cookbook on this architecture ? I guess that's the one: https://services.renater.fr/federation/docs/fiches/reverseproxy (it does link to whiki shib 1.x SPForwardProxy )
> I hope it still works with recent versions (apache 2.4, SP 3)
This documentation is quite old, as most of the website, and ought to be 
updated, but excepted minor configuration directives oddities 
(ShibExportAssertion, for instance), is still valid. Especially about 
the main security concern for any kind of authentication proxy, which is 
to ensure than only trafic coming from the proxy should be allowed. And 
yes, it works with recent software versions.

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/20181029/c6813d74/attachment.p7s>


More information about the users mailing list