Re: Creating a secure connection system and using JMSXUserID support

[James Strachan <ja...@gmail.com>]

On 7/31/06, ngcutura <ng...@gmail.com> wrote:
>
> Hi,
>
> Has there been any progress on this issue? I have the same need in my
> project and am able to accept some work load to help this. (I was already
> going to start it myself, aanyway ;-) )

Great! We *love* contributors :)

So it sounds like you need to add one or more transient
fields/properties to the ConnectionInfo class so that you can pass in
any certificate details into the broker from the SSL transport. Then
you can make use of the certificates in the security plugin.
-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Creating a secure connection system and using JMSXUserID support

[Guillaume Nodet <gn...@gmail.com>]

There is one in ServiceMix.
http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/security/login/

On 8/2/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
>
> On 8/1/06, Sepand M <se...@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 <ja...@gmail.com> wrote:
> > > On 8/1/06, ngcutura <ng...@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
>



-- 
Cheers,
Guillaume Nodet

Re: Creating a secure connection system and using JMSXUserID support

[ngcutura <ng...@gmail.com>]

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 <da...@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 <ng...@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 <ng...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hiram Chirino wrote:
>>>>>>>>>
>>>>>>>>> On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com> wrote:
>>>>>>>>>>>>> On 8/1/06, ngcutura <ng...@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.

Re: Creating a secure connection system and using JMSXUserID support

[David Jencks <da...@yahoo.com>]

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 <da...@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 <ng...@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 <ng...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hiram Chirino wrote:
>>>>>>>>
>>>>>>>> On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com> wrote:
>>>>>>>>>>>> On 8/1/06, ngcutura <ng...@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.
>

Re: Creating a secure connection system and using JMSXUserID support

[ngcutura <ng...@gmail.com>]

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 <da...@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 <ng...@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 <ng...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >> Hiram Chirino wrote:
>> >> >> >
>> >> >> > On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com> wrote:
>> >> >> >> >> > On 8/1/06, ngcutura <ng...@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.

Re: Creating a secure connection system and using JMSXUserID support

[Hiram Chirino <hi...@hiramchirino.com>]

Hi Sepand,

Do you have any testcases where you atually use the SslBrokerService ??

On 8/30/06, Sepand M <se...@gmail.com> wrote:
>
> Hi all,
>
> I've seen a similar patch going out so I'm giving an update on this one.
>
> Currently, it does the following:
> - Allows for wantClientAuth and needClientAuth on SslTransport and
> SslTransportServer classes.
> - SslTransport attaches the client's certificate chain to
> ConnectionInfo in the newly added (not by me) connection context
> field.
> - Adds ActiveMQSslConnectionFactory and SslBrokerService, which can be
> used to specify trust and key managers from within code (otherwise,
> you can use the default ActiveMQConnectionFactory and BrokerService
> classes and just give an "ssl" URI)
> - Adds a new JaasCertificateAuthenticationPlugin and the corresponding
> broker which allow for authentication based on the certificate
>   - The above use the standard JAAS interface (with some new classes
> for handling SSL certs)
>   - These classes can be tied into the existing authorization system
> and UserIDBroker (JaasCertificateAuthenticationBroker will set the
> securityContext's username to one associated with the certificate
> based on CertificateLoginModule).
>
> It has no problems right now, but I'd rather test it more thoroughly
> before sending the patch. I should be done within the next 2 weeks.
>
> - Sepand
>
> On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > Hi,
> >
> > The DN will overwrite the client-provided username (if any) when the
> > SslTransport writes it.
> >
> > On 8/3/06, Kelly Campbell <ke...@gmail.com> wrote:
> > > Sepand,
> > >
> > > One possible gotcha I haven't heard anyone bring up that we should
> > > address is to make sure that someone can't just "fake" the DN in the
> > > username field through a normal login and make the system think it's
> > > authenticated with the certificate.
> > >
> > > -Kelly
> > >
> > > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > Hi Sepand,
> > > >
> > > > 4.1 and 4.0 branches are not that different yet.  If you need your
> > > > solution for 4.0, go ahead and do it.  Chances are we will only
> apply
> > > > it only to 4.1 (since this a new feature).
> > > >
> > > > On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > > > > Thanks Hiram. That sounds great.
> > > > >
> > > > > I guess my last question is: what branch do I work off of?
> Personally,
> > > > > I would like to build my stuff on a stable release (4.0.1), but
> I've
> > > > > looked at the svn logs and you guys seem to be pretty active
> around
> > > > > the stuff I want to change so I'm not sure how my changes could be
> > > > > reintegrated once I'm done.
> > > > >
> > > > > Any thoughts?
> > > > >
> > > > > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > > > Sepand,
> > > > > >
> > > > > > Do what you need to to get you project done, you cand send us
> tidbit
> > > > > > as you get it done and we can work on merging it back to the
> main
> > > > > > branch.  The great thing is that you have a use case that we
> want to
> > > > > > support, so if you put something together that work for you, I
> don't
> > > > > > see why it would not just go whole hog into the main branch.
> > > > > >
> > > > > > On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > > > > > > Hi guys,
> > > > > > >
> > > > > > > Here are a few things:
> > > > > > > 1) I cannot use LDAP. We don't use it now, and don't want to
> later. I
> > > > > > > understand if you want to use it, but I can't.
> > > > > > >
> > > > > > > 2) From what I understand (and my understanding isn't too bad
> at this
> > > > > > > point), SSL sockets with needClientAuth just verify the
> client's cert
> > > > > > > against the CA. This means that the socket only does
> authentication
> > > > > > > and the rest is up to the broker (which seems perfect).
> > > > > > >
> > > > > > > 3) The other ideas we're getting like separating the user from
> the
> > > > > > > connection (which I don't fully understand) seem like they are
> > > > > > > overkill. To be done properly, they would need significant
> (not
> > > > > > > drastic, but significant) architectural rework (look at things
> like
> > > > > > > UserIDBroker, and how the user ID is currently obtained from
> the
> > > > > > > connection with the producer ID registration stuff) and are
> fairly
> > > > > > > independent of the SSL thing.
> > > > > > >
> > > > > >
> > > > > > Yeah I think this is overkill too.
> > > > > >
> > > > > > > So here's my plan: I want to implement my original idea (it's
> in this
> > > > > > > thread a few posts up) with (at most) the addition of a
> > > > > > > subject/principal back end for authorization. I say at most
> because
> > > > > > > I've been working on my idea for a while and know exactly how
> to do
> > > > > > > it; adding the subject/principal thing is a good design choice
> but I'm
> > > > > > > hesitant to persue it since I don't know much about it and I
> have a
> > > > > > > deadline (and therefore, would rather avoid having to read
> about it).
> > > > > > >
> > > > > > > If someone knows their stuff regarding to JAAS and is willing
> to work
> > > > > > > on it, I would be very glad to incorporate that into the
> design. If
> > > > > > > not, I must begin working on my implementation by the end of
> the week
> > > > > > > (hopefully sooner).
> > > > > > >
> > > > > > > I would *REALLY* like to work with you guys, but I have
> deadlines to
> > > > > > > meet. I would also hate it if my work didn't make it into the
> > > > > > > project's main branch, but I would totally understand if you
> decided
> > > > > > > to go with your own ideas.
> > > > > > >
> > > > > > > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > > > > > On 8/3/06, David Jencks <da...@yahoo.com> wrote:
> > > > > > > > >
> > > > > > > > > On Aug 2, 2006, at 4:35 PM, 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).
> > > > > > > > >
> > > > > > > > > I thought about this some more and wonder if it would be
> appropriate
> > > > > > > > > to consider using the full corba csiv2 framework or a
> reasonable
> > > > > > > > > facsimile.  I think it would.  Very briefly here is what
> it gives you:
> > > > > > > > >
> > > > > > > > > -both ends of the communication channel have policies
> specifying what
> > > > > > > > > they can provide and require for security: they negotiate
> a common
> > > > > > > > > policy.
> > > > > > > > >
> > > > > > > > > The policy can specify:
> > > > > > > > >
> > > > > > > > > - security level of channel (basically unprotected or ssl)
> > > > > > > > >
> > > > > > > > > - validation of identity of server and client, by user/pw
> or
> > > > > > > > > certificate chain
> > > > > > > > >
> > > > > > > > > - validation of identity of user by a variety of
> mechanisms including
> > > > > > > > > user/pw, cert chain, and trusting the client.
> > > > > > > > >
> > > > > > > > > Perhaps the most important point here is that the identity
> of the
> > > > > > > > > user and the client may not be the same: this would
> typically be the
> > > > > > > > > case when the client is a broker forwarding messages it
> got from
> > > > > > > > > somewhere else.  Here the ssl connection with client
> certificates
> > > > > > > > > would be used to establish the identity of both brokers
> but the user
> > > > > > > > > who originated the message would also be communicated and
> used in
> > > > > > > > > authorization decisions.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Seem like a bit of overkill but the whole separating the
> identity of
> > > > > > > > the user from the identity of the connection bit is
> interesting.
> > > > > > > > Could something similar be accomplished if each message was
> signed by
> > > > > > > > the user before it was sent into the messaging system?
> > > > > > > >
> > > > > > > > > In other situations where the message sender is a
> single-user client
> > > > > > > > > the client certificate can be used to establish the
> identity of both
> > > > > > > > > the client and user.
> > > > > > > > >
> > > > > > > > > thanks
> > > > > > > > > david jencks
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Regards,
> > > > > > > > Hiram
> > > > > > > >
> > > > > > > > Blog: http://hiramchirino.com
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > Hiram
> > > > > >
> > > > > > Blog: http://hiramchirino.com
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Hiram
> > > >
> > > > Blog: http://hiramchirino.com
> > > >
> > >
> >
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Creating a secure connection system and using JMSXUserID support

[Sepand M <se...@gmail.com>]

Hi all,

I've seen a similar patch going out so I'm giving an update on this one.

Currently, it does the following:
- Allows for wantClientAuth and needClientAuth on SslTransport and
SslTransportServer classes.
- SslTransport attaches the client's certificate chain to
ConnectionInfo in the newly added (not by me) connection context
field.
- Adds ActiveMQSslConnectionFactory and SslBrokerService, which can be
used to specify trust and key managers from within code (otherwise,
you can use the default ActiveMQConnectionFactory and BrokerService
classes and just give an "ssl" URI)
- Adds a new JaasCertificateAuthenticationPlugin and the corresponding
broker which allow for authentication based on the certificate
  - The above use the standard JAAS interface (with some new classes
for handling SSL certs)
  - These classes can be tied into the existing authorization system
and UserIDBroker (JaasCertificateAuthenticationBroker will set the
securityContext's username to one associated with the certificate
based on CertificateLoginModule).

It has no problems right now, but I'd rather test it more thoroughly
before sending the patch. I should be done within the next 2 weeks.

- Sepand

On 8/3/06, Sepand M <se...@gmail.com> wrote:
> Hi,
>
> The DN will overwrite the client-provided username (if any) when the
> SslTransport writes it.
>
> On 8/3/06, Kelly Campbell <ke...@gmail.com> wrote:
> > Sepand,
> >
> > One possible gotcha I haven't heard anyone bring up that we should
> > address is to make sure that someone can't just "fake" the DN in the
> > username field through a normal login and make the system think it's
> > authenticated with the certificate.
> >
> > -Kelly
> >
> > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > Hi Sepand,
> > >
> > > 4.1 and 4.0 branches are not that different yet.  If you need your
> > > solution for 4.0, go ahead and do it.  Chances are we will only apply
> > > it only to 4.1 (since this a new feature).
> > >
> > > On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > > > Thanks Hiram. That sounds great.
> > > >
> > > > I guess my last question is: what branch do I work off of? Personally,
> > > > I would like to build my stuff on a stable release (4.0.1), but I've
> > > > looked at the svn logs and you guys seem to be pretty active around
> > > > the stuff I want to change so I'm not sure how my changes could be
> > > > reintegrated once I'm done.
> > > >
> > > > Any thoughts?
> > > >
> > > > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > > Sepand,
> > > > >
> > > > > Do what you need to to get you project done, you cand send us tidbit
> > > > > as you get it done and we can work on merging it back to the main
> > > > > branch.  The great thing is that you have a use case that we want to
> > > > > support, so if you put something together that work for you, I don't
> > > > > see why it would not just go whole hog into the main branch.
> > > > >
> > > > > On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > > > > > Hi guys,
> > > > > >
> > > > > > Here are a few things:
> > > > > > 1) I cannot use LDAP. We don't use it now, and don't want to later. I
> > > > > > understand if you want to use it, but I can't.
> > > > > >
> > > > > > 2) From what I understand (and my understanding isn't too bad at this
> > > > > > point), SSL sockets with needClientAuth just verify the client's cert
> > > > > > against the CA. This means that the socket only does authentication
> > > > > > and the rest is up to the broker (which seems perfect).
> > > > > >
> > > > > > 3) The other ideas we're getting like separating the user from the
> > > > > > connection (which I don't fully understand) seem like they are
> > > > > > overkill. To be done properly, they would need significant (not
> > > > > > drastic, but significant) architectural rework (look at things like
> > > > > > UserIDBroker, and how the user ID is currently obtained from the
> > > > > > connection with the producer ID registration stuff) and are fairly
> > > > > > independent of the SSL thing.
> > > > > >
> > > > >
> > > > > Yeah I think this is overkill too.
> > > > >
> > > > > > So here's my plan: I want to implement my original idea (it's in this
> > > > > > thread a few posts up) with (at most) the addition of a
> > > > > > subject/principal back end for authorization. I say at most because
> > > > > > I've been working on my idea for a while and know exactly how to do
> > > > > > it; adding the subject/principal thing is a good design choice but I'm
> > > > > > hesitant to persue it since I don't know much about it and I have a
> > > > > > deadline (and therefore, would rather avoid having to read about it).
> > > > > >
> > > > > > If someone knows their stuff regarding to JAAS and is willing to work
> > > > > > on it, I would be very glad to incorporate that into the design. If
> > > > > > not, I must begin working on my implementation by the end of the week
> > > > > > (hopefully sooner).
> > > > > >
> > > > > > I would *REALLY* like to work with you guys, but I have deadlines to
> > > > > > meet. I would also hate it if my work didn't make it into the
> > > > > > project's main branch, but I would totally understand if you decided
> > > > > > to go with your own ideas.
> > > > > >
> > > > > > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > > > > On 8/3/06, David Jencks <da...@yahoo.com> wrote:
> > > > > > > >
> > > > > > > > On Aug 2, 2006, at 4:35 PM, 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).
> > > > > > > >
> > > > > > > > I thought about this some more and wonder if it would be appropriate
> > > > > > > > to consider using the full corba csiv2 framework or a reasonable
> > > > > > > > facsimile.  I think it would.  Very briefly here is what it gives you:
> > > > > > > >
> > > > > > > > -both ends of the communication channel have policies specifying what
> > > > > > > > they can provide and require for security: they negotiate a common
> > > > > > > > policy.
> > > > > > > >
> > > > > > > > The policy can specify:
> > > > > > > >
> > > > > > > > - security level of channel (basically unprotected or ssl)
> > > > > > > >
> > > > > > > > - validation of identity of server and client, by user/pw or
> > > > > > > > certificate chain
> > > > > > > >
> > > > > > > > - validation of identity of user by a variety of mechanisms including
> > > > > > > > user/pw, cert chain, and trusting the client.
> > > > > > > >
> > > > > > > > Perhaps the most important point here is that the identity of the
> > > > > > > > user and the client may not be the same: this would typically be the
> > > > > > > > case when the client is a broker forwarding messages it got from
> > > > > > > > somewhere else.  Here the ssl connection with client certificates
> > > > > > > > would be used to establish the identity of both brokers but the user
> > > > > > > > who originated the message would also be communicated and used in
> > > > > > > > authorization decisions.
> > > > > > > >
> > > > > > >
> > > > > > > Seem like a bit of overkill but the whole separating the identity of
> > > > > > > the user from the identity of the connection bit is interesting.
> > > > > > > Could something similar be accomplished if each message was signed by
> > > > > > > the user before it was sent into the messaging system?
> > > > > > >
> > > > > > > > In other situations where the message sender is a single-user client
> > > > > > > > the client certificate can be used to establish the identity of both
> > > > > > > > the client and user.
> > > > > > > >
> > > > > > > > thanks
> > > > > > > > david jencks
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Regards,
> > > > > > > Hiram
> > > > > > >
> > > > > > > Blog: http://hiramchirino.com
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Hiram
> > > > >
> > > > > Blog: http://hiramchirino.com
> > > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> >
>

Re: Creating a secure connection system and using JMSXUserID support

[Sepand M <se...@gmail.com>]

Hi,

The DN will overwrite the client-provided username (if any) when the
SslTransport writes it.

On 8/3/06, Kelly Campbell <ke...@gmail.com> wrote:
> Sepand,
>
> One possible gotcha I haven't heard anyone bring up that we should
> address is to make sure that someone can't just "fake" the DN in the
> username field through a normal login and make the system think it's
> authenticated with the certificate.
>
> -Kelly
>
> On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > Hi Sepand,
> >
> > 4.1 and 4.0 branches are not that different yet.  If you need your
> > solution for 4.0, go ahead and do it.  Chances are we will only apply
> > it only to 4.1 (since this a new feature).
> >
> > On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > > Thanks Hiram. That sounds great.
> > >
> > > I guess my last question is: what branch do I work off of? Personally,
> > > I would like to build my stuff on a stable release (4.0.1), but I've
> > > looked at the svn logs and you guys seem to be pretty active around
> > > the stuff I want to change so I'm not sure how my changes could be
> > > reintegrated once I'm done.
> > >
> > > Any thoughts?
> > >
> > > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > Sepand,
> > > >
> > > > Do what you need to to get you project done, you cand send us tidbit
> > > > as you get it done and we can work on merging it back to the main
> > > > branch.  The great thing is that you have a use case that we want to
> > > > support, so if you put something together that work for you, I don't
> > > > see why it would not just go whole hog into the main branch.
> > > >
> > > > On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > > > > Hi guys,
> > > > >
> > > > > Here are a few things:
> > > > > 1) I cannot use LDAP. We don't use it now, and don't want to later. I
> > > > > understand if you want to use it, but I can't.
> > > > >
> > > > > 2) From what I understand (and my understanding isn't too bad at this
> > > > > point), SSL sockets with needClientAuth just verify the client's cert
> > > > > against the CA. This means that the socket only does authentication
> > > > > and the rest is up to the broker (which seems perfect).
> > > > >
> > > > > 3) The other ideas we're getting like separating the user from the
> > > > > connection (which I don't fully understand) seem like they are
> > > > > overkill. To be done properly, they would need significant (not
> > > > > drastic, but significant) architectural rework (look at things like
> > > > > UserIDBroker, and how the user ID is currently obtained from the
> > > > > connection with the producer ID registration stuff) and are fairly
> > > > > independent of the SSL thing.
> > > > >
> > > >
> > > > Yeah I think this is overkill too.
> > > >
> > > > > So here's my plan: I want to implement my original idea (it's in this
> > > > > thread a few posts up) with (at most) the addition of a
> > > > > subject/principal back end for authorization. I say at most because
> > > > > I've been working on my idea for a while and know exactly how to do
> > > > > it; adding the subject/principal thing is a good design choice but I'm
> > > > > hesitant to persue it since I don't know much about it and I have a
> > > > > deadline (and therefore, would rather avoid having to read about it).
> > > > >
> > > > > If someone knows their stuff regarding to JAAS and is willing to work
> > > > > on it, I would be very glad to incorporate that into the design. If
> > > > > not, I must begin working on my implementation by the end of the week
> > > > > (hopefully sooner).
> > > > >
> > > > > I would *REALLY* like to work with you guys, but I have deadlines to
> > > > > meet. I would also hate it if my work didn't make it into the
> > > > > project's main branch, but I would totally understand if you decided
> > > > > to go with your own ideas.
> > > > >
> > > > > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > > > On 8/3/06, David Jencks <da...@yahoo.com> wrote:
> > > > > > >
> > > > > > > On Aug 2, 2006, at 4:35 PM, 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).
> > > > > > >
> > > > > > > I thought about this some more and wonder if it would be appropriate
> > > > > > > to consider using the full corba csiv2 framework or a reasonable
> > > > > > > facsimile.  I think it would.  Very briefly here is what it gives you:
> > > > > > >
> > > > > > > -both ends of the communication channel have policies specifying what
> > > > > > > they can provide and require for security: they negotiate a common
> > > > > > > policy.
> > > > > > >
> > > > > > > The policy can specify:
> > > > > > >
> > > > > > > - security level of channel (basically unprotected or ssl)
> > > > > > >
> > > > > > > - validation of identity of server and client, by user/pw or
> > > > > > > certificate chain
> > > > > > >
> > > > > > > - validation of identity of user by a variety of mechanisms including
> > > > > > > user/pw, cert chain, and trusting the client.
> > > > > > >
> > > > > > > Perhaps the most important point here is that the identity of the
> > > > > > > user and the client may not be the same: this would typically be the
> > > > > > > case when the client is a broker forwarding messages it got from
> > > > > > > somewhere else.  Here the ssl connection with client certificates
> > > > > > > would be used to establish the identity of both brokers but the user
> > > > > > > who originated the message would also be communicated and used in
> > > > > > > authorization decisions.
> > > > > > >
> > > > > >
> > > > > > Seem like a bit of overkill but the whole separating the identity of
> > > > > > the user from the identity of the connection bit is interesting.
> > > > > > Could something similar be accomplished if each message was signed by
> > > > > > the user before it was sent into the messaging system?
> > > > > >
> > > > > > > In other situations where the message sender is a single-user client
> > > > > > > the client certificate can be used to establish the identity of both
> > > > > > > the client and user.
> > > > > > >
> > > > > > > thanks
> > > > > > > david jencks
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > Hiram
> > > > > >
> > > > > > Blog: http://hiramchirino.com
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Hiram
> > > >
> > > > Blog: http://hiramchirino.com
> > > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>

Re: Creating a secure connection system and using JMSXUserID support

[Kelly Campbell <ke...@gmail.com>]

Sepand,

One possible gotcha I haven't heard anyone bring up that we should
address is to make sure that someone can't just "fake" the DN in the
username field through a normal login and make the system think it's
authenticated with the certificate.

-Kelly

On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi Sepand,
>
> 4.1 and 4.0 branches are not that different yet.  If you need your
> solution for 4.0, go ahead and do it.  Chances are we will only apply
> it only to 4.1 (since this a new feature).
>
> On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > Thanks Hiram. That sounds great.
> >
> > I guess my last question is: what branch do I work off of? Personally,
> > I would like to build my stuff on a stable release (4.0.1), but I've
> > looked at the svn logs and you guys seem to be pretty active around
> > the stuff I want to change so I'm not sure how my changes could be
> > reintegrated once I'm done.
> >
> > Any thoughts?
> >
> > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > Sepand,
> > >
> > > Do what you need to to get you project done, you cand send us tidbit
> > > as you get it done and we can work on merging it back to the main
> > > branch.  The great thing is that you have a use case that we want to
> > > support, so if you put something together that work for you, I don't
> > > see why it would not just go whole hog into the main branch.
> > >
> > > On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > > > Hi guys,
> > > >
> > > > Here are a few things:
> > > > 1) I cannot use LDAP. We don't use it now, and don't want to later. I
> > > > understand if you want to use it, but I can't.
> > > >
> > > > 2) From what I understand (and my understanding isn't too bad at this
> > > > point), SSL sockets with needClientAuth just verify the client's cert
> > > > against the CA. This means that the socket only does authentication
> > > > and the rest is up to the broker (which seems perfect).
> > > >
> > > > 3) The other ideas we're getting like separating the user from the
> > > > connection (which I don't fully understand) seem like they are
> > > > overkill. To be done properly, they would need significant (not
> > > > drastic, but significant) architectural rework (look at things like
> > > > UserIDBroker, and how the user ID is currently obtained from the
> > > > connection with the producer ID registration stuff) and are fairly
> > > > independent of the SSL thing.
> > > >
> > >
> > > Yeah I think this is overkill too.
> > >
> > > > So here's my plan: I want to implement my original idea (it's in this
> > > > thread a few posts up) with (at most) the addition of a
> > > > subject/principal back end for authorization. I say at most because
> > > > I've been working on my idea for a while and know exactly how to do
> > > > it; adding the subject/principal thing is a good design choice but I'm
> > > > hesitant to persue it since I don't know much about it and I have a
> > > > deadline (and therefore, would rather avoid having to read about it).
> > > >
> > > > If someone knows their stuff regarding to JAAS and is willing to work
> > > > on it, I would be very glad to incorporate that into the design. If
> > > > not, I must begin working on my implementation by the end of the week
> > > > (hopefully sooner).
> > > >
> > > > I would *REALLY* like to work with you guys, but I have deadlines to
> > > > meet. I would also hate it if my work didn't make it into the
> > > > project's main branch, but I would totally understand if you decided
> > > > to go with your own ideas.
> > > >
> > > > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > > On 8/3/06, David Jencks <da...@yahoo.com> wrote:
> > > > > >
> > > > > > On Aug 2, 2006, at 4:35 PM, 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).
> > > > > >
> > > > > > I thought about this some more and wonder if it would be appropriate
> > > > > > to consider using the full corba csiv2 framework or a reasonable
> > > > > > facsimile.  I think it would.  Very briefly here is what it gives you:
> > > > > >
> > > > > > -both ends of the communication channel have policies specifying what
> > > > > > they can provide and require for security: they negotiate a common
> > > > > > policy.
> > > > > >
> > > > > > The policy can specify:
> > > > > >
> > > > > > - security level of channel (basically unprotected or ssl)
> > > > > >
> > > > > > - validation of identity of server and client, by user/pw or
> > > > > > certificate chain
> > > > > >
> > > > > > - validation of identity of user by a variety of mechanisms including
> > > > > > user/pw, cert chain, and trusting the client.
> > > > > >
> > > > > > Perhaps the most important point here is that the identity of the
> > > > > > user and the client may not be the same: this would typically be the
> > > > > > case when the client is a broker forwarding messages it got from
> > > > > > somewhere else.  Here the ssl connection with client certificates
> > > > > > would be used to establish the identity of both brokers but the user
> > > > > > who originated the message would also be communicated and used in
> > > > > > authorization decisions.
> > > > > >
> > > > >
> > > > > Seem like a bit of overkill but the whole separating the identity of
> > > > > the user from the identity of the connection bit is interesting.
> > > > > Could something similar be accomplished if each message was signed by
> > > > > the user before it was sent into the messaging system?
> > > > >
> > > > > > In other situations where the message sender is a single-user client
> > > > > > the client certificate can be used to establish the identity of both
> > > > > > the client and user.
> > > > > >
> > > > > > thanks
> > > > > > david jencks
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Hiram
> > > > >
> > > > > Blog: http://hiramchirino.com
> > > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>

Re: Creating a secure connection system and using JMSXUserID support

[Hiram Chirino <hi...@hiramchirino.com>]

Hi Sepand,

4.1 and 4.0 branches are not that different yet.  If you need your
solution for 4.0, go ahead and do it.  Chances are we will only apply
it only to 4.1 (since this a new feature).

On 8/3/06, Sepand M <se...@gmail.com> wrote:
> Thanks Hiram. That sounds great.
>
> I guess my last question is: what branch do I work off of? Personally,
> I would like to build my stuff on a stable release (4.0.1), but I've
> looked at the svn logs and you guys seem to be pretty active around
> the stuff I want to change so I'm not sure how my changes could be
> reintegrated once I'm done.
>
> Any thoughts?
>
> On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > Sepand,
> >
> > Do what you need to to get you project done, you cand send us tidbit
> > as you get it done and we can work on merging it back to the main
> > branch.  The great thing is that you have a use case that we want to
> > support, so if you put something together that work for you, I don't
> > see why it would not just go whole hog into the main branch.
> >
> > On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > > Hi guys,
> > >
> > > Here are a few things:
> > > 1) I cannot use LDAP. We don't use it now, and don't want to later. I
> > > understand if you want to use it, but I can't.
> > >
> > > 2) From what I understand (and my understanding isn't too bad at this
> > > point), SSL sockets with needClientAuth just verify the client's cert
> > > against the CA. This means that the socket only does authentication
> > > and the rest is up to the broker (which seems perfect).
> > >
> > > 3) The other ideas we're getting like separating the user from the
> > > connection (which I don't fully understand) seem like they are
> > > overkill. To be done properly, they would need significant (not
> > > drastic, but significant) architectural rework (look at things like
> > > UserIDBroker, and how the user ID is currently obtained from the
> > > connection with the producer ID registration stuff) and are fairly
> > > independent of the SSL thing.
> > >
> >
> > Yeah I think this is overkill too.
> >
> > > So here's my plan: I want to implement my original idea (it's in this
> > > thread a few posts up) with (at most) the addition of a
> > > subject/principal back end for authorization. I say at most because
> > > I've been working on my idea for a while and know exactly how to do
> > > it; adding the subject/principal thing is a good design choice but I'm
> > > hesitant to persue it since I don't know much about it and I have a
> > > deadline (and therefore, would rather avoid having to read about it).
> > >
> > > If someone knows their stuff regarding to JAAS and is willing to work
> > > on it, I would be very glad to incorporate that into the design. If
> > > not, I must begin working on my implementation by the end of the week
> > > (hopefully sooner).
> > >
> > > I would *REALLY* like to work with you guys, but I have deadlines to
> > > meet. I would also hate it if my work didn't make it into the
> > > project's main branch, but I would totally understand if you decided
> > > to go with your own ideas.
> > >
> > > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > > On 8/3/06, David Jencks <da...@yahoo.com> wrote:
> > > > >
> > > > > On Aug 2, 2006, at 4:35 PM, 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).
> > > > >
> > > > > I thought about this some more and wonder if it would be appropriate
> > > > > to consider using the full corba csiv2 framework or a reasonable
> > > > > facsimile.  I think it would.  Very briefly here is what it gives you:
> > > > >
> > > > > -both ends of the communication channel have policies specifying what
> > > > > they can provide and require for security: they negotiate a common
> > > > > policy.
> > > > >
> > > > > The policy can specify:
> > > > >
> > > > > - security level of channel (basically unprotected or ssl)
> > > > >
> > > > > - validation of identity of server and client, by user/pw or
> > > > > certificate chain
> > > > >
> > > > > - validation of identity of user by a variety of mechanisms including
> > > > > user/pw, cert chain, and trusting the client.
> > > > >
> > > > > Perhaps the most important point here is that the identity of the
> > > > > user and the client may not be the same: this would typically be the
> > > > > case when the client is a broker forwarding messages it got from
> > > > > somewhere else.  Here the ssl connection with client certificates
> > > > > would be used to establish the identity of both brokers but the user
> > > > > who originated the message would also be communicated and used in
> > > > > authorization decisions.
> > > > >
> > > >
> > > > Seem like a bit of overkill but the whole separating the identity of
> > > > the user from the identity of the connection bit is interesting.
> > > > Could something similar be accomplished if each message was signed by
> > > > the user before it was sent into the messaging system?
> > > >
> > > > > In other situations where the message sender is a single-user client
> > > > > the client certificate can be used to establish the identity of both
> > > > > the client and user.
> > > > >
> > > > > thanks
> > > > > david jencks
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Hiram
> > > >
> > > > Blog: http://hiramchirino.com
> > > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Creating a secure connection system and using JMSXUserID support

[Sepand M <se...@gmail.com>]

Thanks Hiram. That sounds great.

I guess my last question is: what branch do I work off of? Personally,
I would like to build my stuff on a stable release (4.0.1), but I've
looked at the svn logs and you guys seem to be pretty active around
the stuff I want to change so I'm not sure how my changes could be
reintegrated once I'm done.

Any thoughts?

On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Sepand,
>
> Do what you need to to get you project done, you cand send us tidbit
> as you get it done and we can work on merging it back to the main
> branch.  The great thing is that you have a use case that we want to
> support, so if you put something together that work for you, I don't
> see why it would not just go whole hog into the main branch.
>
> On 8/3/06, Sepand M <se...@gmail.com> wrote:
> > Hi guys,
> >
> > Here are a few things:
> > 1) I cannot use LDAP. We don't use it now, and don't want to later. I
> > understand if you want to use it, but I can't.
> >
> > 2) From what I understand (and my understanding isn't too bad at this
> > point), SSL sockets with needClientAuth just verify the client's cert
> > against the CA. This means that the socket only does authentication
> > and the rest is up to the broker (which seems perfect).
> >
> > 3) The other ideas we're getting like separating the user from the
> > connection (which I don't fully understand) seem like they are
> > overkill. To be done properly, they would need significant (not
> > drastic, but significant) architectural rework (look at things like
> > UserIDBroker, and how the user ID is currently obtained from the
> > connection with the producer ID registration stuff) and are fairly
> > independent of the SSL thing.
> >
>
> Yeah I think this is overkill too.
>
> > So here's my plan: I want to implement my original idea (it's in this
> > thread a few posts up) with (at most) the addition of a
> > subject/principal back end for authorization. I say at most because
> > I've been working on my idea for a while and know exactly how to do
> > it; adding the subject/principal thing is a good design choice but I'm
> > hesitant to persue it since I don't know much about it and I have a
> > deadline (and therefore, would rather avoid having to read about it).
> >
> > If someone knows their stuff regarding to JAAS and is willing to work
> > on it, I would be very glad to incorporate that into the design. If
> > not, I must begin working on my implementation by the end of the week
> > (hopefully sooner).
> >
> > I would *REALLY* like to work with you guys, but I have deadlines to
> > meet. I would also hate it if my work didn't make it into the
> > project's main branch, but I would totally understand if you decided
> > to go with your own ideas.
> >
> > On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > > On 8/3/06, David Jencks <da...@yahoo.com> wrote:
> > > >
> > > > On Aug 2, 2006, at 4:35 PM, 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).
> > > >
> > > > I thought about this some more and wonder if it would be appropriate
> > > > to consider using the full corba csiv2 framework or a reasonable
> > > > facsimile.  I think it would.  Very briefly here is what it gives you:
> > > >
> > > > -both ends of the communication channel have policies specifying what
> > > > they can provide and require for security: they negotiate a common
> > > > policy.
> > > >
> > > > The policy can specify:
> > > >
> > > > - security level of channel (basically unprotected or ssl)
> > > >
> > > > - validation of identity of server and client, by user/pw or
> > > > certificate chain
> > > >
> > > > - validation of identity of user by a variety of mechanisms including
> > > > user/pw, cert chain, and trusting the client.
> > > >
> > > > Perhaps the most important point here is that the identity of the
> > > > user and the client may not be the same: this would typically be the
> > > > case when the client is a broker forwarding messages it got from
> > > > somewhere else.  Here the ssl connection with client certificates
> > > > would be used to establish the identity of both brokers but the user
> > > > who originated the message would also be communicated and used in
> > > > authorization decisions.
> > > >
> > >
> > > Seem like a bit of overkill but the whole separating the identity of
> > > the user from the identity of the connection bit is interesting.
> > > Could something similar be accomplished if each message was signed by
> > > the user before it was sent into the messaging system?
> > >
> > > > In other situations where the message sender is a single-user client
> > > > the client certificate can be used to establish the identity of both
> > > > the client and user.
> > > >
> > > > thanks
> > > > david jencks
> > > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> > >
> >
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>

Re: Creating a secure connection system and using JMSXUserID support

[Hiram Chirino <hi...@hiramchirino.com>]

Sepand,

Do what you need to to get you project done, you cand send us tidbit
as you get it done and we can work on merging it back to the main
branch.  The great thing is that you have a use case that we want to
support, so if you put something together that work for you, I don't
see why it would not just go whole hog into the main branch.

On 8/3/06, Sepand M <se...@gmail.com> wrote:
> Hi guys,
>
> Here are a few things:
> 1) I cannot use LDAP. We don't use it now, and don't want to later. I
> understand if you want to use it, but I can't.
>
> 2) From what I understand (and my understanding isn't too bad at this
> point), SSL sockets with needClientAuth just verify the client's cert
> against the CA. This means that the socket only does authentication
> and the rest is up to the broker (which seems perfect).
>
> 3) The other ideas we're getting like separating the user from the
> connection (which I don't fully understand) seem like they are
> overkill. To be done properly, they would need significant (not
> drastic, but significant) architectural rework (look at things like
> UserIDBroker, and how the user ID is currently obtained from the
> connection with the producer ID registration stuff) and are fairly
> independent of the SSL thing.
>

Yeah I think this is overkill too.

> So here's my plan: I want to implement my original idea (it's in this
> thread a few posts up) with (at most) the addition of a
> subject/principal back end for authorization. I say at most because
> I've been working on my idea for a while and know exactly how to do
> it; adding the subject/principal thing is a good design choice but I'm
> hesitant to persue it since I don't know much about it and I have a
> deadline (and therefore, would rather avoid having to read about it).
>
> If someone knows their stuff regarding to JAAS and is willing to work
> on it, I would be very glad to incorporate that into the design. If
> not, I must begin working on my implementation by the end of the week
> (hopefully sooner).
>
> I would *REALLY* like to work with you guys, but I have deadlines to
> meet. I would also hate it if my work didn't make it into the
> project's main branch, but I would totally understand if you decided
> to go with your own ideas.
>
> On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > On 8/3/06, David Jencks <da...@yahoo.com> wrote:
> > >
> > > On Aug 2, 2006, at 4:35 PM, 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).
> > >
> > > I thought about this some more and wonder if it would be appropriate
> > > to consider using the full corba csiv2 framework or a reasonable
> > > facsimile.  I think it would.  Very briefly here is what it gives you:
> > >
> > > -both ends of the communication channel have policies specifying what
> > > they can provide and require for security: they negotiate a common
> > > policy.
> > >
> > > The policy can specify:
> > >
> > > - security level of channel (basically unprotected or ssl)
> > >
> > > - validation of identity of server and client, by user/pw or
> > > certificate chain
> > >
> > > - validation of identity of user by a variety of mechanisms including
> > > user/pw, cert chain, and trusting the client.
> > >
> > > Perhaps the most important point here is that the identity of the
> > > user and the client may not be the same: this would typically be the
> > > case when the client is a broker forwarding messages it got from
> > > somewhere else.  Here the ssl connection with client certificates
> > > would be used to establish the identity of both brokers but the user
> > > who originated the message would also be communicated and used in
> > > authorization decisions.
> > >
> >
> > Seem like a bit of overkill but the whole separating the identity of
> > the user from the identity of the connection bit is interesting.
> > Could something similar be accomplished if each message was signed by
> > the user before it was sent into the messaging system?
> >
> > > In other situations where the message sender is a single-user client
> > > the client certificate can be used to establish the identity of both
> > > the client and user.
> > >
> > > thanks
> > > david jencks
> > >
> >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Creating a secure connection system and using JMSXUserID support

[Sepand M <se...@gmail.com>]

Hi guys,

Here are a few things:
1) I cannot use LDAP. We don't use it now, and don't want to later. I
understand if you want to use it, but I can't.

2) From what I understand (and my understanding isn't too bad at this
point), SSL sockets with needClientAuth just verify the client's cert
against the CA. This means that the socket only does authentication
and the rest is up to the broker (which seems perfect).

3) The other ideas we're getting like separating the user from the
connection (which I don't fully understand) seem like they are
overkill. To be done properly, they would need significant (not
drastic, but significant) architectural rework (look at things like
UserIDBroker, and how the user ID is currently obtained from the
connection with the producer ID registration stuff) and are fairly
independent of the SSL thing.

So here's my plan: I want to implement my original idea (it's in this
thread a few posts up) with (at most) the addition of a
subject/principal back end for authorization. I say at most because
I've been working on my idea for a while and know exactly how to do
it; adding the subject/principal thing is a good design choice but I'm
hesitant to persue it since I don't know much about it and I have a
deadline (and therefore, would rather avoid having to read about it).

If someone knows their stuff regarding to JAAS and is willing to work
on it, I would be very glad to incorporate that into the design. If
not, I must begin working on my implementation by the end of the week
(hopefully sooner).

I would *REALLY* like to work with you guys, but I have deadlines to
meet. I would also hate it if my work didn't make it into the
project's main branch, but I would totally understand if you decided
to go with your own ideas.

On 8/3/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> On 8/3/06, David Jencks <da...@yahoo.com> wrote:
> >
> > On Aug 2, 2006, at 4:35 PM, 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).
> >
> > I thought about this some more and wonder if it would be appropriate
> > to consider using the full corba csiv2 framework or a reasonable
> > facsimile.  I think it would.  Very briefly here is what it gives you:
> >
> > -both ends of the communication channel have policies specifying what
> > they can provide and require for security: they negotiate a common
> > policy.
> >
> > The policy can specify:
> >
> > - security level of channel (basically unprotected or ssl)
> >
> > - validation of identity of server and client, by user/pw or
> > certificate chain
> >
> > - validation of identity of user by a variety of mechanisms including
> > user/pw, cert chain, and trusting the client.
> >
> > Perhaps the most important point here is that the identity of the
> > user and the client may not be the same: this would typically be the
> > case when the client is a broker forwarding messages it got from
> > somewhere else.  Here the ssl connection with client certificates
> > would be used to establish the identity of both brokers but the user
> > who originated the message would also be communicated and used in
> > authorization decisions.
> >
>
> Seem like a bit of overkill but the whole separating the identity of
> the user from the identity of the connection bit is interesting.
> Could something similar be accomplished if each message was signed by
> the user before it was sent into the messaging system?
>
> > In other situations where the message sender is a single-user client
> > the client certificate can be used to establish the identity of both
> > the client and user.
> >
> > thanks
> > david jencks
> >
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>

Re: Creating a secure connection system and using JMSXUserID support

[Hiram Chirino <hi...@hiramchirino.com>]

On 8/3/06, David Jencks <da...@yahoo.com> wrote:
>
> On Aug 2, 2006, at 4:35 PM, 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).
>
> I thought about this some more and wonder if it would be appropriate
> to consider using the full corba csiv2 framework or a reasonable
> facsimile.  I think it would.  Very briefly here is what it gives you:
>
> -both ends of the communication channel have policies specifying what
> they can provide and require for security: they negotiate a common
> policy.
>
> The policy can specify:
>
> - security level of channel (basically unprotected or ssl)
>
> - validation of identity of server and client, by user/pw or
> certificate chain
>
> - validation of identity of user by a variety of mechanisms including
> user/pw, cert chain, and trusting the client.
>
> Perhaps the most important point here is that the identity of the
> user and the client may not be the same: this would typically be the
> case when the client is a broker forwarding messages it got from
> somewhere else.  Here the ssl connection with client certificates
> would be used to establish the identity of both brokers but the user
> who originated the message would also be communicated and used in
> authorization decisions.
>

Seem like a bit of overkill but the whole separating the identity of
the user from the identity of the connection bit is interesting.
Could something similar be accomplished if each message was signed by
the user before it was sent into the messaging system?

> In other situations where the message sender is a single-user client
> the client certificate can be used to establish the identity of both
> the client and user.
>
> thanks
> david jencks
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Creating a secure connection system and using JMSXUserID support

[David Jencks <da...@yahoo.com>]

On Aug 2, 2006, at 4:35 PM, 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).

I thought about this some more and wonder if it would be appropriate  
to consider using the full corba csiv2 framework or a reasonable  
facsimile.  I think it would.  Very briefly here is what it gives you:

-both ends of the communication channel have policies specifying what  
they can provide and require for security: they negotiate a common  
policy.

The policy can specify:

- security level of channel (basically unprotected or ssl)

- validation of identity of server and client, by user/pw or  
certificate chain

- validation of identity of user by a variety of mechanisms including  
user/pw, cert chain, and trusting the client.

Perhaps the most important point here is that the identity of the  
user and the client may not be the same: this would typically be the  
case when the client is a broker forwarding messages it got from  
somewhere else.  Here the ssl connection with client certificates  
would be used to establish the identity of both brokers but the user  
who originated the message would also be communicated and used in  
authorization decisions.

In other situations where the message sender is a single-user client  
the client certificate can be used to establish the identity of both  
the client and user.

thanks
david jencks

>
> On 8/2/06, David Jencks <da...@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 <ng...@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 <ng...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >> Hiram Chirino wrote:
>> >> >> >
>> >> >> > On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com>  
>> wrote:
>> >> >> >> >> > On 8/1/06, ngcutura <ng...@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
>>
>>

Re: Creating a secure connection system and using JMSXUserID support

[Sepand M <se...@gmail.com>]

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 <da...@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 <ng...@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 <ng...@gmail.com> wrote:
> >> >>
> >> >>
> >> >> Hiram Chirino wrote:
> >> >> >
> >> >> > On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com> wrote:
> >> >> >> >> > On 8/1/06, ngcutura <ng...@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
>
>

Re: Creating a secure connection system and using JMSXUserID support

[Hiram Chirino <hi...@hiramchirino.com>]

On 8/2/06, David Jencks <da...@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 <ng...@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 <ng...@gmail.com> wrote:
> >> >>
> >> >>
> >> >> Hiram Chirino wrote:
> >> >> >
> >> >> > On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com> wrote:
> >> >> >> >> > On 8/1/06, ngcutura <ng...@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

Re: Creating a secure connection system and using JMSXUserID support

[David Jencks <da...@yahoo.com>]

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 <ng...@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 <ng...@gmail.com> wrote:
>> >>
>> >>
>> >> Hiram Chirino wrote:
>> >> >
>> >> > On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com> wrote:
>> >> >> >> > On 8/1/06, ngcutura <ng...@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

Re: Creating a secure connection system and using JMSXUserID support

[Hiram Chirino <hi...@hiramchirino.com>]

Hi,

On 8/2/06, ngcutura <ng...@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 <ng...@gmail.com> wrote:
> >>
> >>
> >> Hiram Chirino wrote:
> >> >
> >> > On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com> wrote:
> >> >> >> > On 8/1/06, ngcutura <ng...@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

Re: Creating a secure connection system and using JMSXUserID support

[ngcutura <ng...@gmail.com>]

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


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 <ng...@gmail.com> wrote:
>>
>>
>> Hiram Chirino wrote:
>> >
>> > On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com> wrote:
>> >> >> > On 8/1/06, ngcutura <ng...@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.

Re: Creating a secure connection system and using JMSXUserID support

[Hiram Chirino <hi...@hiramchirino.com>]

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 <ng...@gmail.com> wrote:
>
>
> Hiram Chirino wrote:
> >
> > On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com> wrote:
> >> >> > On 8/1/06, ngcutura <ng...@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

Re: Creating a secure connection system and using JMSXUserID support

[ngcutura <ng...@gmail.com>]

Hiram Chirino wrote:
> 
> On 8/2/06, ngcutura <ng...@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 <se...@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 <ja...@gmail.com> wrote:
>> >> > On 8/1/06, ngcutura <ng...@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.

Re: Creating a secure connection system and using JMSXUserID support

[Hiram Chirino <hi...@hiramchirino.com>]

On 8/2/06, ngcutura <ng...@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.

>
> 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 <se...@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 <ja...@gmail.com> wrote:
> >> > On 8/1/06, ngcutura <ng...@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

Re: Creating a secure connection system and using JMSXUserID support

[ngcutura <ng...@gmail.com>]

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.

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.

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.

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 <se...@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 <ja...@gmail.com> wrote:
>> > On 8/1/06, ngcutura <ng...@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.

Re: Creating a secure connection system and using JMSXUserID support

[Hiram Chirino <hi...@hiramchirino.com>]

On 8/1/06, Sepand M <se...@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 <ja...@gmail.com> wrote:
> > On 8/1/06, ngcutura <ng...@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

Re: Creating a secure connection system and using JMSXUserID support

[Sepand M <se...@gmail.com>]

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

Any thoughts?
- Sepand

On 8/1/06, James Strachan <ja...@gmail.com> wrote:
> On 8/1/06, ngcutura <ng...@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/
>

Re: Creating a secure connection system and using JMSXUserID support

[James Strachan <ja...@gmail.com>]

On 8/1/06, ngcutura <ng...@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/

Re: Creating a secure connection system and using JMSXUserID support

[ngcutura <ng...@gmail.com>]

My JIRA username is 'ngcutura' and I'll be glad to assign LDAP Authorization
issue to myself. I also take this opportunity to remind you of my code
waiting for your review. :-)

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

Regards,
NGC


James.Strachan wrote:
> 
> On 8/1/06, ngcutura <ng...@gmail.com> wrote:
>>
>> I was wondering whether the work on this is already in progress, to join
>> it
>> rather than starting my own implementation.
>>
>> Sepand, are you already on this? Can I help somwhow? Is there anyone else
>> coordinating work on this issue?
> 
> I don't know if anyone is working on this yet - I guess Sepand is the
> only one who might be?
> 
> How about we raise one or more JIRAs as needed then folks can assign
> the JIRAs to themselves to indicate what they are working on etc? i.e.
> use JIRA as our coordinator
> 
> If you don't have karma to assign issues to yourself send a quick mail
> to the dev list with the username you used to register to JIRA and I
> can grant you karma...
> 
> See the 'Using the issue tracker' section of
> http://incubator.apache.org/activemq/contributing.html
> 
> 
> -- 
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 
-- 
View this message in context: http://www.nabble.com/Creating-a-secure-connection-system-and-using-JMSXUserID-support-tf1956575.html#a5600217
Sent from the ActiveMQ - Dev forum at Nabble.com.

Re: Creating a secure connection system and using JMSXUserID support

[James Strachan <ja...@gmail.com>]

On 8/1/06, ngcutura <ng...@gmail.com> wrote:
>
> I was wondering whether the work on this is already in progress, to join it
> rather than starting my own implementation.
>
> Sepand, are you already on this? Can I help somwhow? Is there anyone else
> coordinating work on this issue?

I don't know if anyone is working on this yet - I guess Sepand is the
only one who might be?

How about we raise one or more JIRAs as needed then folks can assign
the JIRAs to themselves to indicate what they are working on etc? i.e.
use JIRA as our coordinator

If you don't have karma to assign issues to yourself send a quick mail
to the dev list with the username you used to register to JIRA and I
can grant you karma...

See the 'Using the issue tracker' section of
http://incubator.apache.org/activemq/contributing.html


-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Creating a secure connection system and using JMSXUserID support

[ngcutura <ng...@gmail.com>]

I was wondering whether the work on this is already in progress, to join it
rather than starting my own implementation.

Sepand, are you already on this? Can I help somwhow? Is there anyone else
coordinating work on this issue?

Regards,
NGC

James.Strachan wrote:
> 
> On 7/31/06, ngcutura <ng...@gmail.com> wrote:
>>
>> Hi,
>>
>> Has there been any progress on this issue? I have the same need in my
>> project and am able to accept some work load to help this. (I was already
>> going to start it myself, aanyway ;-) )
> 
> Great! We *love* contributors :)
> 
> So it sounds like you need to add one or more transient
> fields/properties to the ConnectionInfo class so that you can pass in
> any certificate details into the broker from the SSL transport. Then
> you can make use of the certificates in the security plugin.
> -- 
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 
-- 
View this message in context: http://www.nabble.com/Creating-a-secure-connection-system-and-using-JMSXUserID-support-tf1956575.html#a5591352
Sent from the ActiveMQ - Dev forum at Nabble.com.