activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ngcutura <ngcut...@gmail.com>
Subject Re: Creating a secure connection system and using JMSXUserID support
Date Wed, 02 Aug 2006 16:32:22 GMT


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.


Mime
View raw message