I am actually implementing option 1 anyways since the reflection stuff
is part of the other Transport implementations (I'm being consistent).
The problem is that I want the user to be sure that the broker they
start will only use certificate authenticated connections (this is for
the paranoid to be sure that nothing else will get inside their
server). I am suggesting something like a setNeedClientCert method
that would operate similar to setUseJmx (except that setUseJmx adds a
broker filter and setNeedClientAuth would change the addConnector
calls to enable client certificates).

On 8/10/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
I would go with option 1 since SSL is transport layer option and does
not really have anything to do with the core of the broker.

On 8/10/06, Sepand M <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> As some of you may know, I'm working on an SSL client certificate
> authorization system for ActiveMQ. I've gotten some of the basics done
> and am trying to create a way of ensuring that SSL client certificates
> are used.
>
> I see two options (and I strongly prefer the second one):
> 1. The client would add the proper "option" to the URI they bind to on
> the broker side (e.g URI="localhost:61616?needClientAuth=true").
>
> 2. Adding a method to the BrokerService that enables this functionality.
>
> Unless someone suggests something different, I'm choosing method 2.
> The problem is I can't decide if I should subclass the existing
> BrokerService or add the menthioned method to the existing
> BrokerService class.
>
> So far, BrokerService seems to be doing everything and it has no
> subclasses, but I'm wondering how much more can be crammed into it and
> if SSL functionality should be built into the general purpose broker.
>
> Any thoughts?
>
> Regards,
> Sepand
>


--
Regards,
Hiram

Blog: http://hiramchirino.com

Reply via email to