Conceptually you need both.
-- the client needs a policy to say what kind of authentication it
will offer. client cert is one choice.
-- the server needs a policy to say what kind of client
authentication it will accept. client certs are one choice.
AFAICT these are your two options.
I'll repeat that IMO you should expand the choices to match what's in
corba csiv2. Otherwise you are apt to implement little bits and
pieces in inconsistent and incompatible ways that will be very
difficult to extend to a set of reasonable choices.
thanks
david jencks
On Aug 10, 2006, at 10:38 PM, Hiram Chirino 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
