Hi all, Thank you for your answers. this is very helpful! I was indeed hesitating between IP/hostname in the certificate (knowing it could be a mess to manage) and filtering on the IP. I think the latter option looks good enough.
@Rob, Thank you for your proposal. I do not have strong needs/commitments on this for now so :). Thank you for routing me on the ACLs. @Gordon, I was reading this http://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html and indeed, it looks like the last version of the dispatcher may support these filtering features (using policy and policyRuleSet) Again, thx. Olivier. On Thu, Jun 9, 2016 at 10:40 PM, Rob Godfrey <[email protected]> wrote: > On 9 June 2016 at 22:19, Gordon Sim <[email protected]> wrote: > > > On 09/06/16 21:00, Rob Godfrey wrote: > > > >> Hi Olivier, > >> > >> Speaking for the Java Broker, there is currently no mechanism to tie the > >> TLS client certificate to the host name or IP address corresponding to > the > >> origin of the TCP/IP connection (I'd imagine this is also the case for > >> Dispatcher but I'll let someone more knowledgable on that codebase step > in > >> there). Similarly to the C++ broker as described in the document > Chester > >> provided, when using the SSL Client Certificates on a connection we > simply > >> verify that the certificate has been signed by a trusted source, and > then > >> (if the External Auth Provider is being used) take the identity from the > >> certificate itself. > >> > >> It's certainly shouldn't be a big job to add the ability to verify that > >> the > >> certificate provided by the client in the TLS negotiation has a DN or > SAN > >> which corresponds to the IP address or reverse-looked-up DNS name of the > >> machine initiating the connection. Obviously in your use case as > >> described > >> below this would be validating that the connection from a Dispatcher > >> instance is coming from the expected machine for the Dispatcher... it > >> won't > >> be verifying anything about the client which connects to the Dispatcher. > >> > >> Would you be interested in me implementing something to add this > >> functionality to the Java Broker? > >> > > > > My suggestion would be to restrict the authenticated client identity to > > connect only from given IP addresses. That way your certificates just > > identify the client (and are not tied to a given host or ip address) and > > you can update the whitelisted/blacklisted ips for a given client > identity > > more easily. > > > > The router can do this now, I believe. > > > > > > > Yes - that will also work if you have a reasonably static set of users / > hosts connecting and want to have the configuration at the server... The > Java Broker also supports ACL rules that limit access to a given virtual > host for a given user (or group) to a set of IP Addresses or DNS host > names. The difference (I don't know if this is the property that Olivier > needs) is that the TLS certificate mechanism doesn't need the broker to be > reconfigured in order for a new client / host to be added... that is taken > care of solely by the generation of a certificate which is is signed by the > trusted authority. > > -- Rob > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
