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 19:43:36 GMT

I wouldn't need a fake truststore. I would use a custom truststore that would
use a custom login module to authenticate the client via certificate (LDAP
would be just one of the login modules) and return authenticated subject and
principals.

This return seems complicated so fake truststore was an attempt to simplify
things. What I don't like about it is that it performs half of the normal
SSL authentication and then performs full authentication again on the broker
side.

I'll go for the original one. I'll try to find a way to return authenticated
subject and principals from the custom truststore and somehow make it
available to AMQ for later authorization.

I haven't gone through the AMQ code yet so I would gladly accept
suggestions.

Regards,
NGC


David Jencks wrote:
> 
> 
> On Aug 3, 2006, at 3:35 AM, ngcutura wrote:
> 
>>
>> 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.
> 
> I still don't understand why you would want to use a fake  
> truststore.  I would expect that you would want to use the standard  
> mechanisms to validate the supplied client cert chain, so you know by  
> the time the connection is set up the client has supplied a valid  
> cert chain, and then use a JAAS login module to decide if the  
> identified user is someone you want to let into the system.
> 
> I think that you will need a variety of approaches in the security  
> broker filter to extract the necessary info from the environment  
> (including the SSLSession and ConnectionInfo) and feed it into JAAS.
> 
> thanks
> david jencks
> 
>>
>> 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.
>>
> 
> 
> 
-- 
View this message in context: http://www.nabble.com/Creating-a-secure-connection-system-and-using-JMSXUserID-support-tf1956575.html#a5639382
Sent from the ActiveMQ - Dev forum at Nabble.com.


Mime
View raw message