activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sepand M" <sepa...@gmail.com>
Subject Re: Creating a secure connection system and using JMSXUserID support
Date Wed, 30 Aug 2006 22:21:16 GMT
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
> > >
> >
>

Mime
View raw message