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.172 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=Y8CxB/S6nkEb3eWSPGAp0oC6TdT97Zu86wusbE20deia/oGvZ8ynvZaWyYO2Y/MBxKoFVoVSxuWN7hys63YE+2aYO5C4k8UaTgnl/ZborvPlDdA/kTna3/GOMUanhHu6Bt3GZIz7/MdNvln56A84/6eYQ2sBD2IiIxQbdH3CYRE=
Message-ID: <af2843cd0608021220q4376940ak199aae8779d6a045@mail.gmail.com>
Date: Wed, 2 Aug 2006 15:20:08 -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: <5619195.post@talk.nabble.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>
	 <ec6e67fd0608010312xb9719eta868e8d932fce409@mail.gmail.com>
	 <5600217.post@talk.nabble.com>
	 <ec6e67fd0608011140j569efc15jc133d71dcdeab7b5@mail.gmail.com>
	 <bc2b53c50608011702n500850f4kac5a43e8967ced82@mail.gmail.com>
	 <5612820.post@talk.nabble.com>
	 <af2843cd0608020644j12905151oa7b1afece344caa3@mail.gmail.com>
	 <5617424.post@talk.nabble.com>
	 <af2843cd0608020959v9f6a7a0l8f6331f2c88f980a@mail.gmail.com>
	 <5619195.post@talk.nabble.com>

Hi,

On 8/2/06, ngcutura <ngcutura@gmail.com> wrote:
>
> Hmmm...  It didn't cross my mind but yes, indeed, it is possible.
>
> We may supply a fake truststore that would return 'true' for any certificate
> submitted for authentication and then perform real authentication after
> connection setup. We would then be able to obtain client certificate exactly
> as you stated.
>
> If we accept this approach, I see three components to implement:
>
> 1. Fake truststore
> 2. CertificateLoginModule (against LDAP)
> 3. Tweak connection setup to ask for peer certificates.
>
> In 3. we actually need some kind of policy reagarding authenitcation.
> Although SSL connection is established, a client may still supply
> username/password meaning that it should be used for login. I guess that
> obtaining client certificate from SSL session should be the last option.
>
> In 'Certificate login' thread I described another approach:
>
> We may use SSL without client authentication but find a way to export
> certificate to a String (on client side) and then supply that string as
> 'username' in createConnection(). On server side, the String would be
> converted back to certificate and authenticated. With this approach, we need
> to agree on the string format and conversion discipline and then only
> another JAAS login module is required (that would actually perform coversion
> from String to Certificate and authenticate). Thus no change is required in
> existing code. We may even add another non-portable
> createConnection(Certificate, brokerURL) that would convert Certificate to
> String and invoke createConnection(username, password, brokerURL). So, the
> necessary modules to implement would be:
>
> 1. Utility to convert Certificate to a string and back.
> 1a. (optional) createConnection(Certificate, brokerURL) method and
> ActiveMQConnection(Certifcate, brokerURL) constructor that perform
> conversion from Certificate to String using utility in #1 and invoke
> appropriate existing meothods/constructors.

This sounds fine to me too.  I would use the DN as the userId and
encode the certificate as a string for the password and add a
ActiveMQConnectionFactory.setCertificate( Certificate ) and have that
set userid/password.

> 2. JAAS login module that accepts username (and blank password; or whatever
> convenient) converts it back to Certificate using utility in #1 and
> authenticates it.
>

Yep, sounds good to me.  BTW, how easy is it to get Certificate
instance?  Is this susceptible to spoofing?

>
> I didn't like this approach at first but now it seems the quickiest (and the
> dirtiest) solution. Actually, it is developing a new protocol on exisitng
> facilities.
>
> Any thoughts?
>
> Regards,
> NGC
>
>
> Hiram Chirino wrote:
> >
> > I guess I don't understand what you mean by #2 but that could be due
> > to my ignorance of the SSL socket stuff.  So perhaps you can help me
> > understand what happens there...
> >
> > Lets assume we setup the ssl stuff to use 'need client auth'.  Could
> > we setup a truststore implementation that accepts any client
> > certificate or would this be a problem?
> >
> > Can you later get use the SSLScoket.getSession().getPeerCertificates()
> > when the ConnectionInfo command comes in and attach those certificates
> > to the command?
> >
> > Could that Certificate[] later be used against an LDAP JAAS module?
> >
> > Regards,
> > Hiram
> >
> > On 8/2/06, ngcutura <ngcutura@gmail.com> wrote:
> >>
> >>
> >> Hiram Chirino wrote:
> >> >
> >> > On 8/2/06, ngcutura <ngcutura@gmail.com> 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 <sepandm@gmail.com> 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 <james.strachan@gmail.com> wrote:
> >> >> >> > On 8/1/06, ngcutura <ngcutura@gmail.com> 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.
> >>
> >>
> >
> >
> > --
> > 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#a5619195
> Sent from the ActiveMQ - Dev forum at Nabble.com.
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com