Hi,
On 8/2/06, ngcutura <[EMAIL PROTECTED]> 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 <[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.
--
Regards,
Hiram
Blog: http://hiramchirino.com
