Re: Yet another trusted proxy suggestion

On 2013-11-28 10:18, Nicolas Mailhot wrote:
> Le Mer 27 novembre 2013 21:58, Stephen Farrell a écrit :
>> 
>> 
>> On 11/27/2013 08:40 PM, Nicolas Mailhot wrote:
>>> 
>>> Le Mar 26 novembre 2013 21:09, Adrien de Croy a écrit :
>>>> 
>>>> I don't see any point in using a CONNECT style of approach if you 
>>>> trust
>>>> the proxy.  What sort of connection is that? If TLS, then why not 
>>>> just
>>>> use a GET https:// approach.
>>>> 
>>>> As for using a mandatory proxy on the server end, I don't really see 
>>>> a
>>>> requirement for that.  People use reverse proxies for sure, but they
>>>> just appear from the outside to be a server.  I think if we allowed
>>>> assertion of mandatory proxy use outside a trusted environment (e.g.
>>>> the
>>>> user's LAN) then we would have major problems getting it accepted.
>>> 
>>> I had the case of an entity that used an authenticating proxy to 
>>> protect
>>> outside access to their internal webapps. So getting access for our
>>> users
>>> to their apps would have required chaining two proxies
>>> 
>>> web client on corp1 lan → corp1 outbound auth proxy → Internet → 
>>> corp2
>>> inbound auth proxy → webapp on corp2 land
>>> 
>>> And of course corp1 and corp2 secrets were not shared, only users 
>>> with
>>> dual affiliation had a login on both proxies.
>> 
>> I'm not sure how that actually works with http/1.1 - does it
>> really?
> 
> I freely admit we could not get it to work which made those
> dual-affiliated users greatly cross with IT. We would definitely be
> interested in upgrading our hardware to http/2 if it could solve such
> use-cases, we do not enjoy making users miserable.
> 
> Cheers,

HTTP auth framework is quite flexible. Squid can configure exactly this 
in any one of several ways:

* end users have a login to proxy1 in corp1.


method 0)
  corp2 configure their proxy2 as a reverse proxy accepting www-auth 
headers. Login to proxy1 proceeds as normal with proxy-auth headers for 
credentials. Login to proxy2 proceeds as normal with www-auth headers 
for credentials.
  Any separate login within corp2 to the app service itself is corp2's 
problem. But it should not be hard since they control the credentials 
and access to both proxy2 and the app. if not then one of the below 
methods will be needed.

method 1)
  corp1 has an organization level set of credentials to access corp2 via 
proxy2. This is configured in proxy1 along with access controls 
responsible for gatekeeping particular end-users access to corp2 on the 
authenticated channel.

method 2)
   corp1 and corp2 have federated single-sign-on credentials for each 
corp1 user. proxy1 simply passes along the authentication headers 
instead of stripping as hop-by-hop (or re-instates a new hop-by-hop 
header with the same field values.

method 3)
   corp1 and corp2 have fully independent sets of credentials. corp1 
maintains an administrative system for allocating and managing its users 
credentials for corp2. proxy1 is configured such that outgoing traffic 
sent to proxy2 is assigned the credentials from said system based on 
(perhapse even encrypted by) the users authenticated proxy1 credentials.

The particulars are off-topic I think. So drop me a line if you want 
more on specific config.

Amos

Received on Wednesday, 27 November 2013 22:22:49 UTC