activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Where to add new SSL BrokerService functionality
Date Fri, 11 Aug 2006 16:44:24 GMT
Hi,

I just added a transportContext field to the 4.1 ConnectionInfo obect.
 I'll back port it to 4.0 shortly.

On 8/11/06, Hiram Chirino <hiram@hiramchirino.com> 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 <sepandm@gmail.com> 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 <hiram@hiramchirino.com> 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 <sepandm@gmail.com> 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 <hiram@hiramchirino.com> 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 <sepandm@gmail.com> 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

Mime
View raw message