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 Thu, 03 Aug 2006 17:58:44 GMT
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
>

Mime
View raw message