activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Creating a secure connection system and using JMSXUserID support
Date Thu, 19 Oct 2006 19:29:56 GMT
Hi Sepand,

Do you have any testcases where you atually use the SslBrokerService ??

On 8/30/06, Sepand M <sepandm@gmail.com> wrote:
>
> Hi all,
>
> I've seen a similar patch going out so I'm giving an update on this one.
>
> Currently, it does the following:
> - Allows for wantClientAuth and needClientAuth on SslTransport and
> SslTransportServer classes.
> - SslTransport attaches the client's certificate chain to
> ConnectionInfo in the newly added (not by me) connection context
> field.
> - Adds ActiveMQSslConnectionFactory and SslBrokerService, which can be
> used to specify trust and key managers from within code (otherwise,
> you can use the default ActiveMQConnectionFactory and BrokerService
> classes and just give an "ssl" URI)
> - Adds a new JaasCertificateAuthenticationPlugin and the corresponding
> broker which allow for authentication based on the certificate
>   - The above use the standard JAAS interface (with some new classes
> for handling SSL certs)
>   - These classes can be tied into the existing authorization system
> and UserIDBroker (JaasCertificateAuthenticationBroker will set the
> securityContext's username to one associated with the certificate
> based on CertificateLoginModule).
>
> It has no problems right now, but I'd rather test it more thoroughly
> before sending the patch. I should be done within the next 2 weeks.
>
> - Sepand
>
> On 8/3/06, Sepand M <sepandm@gmail.com> wrote:
> > Hi,
> >
> > The DN will overwrite the client-provided username (if any) when the
> > SslTransport writes it.
> >
> > On 8/3/06, Kelly Campbell <kelly.a.campbell@gmail.com> wrote:
> > > Sepand,
> > >
> > > One possible gotcha I haven't heard anyone bring up that we should
> > > address is to make sure that someone can't just "fake" the DN in the
> > > username field through a normal login and make the system think it's
> > > authenticated with the certificate.
> > >
> > > -Kelly
> > >
> > > On 8/3/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> > > > Hi Sepand,
> > > >
> > > > 4.1 and 4.0 branches are not that different yet.  If you need your
> > > > solution for 4.0, go ahead and do it.  Chances are we will only
> apply
> > > > it only to 4.1 (since this a new feature).
> > > >
> > > > On 8/3/06, Sepand M <sepandm@gmail.com> wrote:
> > > > > Thanks Hiram. That sounds great.
> > > > >
> > > > > I guess my last question is: what branch do I work off of?
> Personally,
> > > > > I would like to build my stuff on a stable release (4.0.1), but
> I've
> > > > > looked at the svn logs and you guys seem to be pretty active
> around
> > > > > the stuff I want to change so I'm not sure how my changes could be
> > > > > reintegrated once I'm done.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > On 8/3/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> > > > > > Sepand,
> > > > > >
> > > > > > Do what you need to to get you project done, you cand send us
> tidbit
> > > > > > as you get it done and we can work on merging it back to the
> main
> > > > > > branch.  The great thing is that you have a use case that we
> want to
> > > > > > support, so if you put something together that work for you,
I
> don't
> > > > > > see why it would not just go whole hog into the main branch.
> > > > > >
> > > > > > On 8/3/06, Sepand M <sepandm@gmail.com> wrote:
> > > > > > > Hi guys,
> > > > > > >
> > > > > > > Here are a few things:
> > > > > > > 1) I cannot use LDAP. We don't use it now, and don't want
to
> later. I
> > > > > > > understand if you want to use it, but I can't.
> > > > > > >
> > > > > > > 2) From what I understand (and my understanding isn't too
bad
> at this
> > > > > > > point), SSL sockets with needClientAuth just verify the
> client's cert
> > > > > > > against the CA. This means that the socket only does
> authentication
> > > > > > > and the rest is up to the broker (which seems perfect).
> > > > > > >
> > > > > > > 3) The other ideas we're getting like separating the user
from
> the
> > > > > > > connection (which I don't fully understand) seem like they
are
> > > > > > > overkill. To be done properly, they would need significant
> (not
> > > > > > > drastic, but significant) architectural rework (look at
things
> like
> > > > > > > UserIDBroker, and how the user ID is currently obtained
from
> the
> > > > > > > connection with the producer ID registration stuff) and
are
> fairly
> > > > > > > independent of the SSL thing.
> > > > > > >
> > > > > >
> > > > > > Yeah I think this is overkill too.
> > > > > >
> > > > > > > So here's my plan: I want to implement my original idea
(it's
> in this
> > > > > > > thread a few posts up) with (at most) the addition of a
> > > > > > > subject/principal back end for authorization. I say at
most
> because
> > > > > > > I've been working on my idea for a while and know exactly
how
> to do
> > > > > > > it; adding the subject/principal thing is a good design
choice
> but I'm
> > > > > > > hesitant to persue it since I don't know much about it
and I
> have a
> > > > > > > deadline (and therefore, would rather avoid having to read
> about it).
> > > > > > >
> > > > > > > If someone knows their stuff regarding to JAAS and is willing
> to work
> > > > > > > on it, I would be very glad to incorporate that into the
> design. If
> > > > > > > not, I must begin working on my implementation by the end
of
> the week
> > > > > > > (hopefully sooner).
> > > > > > >
> > > > > > > I would *REALLY* like to work with you guys, but I have
> deadlines to
> > > > > > > meet. I would also hate it if my work didn't make it into
the
> > > > > > > project's main branch, but I would totally understand if
you
> decided
> > > > > > > to go with your own ideas.
> > > > > > >
> > > > > > > On 8/3/06, Hiram Chirino <hiram@hiramchirino.com>
wrote:
> > > > > > > > On 8/3/06, David Jencks <david_jencks@yahoo.com>
wrote:
> > > > > > > > >
> > > > > > > > > On Aug 2, 2006, at 4:35 PM, Sepand M wrote:
> > > > > > > > >
> > > > > > > > > > Ok. So from what I've read, we're trying
to separate the
> authorization
> > > > > > > > > > part from the SSL socket and let the broker
handle it.
> > > > > > > > > > This sounds great. It would take more work
(not so great
> since I have
> > > > > > > > > > a deadline), but it would be a "proper"
solution.
> > > > > > > > > > From what I know of JAAS, the subject/principals
fully
> represent
> > > > > > > > > > identity. So attaching them to Connection
info would be
> a good idea.
> > > > > > > > > > That way, the Transport's job would be to
authenticate
> and the Broker
> > > > > > > > > > could handle authorization completely. This
would also
> mean that any
> > > > > > > > > > communication system could be used without
having to
> change the Broker
> > > > > > > > > > (as long as the Transport can authenticate
and create
> proper
> > > > > > > > > > subjet/principals).
> > > > > > > > > >
> > > > > > > > > > The one thing I will note is that we are
changing the
> ActiveMQ
> > > > > > > > > > architecture in that currently, the Brokers
are doing
> both
> > > > > > > > > > authentication and authorization (e.g. The
Brokers are
> currently doing
> > > > > > > > > > the user name and password validation).
> > > > > > > > > > I think, however, that this is necessary
because without
> our change,
> > > > > > > > > > there would need to be a new broker for
every new,
> authenticated,
> > > > > > > > > > communication system.
> > > > > > > > > >
> > > > > > > > > > Please tell me if you agree (in which case
I'll start
> looking at
> > > > > > > > > > implementation details).
> > > > > > > > >
> > > > > > > > > I thought about this some more and wonder if
it would be
> appropriate
> > > > > > > > > to consider using the full corba csiv2 framework
or a
> reasonable
> > > > > > > > > facsimile.  I think it would.  Very briefly here
is what
> it gives you:
> > > > > > > > >
> > > > > > > > > -both ends of the communication channel have
policies
> specifying what
> > > > > > > > > they can provide and require for security: they
negotiate
> a common
> > > > > > > > > policy.
> > > > > > > > >
> > > > > > > > > The policy can specify:
> > > > > > > > >
> > > > > > > > > - security level of channel (basically unprotected
or ssl)
> > > > > > > > >
> > > > > > > > > - validation of identity of server and client,
by user/pw
> or
> > > > > > > > > certificate chain
> > > > > > > > >
> > > > > > > > > - validation of identity of user by a variety
of
> mechanisms including
> > > > > > > > > user/pw, cert chain, and trusting the client.
> > > > > > > > >
> > > > > > > > > Perhaps the most important point here is that
the identity
> of the
> > > > > > > > > user and the client may not be the same: this
would
> typically be the
> > > > > > > > > case when the client is a broker forwarding messages
it
> got from
> > > > > > > > > somewhere else.  Here the ssl connection with
client
> certificates
> > > > > > > > > would be used to establish the identity of both
brokers
> but the user
> > > > > > > > > who originated the message would also be communicated
and
> used in
> > > > > > > > > authorization decisions.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Seem like a bit of overkill but the whole separating
the
> identity of
> > > > > > > > the user from the identity of the connection bit is
> interesting.
> > > > > > > > Could something similar be accomplished if each message
was
> signed by
> > > > > > > > the user before it was sent into the messaging system?
> > > > > > > >
> > > > > > > > > In other situations where the message sender
is a
> single-user client
> > > > > > > > > the client certificate can be used to establish
the
> identity of both
> > > > > > > > > the client and user.
> > > > > > > > >
> > > > > > > > > thanks
> > > > > > > > > david jencks
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message