On 8/11/06, Sepand M <[EMAIL PROTECTED]> wrote:
Hmm. Sounds like you're right =) I think I will. A few questions: 1. Why transient? Is ConnectionInfo serialized anywhere? I thought marshallers were doing that stuff.
because it's not field that should be serialized. It only a way for the broker side transport to communicate some info to the broker.
2. If I use a generic Object field, the hypothetical security broker plugin would have to do a cast to Certificate (or whatever) which, if the classes are not hooked up right, could fail. Is that ok?
Well, he should first test to see if it's an instance of what you expect. If it's not that or not set at all you could assume that the transport being used is NOT ssl and reject that request.
On 8/11/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > Sounds like it may be time to add that transient Object field to the > ConnectionInfo object. > Your transport could attach something to it there that the broker > plugin uses to to figure out, "hey this connection came from an SSL > transport". perhaps it's the Certificate, perhaps it's a reference to > the SSL session object. > > On 8/11/06, Sepand M <[EMAIL PROTECTED]> wrote: > > Hi Hiram, > > > > Thanks for the quick replies, but I have more =) > > I can't make a broker plugin since my design (to allow for quicker > > implementation, etc.) uses the JAAS plugin. It stores the client's DN > > as the username and then passes it to a JAAS broker. > > There is no way of telling if client certificates were checked without > > talking to the transports. > > > > On 8/11/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > > Hi Sepand, > > > > > > For the paranoid, they should use a security broker plugin that only > > > authorizes connections authenticated using certificates. > > > > > > On 8/11/06, Sepand M <[EMAIL PROTECTED]> wrote: > > > > 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 > > > > > > > > > > > > > > > > > > -- > > > Regards, > > > Hiram > > > > > > Blog: http://hiramchirino.com > > > > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com >
-- Regards, Hiram Blog: http://hiramchirino.com
