Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of chirino@gmail.com designates
 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Ku0P6i343cqS+f5CiPzzCVYGm7BuxRJDii74SS3uYssvPNGjCsD3Xarbpx8GysDI0NkeV/WyMewCdVPqsCApsf6/ECtKJlPSRFfAjtDiFDArqC9nUY2xqnVW7xJ4LzgXhxu1btUNo8FxaoW1+w4mhfrD8YYT5lrcA39cSncLDCE=
Message-ID: <af2843cd0608030942w2439f1f0m392a8cfeb4e429e0@mail.gmail.com>
Date: Thu, 3 Aug 2006 12:42:37 -0400
From: "Hiram Chirino" <hiram@hiramchirino.com>
Sender: chirino@gmail.com
To: activemq-dev@geronimo.apache.org
Subject: Re: Creating a secure connection system and using JMSXUserID support
In-Reply-To: <bc2b53c50608030938r64bfca8fn5cddcdab195503fa@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <bc2b53c50607171206r6018e793oc4dc0a0ea7da7b12@mail.gmail.com>
	 <5617424.post@talk.nabble.com>
	 <af2843cd0608020959v9f6a7a0l8f6331f2c88f980a@mail.gmail.com>
	 <5619195.post@talk.nabble.com>
	 <af2843cd0608021220q4376940ak199aae8779d6a045@mail.gmail.com>
	 <C094368B-41AD-46E5-B146-BA0578556D38@yahoo.com>
	 <bc2b53c50608021635t5ae5dbe3t1aa75ff5360b676b@mail.gmail.com>
	 <89459BA6-8759-4B7C-8FD3-A91CD1371DB9@yahoo.com>
	 <af2843cd0608030908x519877e9u50c33e33bd3a0dde@mail.gmail.com>
	 <bc2b53c50608030938r64bfca8fn5cddcdab195503fa@mail.gmail.com>

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