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 Thu, 03 Aug 2006 16:01:37 GMT
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
>

So are you saying that the SSL layer will accept a client cert as long
as it's signed by one of the certs in the trust store?

> 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
>

Verifying against the DN does seem to be the simplest route and I
think we just need a simple first implementation.

> 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.
>

We allready have a plugable authorization strategy in amq I don't see
this as being that hard part in this discussion.

> 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
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message