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.
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 <[EMAIL PROTECTED]> wrote:
>>
>>
>> Hiram Chirino wrote:
>> >
>> > On 8/2/06, ngcutura <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> >> >> > On 8/1/06, ngcutura <[EMAIL PROTECTED]> 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.
