Return-Path: Delivered-To: apmail-geronimo-activemq-dev-archive@www.apache.org Received: (qmail 70670 invoked from network); 2 Aug 2006 16:32:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Aug 2006 16:32:44 -0000 Received: (qmail 66959 invoked by uid 500); 2 Aug 2006 16:32:44 -0000 Delivered-To: apmail-geronimo-activemq-dev-archive@geronimo.apache.org Received: (qmail 66941 invoked by uid 500); 2 Aug 2006 16:32:44 -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 66932 invoked by uid 99); 2 Aug 2006 16:32:44 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Aug 2006 09:32:44 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of lists@nabble.com designates 72.21.53.35 as permitted sender) Received: from [72.21.53.35] (HELO talk.nabble.com) (72.21.53.35) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Aug 2006 09:32:42 -0700 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1G8Jdu-00043A-HA for activemq-dev@geronimo.apache.org; Wed, 02 Aug 2006 09:32:22 -0700 Message-ID: <5617424.post@talk.nabble.com> Date: Wed, 2 Aug 2006 09:32:22 -0700 (PDT) From: ngcutura 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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-Sender: ngcutura@gmail.com X-Nabble-From: ngcutura References: <653849d10607172015y457ba014s6cd8297dadfb8a23@mail.gmail.com> <5584494.post@talk.nabble.com> <5591352.post@talk.nabble.com> <5600217.post@talk.nabble.com> <5612820.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Hiram Chirino wrote: > > On 8/2/06, ngcutura wrote: >> >> Hi, >> >> I started another thread, unaware of this one, with the same aim. >> >> http://www.nabble.com/forum/ViewPost.jtp?post=5583011&framed=y >> >> So please allow me to share my views on this. >> >> If we are going to use SSL and SSL's built in client authentication, then >> I >> would use JAAS to authenticate the user via certificate. I would use LDAP >> to >> store and verify certificates and I guess It would be fairly easy to >> implement. There is already LDAPLoginModule and I implemented >> LDAPAuthorizationMap - cerificates should not be much harder. >> > > Sounds good! > >> The outcome of successful SSL client authentication should be >> authenticated >> Subject with all Princiapls set. This I woud put into ConnectionInfo - no >> need for DN or username. When AMQ has authenticated Subject, it can >> perform >> authorization in any of the existing ways. That is, we can safely >> separate >> authentication from authorization modules as long as AMQ gets Subject >> from >> the authentication process. >> > > agreed. > >> What I miss here is the point of Subject creation. If we totally rely on >> SSL >> for authentication we actually need an implementation of truststore >> (keystore with trust manager) that would verify client certificate and >> create login Subject. However, as this process is totally hidden from AMQ >> (I >> think that truststore and ConnectionInfo instance are unaware of each >> other), we would need another store (directory) to temporarrily save >> Subject >> and make it avaliable to AMQ once the connection is created. Or, if there >> is >> a way for truststore to interact with ConectionInfo instance, this >> problem >> is solved. > > I'm not familiar with the SSL details to get this done, so I may be > talking alot of BS here.... But it sounds like your saying that we > need associate our keystore with the SSL layer. But we want to store > our certs in LDAP. And right now those two layers would communicate > via a ConnectionInfo object. So I would say that in this case the > user is authenticating/logging in earlier than in normal cases. since > he is authentcating at connection setup time, I think you would need > to do the JAAS log in when the connection is estbalished. And attach > the JAAS subject to the ConnectionInfo. > > ---REPLY BEGINS--- > (I don't know how to produce '>' when quoting using the Web interface on > Nabble.) > > Your understanding is compatible with mine. :-) What I undestood from JSSE > is that it is actually a component that you may configure independantly of > the rest of the application. You specify a factory and a truststore and > connection is returned. SSL server and client authentication based on > certificates is configurable but totally hidden from the application. What > we can do to interfere is implement SSLSocketFactory and implement > truststore. > > Now, if we bypass client authentication during SSL handshake and leave it > until the connection is established, the question is how we obtain client > ceritifcate. If the client is not required to authenticate during SSL > handshake, it will not send its certificate to the server and we lose > possibility to perform client certificate authentication. Thus we need to > set 'need client auth' or 'want client auth' property to the server SSL > socket factory. (I saw a discussion thread where this was resolved in > AMQ.) In both cases, I believe (although I am not sure) client > ceritificate authentication wil be attempted. In case of 'need' > unsuccessful authentication will disconnect client while in the case of > 'want' connection will be created. Maybe this can be used in our case but > I am not sure how 'want' case is handled exactly. If there are any > restrictions imposed on such a connection, we lose the case. > > Back to the normal SSL handshake: if we implement our own truststore (we > need to) and our own SSL socket factory (we may) and create ConnectionInfo > instance before the actual connection (I am now talking unaware of the > actual code in AMQ - I have not studied it yet) maybe there would be a way > to pass ConnectionInfo instance to the custom SSL socket factory which > would then pass it to the custom truststore and we are in business. > > Some gymnastics, admitedly. :-) > > What we need to resolve is this: > > 1. In case of 'wantClientAuth' what are the consequences of unsuccessful > client authentication? Is the connection as good as authenticated or are > there any restrictions? > > 2. Is there a way to pass ConnectionInfo instance via factory to the > truststore as suggested? > > Answers to the above questions would give us a way to go. Still, if there > would be a positive answer to the question 2. I would go that way > regardless of the 1. Therefore, I volounteer to resolve 2. :-) > > Any ideas? > > Regards, > NGC > ---REPLY ENDS--- >> >> This approach requires implementation of CertificateLoginModule (JAAS) >> and >> custom truststore that would use this login module plus some temporary >> map. >> >> What do you thik about this? >> >> Regards, >> NGC >> >> >> Hiram Chirino wrote: >> > >> > On 8/1/06, Sepand M wrote: >> >> Hi all, >> >> >> >> So far I've mainly been reading ActiveMQ and making design docs. >> >> Here's what I've got: >> >> >> >> For authorization, my current plan is to just have the client's DN >> >> replace the user name field in the ConnectionInfo class (how this is >> >> done is explained below). I want to do this because I don't know much >> >> about JAAS and I'm trying to avoid writing classes to authorize based >> >> on DNs. If you guys know this stuff (and you probably do), we could >> >> change this easily enough. >> >> >> >> Here's the rest of my design: >> >> >> >> I want to modify SslTransportFactory to use a specific SslContext >> >> object and allow client's access to its init method so that they can >> >> set their own key and trust managers. I also want to create new >> >> SslTransport and SslTransportServer classes. SslTransport will be >> >> derived from TcpTransport. Its main task will be to replace the user >> >> name field of ConnectionInfo commands with its socket's DN (this could >> >> be changed easily to attach the entire certificate to ConnectionInfo >> >> as a new generic field). SslTransport will also make sure that it uses >> >> SslSocketFactory's. SslTransportServer will only be there to make sure >> >> SslSocketFactory's are used. >> >> >> >> For my current design that about does it. The proper Brokers and >> >> plugins (JaasAuthenticationBroker and AuthorizationPlugin) would have >> >> to be used and the configuration files would need to use the DN as the >> >> username. >> >> >> >> I'm not sure about this, but I think if we were to attach the complete >> >> certificate and try to do things "properly" we'd need a new >> >> CertificateAuthenticationBroker and a way for JAAS to authenticate >> >> that certificate (I'm new to JAAS so I don't know how easy/hard this >> >> would be). >> >> >> > >> > Sounds spot on! The JAAS part would totally depend on how the JAAS >> > module that authenticates against a certificate expects to receive the >> > certificate. Right now our current JAAS login only uses >> > userid/password, that would need to change for a cert. Anybody know >> > where we can get a JAAS module that authenticates certificates? >> > >> > Regards, >> > Hiram >> > >> >> Any thoughts? >> >> - Sepand >> >> >> >> On 8/1/06, James Strachan wrote: >> >> > On 8/1/06, ngcutura wrote: >> >> > > >> >> > > My JIRA username is 'ngcutura' and I'll be glad to assign LDAP >> >> Authorization >> >> > > issue to myself. >> >> > >> >> > Great! You're all set now with JIRA karma >> >> > >> >> > > I also take this opportunity to remind you of my code >> >> > > waiting for your review. :-) >> >> > >> >> > Thanks for the reminder - will try get there soon :) >> >> > >> >> > > I wouldn't mind creating and assigning certificate login but as >> >> Sepand was >> >> > > the first to raise it I'd wait for him (a while). >> >> > >> >> > Coolio >> >> > >> >> > -- >> >> > >> >> > James >> >> > ------- >> >> > http://radio.weblogs.com/0112098/ >> >> > >> >> >> > >> > >> > -- >> > Regards, >> > Hiram >> > >> > Blog: http://hiramchirino.com >> > >> > >> -- >> View this message in context: >> http://www.nabble.com/Creating-a-secure-connection-system-and-using-JMSXUserID-support-tf1956575.html#a5612820 >> Sent from the ActiveMQ - Dev forum at Nabble.com. >> >> > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > > -- View this message in context: http://www.nabble.com/Creating-a-secure-connection-system-and-using-JMSXUserID-support-tf1956575.html#a5617424 Sent from the ActiveMQ - Dev forum at Nabble.com.