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