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:35:29 GMT
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

Mime
View raw message