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 Thu, 03 Aug 2006 10:35:28 GMT

I agree with this, I only think it will be a tough job.

I also have a deadline, so I suggest that we split the work.

I may take custom truststore and certificate authentication against LDAP (I
already have idea how to do it) but I am open to suggestions.

Regards,
NGC


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).
> 
> On 8/2/06, David Jencks <david_jencks@yahoo.com> wrote:
>> I'm confused by the descriptions of this approach, and don't
>> understand what is being proposed.  I would separate the steps of
>>
>> 1. validating the client certificate based on the presented
>> certificate chain, which in my experience can be done by the standard
>> truststore implementation that comes with java, and serves to
>> identify the client: this is done during the ssl connection setup
>>
>> and
>>
>> 2. deciding if the identified client is someone you want to let into
>> the system, which can be done with a JAAS login module that accepts
>> either a certificate chain callback handler (probably way overkill),
>> the client certificate (possibly overkill, we've already verified the
>> validity of the chain), or just the DN.  Keeping the DN in LDAP
>> should be no problem, perhaps mapped to the principals you want the
>> user to have: I think this could be done after the ssl connection is
>> set up
>>
>> and
>>
>> 3. deciding what permissions the logged in user should get.   You
>> might want to consider using a JACC like approach: I set up something
>> like this for portal permissions in jetspeed2 and suspect something
>> similar ought to work for amq.
>>
>> many thanks
>> david jencks
>>
>> On Aug 2, 2006, at 12:20 PM, Hiram Chirino wrote:
>>
>> > 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
>>
>>
> 
> 
-- 
View this message in context: http://www.nabble.com/Creating-a-secure-connection-system-and-using-JMSXUserID-support-tf1956575.html#a5630156
Sent from the ActiveMQ - Dev forum at Nabble.com.


Mime
View raw message