Return-Path: Delivered-To: apmail-geronimo-activemq-dev-archive@www.apache.org Received: (qmail 5544 invoked from network); 19 Oct 2006 19:30:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Oct 2006 19:30:21 -0000 Received: (qmail 86621 invoked by uid 500); 19 Oct 2006 19:30:20 -0000 Delivered-To: apmail-geronimo-activemq-dev-archive@geronimo.apache.org Received: (qmail 86602 invoked by uid 500); 19 Oct 2006 19:30:20 -0000 Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: activemq-dev@geronimo.apache.org Delivered-To: mailing list activemq-dev@geronimo.apache.org Received: (qmail 86593 invoked by uid 99); 19 Oct 2006 19:30:20 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Oct 2006 12:30:20 -0700 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of chirino@gmail.com designates 66.249.92.170 as permitted sender) Received: from [66.249.92.170] (HELO ug-out-1314.google.com) (66.249.92.170) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Oct 2006 12:30:18 -0700 Received: by ug-out-1314.google.com with SMTP id 29so633362ugc for ; Thu, 19 Oct 2006 12:29:56 -0700 (PDT) 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:references:x-google-sender-auth; b=s0/6nu2XuxOb3M5695GHs429wiwP6AirPFIJCIknTqYr5cZBepJwA50D38zhCiwcl0DjpLFPiONCbO7cTPcGLkn8TkXwzn0H6DLJBKEVm2Kf9AqOTr4PZzeCjV0hyk6AHBnPZN23AjgUTqZDIrvh4TkS6pgNkXjJNza4Df1tlLc= Received: by 10.78.136.9 with SMTP id j9mr508067hud; Thu, 19 Oct 2006 12:29:56 -0700 (PDT) Received: by 10.78.142.5 with HTTP; Thu, 19 Oct 2006 12:29:56 -0700 (PDT) Message-ID: Date: Thu, 19 Oct 2006 14:29:56 -0500 From: "Hiram Chirino" Sender: chirino@gmail.com To: activemq-dev@geronimo.apache.org Subject: Re: Creating a secure connection system and using JMSXUserID support In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_87642_13699230.1161286196181" References: <89459BA6-8759-4B7C-8FD3-A91CD1371DB9@yahoo.com> <653849d10608031427u717986d4kcf337988972a6dd8@mail.gmail.com> X-Google-Sender-Auth: a88cd7884f9857f9 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_87642_13699230.1161286196181 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Sepand, Do you have any testcases where you atually use the SslBrokerService ?? On 8/30/06, Sepand M 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 wrote: > > Hi, > > > > The DN will overwrite the client-provided username (if any) when the > > SslTransport writes it. > > > > On 8/3/06, Kelly Campbell 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 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 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 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 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 wrote: > > > > > > > > On 8/3/06, David Jencks 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 ------=_Part_87642_13699230.1161286196181--