activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Creating a secure connection system and using JMSXUserID support
Date Wed, 02 Aug 2006 16:59:08 GMT
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

Mime
View raw message