>>> > What about if one have many applications each with different client
>>> > certificate configuration for each directories?
>>> We can imagine theoretical use cases for all kinds of features, that
>>> doesn't mean we implement them. Real use-cases matter.
Hi Lukas,
I do not speak about theoretical use case. Our is a preliminary test to
evaluate the possibilities of designing with haproxy an ssl offloading
solution with client certificates management which then will be extended to
many of our customers who will use our software
to access "some" resources by authenticating to backend servers with client
certificates. On behalf of these customers our
web applications (getting info from haproxy with X-SSL-Client-... headers) can
do the job.
To be efficient in term of resource and to be simple e consistent, we use as
example one domain for application line,
so each customer will access its application on backend servers based on a
specific site directory
(each directory with the customer's own name).
for example:
www.dom1.com/customer1<http://www.dom1.com/customer1>
www.dom1.com/customer2
www.dom1.com/customer3
So we have different domain with different hostname with different directory
and sub dirs., etc., of which only some of that
must be configured with client certificates access (only parts of web
application need client certificates and not all customers
has enabled all functionalities so some customer can have to use same app
functionalities with and other without presenting
client certificates.
for example:
www.dom1.com<http://www.dom1.com>
-> do not request
client cert
www.dom1.com/customer1<http://www.dom1.com/customer1>
-> do not request
client cert
www.dom1.com/customer1/app1/func1/subfunc1<http://www.dom1.com/customer1/app1/func1/subfunc1>
-> do not request client cert
www.dom1.com/customer1/app1/func1/subfunc2<http://www.dom1.com/customer1/app1/func1/subfunc2>
-> request client cert
www.dom1.com/customer1/app1/func1/subfunc3<http://www.dom1.com/customer1/app1/func1/subfunc2>
-> do not request client cert
...
www.dom1.com/customer1/app1/func1/subfunc2<http://www.dom1.com/customer1/app1/func1/subfunc2>
-> do not request client cert
www.dom1.com/customer2/app1/func1/subfunc3<http://www.dom1.com/customer2/app1/func1/subfunc3>
-> request client cert
www.dom1.com/customer3/app1/func1/subfunc3/sub1<http://www.dom1.com/customer3/app1/func1/subfunc3/sub1>
-> do not request client cert
www.dom1.com/customer3/app1/func1/subfunc3/sub2<http://www.dom1.com/customer3/app1/func1/subfunc3/sub2>
-> request client cert
www.dom1.com/customer3/app1/func2<http://www.dom1.com/customer3/app1/func2>
www.dom2.com/customer<http://www.dom2.com/customer2>4...
www.dom3.com/customer5...
Probably this case is not so frequent for web sites, but it is for web app.
Absence of flexibility
in offloading client certificates mean choice another solution or try to force
(impose) at devel
stage to write apps so it is possible to do that conforming to a particular
solution (ie haproxy).
This is a wrong design decision however.
Also with bugs correction you tell, it seems that managing our case with
haproxy pose many problems.
Roberto
-----Original Message-----
From: Lukas Tribus [mailto:[email protected]]
Sent: sabato 4 marzo 2017 16.42
To: mlist <[email protected]>
Cc: [email protected]; 'Emmanuel Hocdet' <[email protected]>
Subject: Re: Client Cert Improvements
Hi,
Am 04.03.2017 um 15:27 schrieb mlist:
>
> I said I'm using dedicated ip:443 bind as a clean solution because "the
> current haproxy client certificate
> management implementation is not optimal nor flexible nor scalable in other
> configurations" so, in this
> test we can waste one public IP and an manage an useless additional frontend,
> having to manage 2 frontend
> instead of one.
Once the bug is fixed you can manage everything easily and with a single
IP, expected when you need per directory client
certificate negotiation, which is what we are discussing here.
> One need to use another IP also for only one directory in the some domain
> if needed...
> Not so good !
> It is simple: if all web server (Apache, IIS, nginx, ...) have such feature,
> is because it is useful and used ! :D
nginx does not have this feature.
> What about if one have many applications each with different client
> certificate configuration for each directories?
We can imagine theoretical use cases for all kinds of features, that
doesn't mean we implement them. Real use-cases matter.
> You can leave haproxy implementation as is if you think this is the right
> way. I found this implementation not at all flexible
> and far away from haproxy standard mindset.
You are not hearing what I'm saying. When the bug is fix you can manage
you real use-case easily.
> I think this is an important feature, but the choice is your!
I don't decide, I'm just expressing my opinion about this feature.
cheers,
lukas
