| Author |
Message
|
| sfari |
 Posted: Tue Jun 15, 2004 6:04 am Post subject: Exits for End to End Encryption |
 |
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Hi
How can a end to end encryption be achieved for MQ?
We need to allow our Java developers to force there putting and getting application to encrypt respectively decrypt the message content. It is important that no sensitive data is stored in a readable form on the queue manager.
My idea is to solve this problem using a send exit on the putting side respectively a receive exit on the getting side. Is such a use of send an receive exit adequate, since they would not be in pairs on the same channels? (Here they would be used on both CLIENTCONN channels.)
Are there any alternatives to solve this problem? Has somebody already implemented something similar?
Any hint will be appreciated!
Thanks
Silvano |
|
| Back to top |
|
 |
| EddieA |
| Posted: Tue Jun 15, 2004 8:38 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| It is important that no sensitive data is stored in a readable form on the queue manager |
| Quote: |
| a send exit on the putting side respectively a receive exit on the getting side |
That won't solve your problem. The data would only be encrypted in the Channel. It would be "clear" on both thye sending and receiving QM.
You need some form of API exit.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Jun 15, 2004 8:43 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Take a look at TAMBI (Tivoli Access Manager for Business Integration) that does exactly what you are looking for and more...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| sfari |
| Posted: Tue Jun 15, 2004 10:49 pm Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Thanks for your replies!
I know there are products doing this but I don't get the budget for that, so have to solve it by myself.
Eddie, I know that usually send end receive exits are used in pairs on both end of one same channel. But I was thinking to use them in a different way.
To have a send exit with my putting program on the client side (no exit on the queue manager side of the channel)!
And to have the partner receive exit with my getting application again on the client side (no exit on the queue manger side of the channel)!
In this exits of course I would only touch the content and leave all the queue manager relevant data like message descriptor, TSH, ...
I was also thinking about using API exits, but as far as I know they are not supported for Java clients. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Jun 15, 2004 10:58 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| sfari wrote: |
| I know there are products doing this but I don't get the budget for that, so have to solve it by myself. |
End-to-End security and encryption are not things that are to be taken lightly (especially when you are serious about it and not use it as a 'phrase').
If you don't get a budget to do or support something, then it is not a serious problem/requirement!
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| sfari |
| Posted: Wed Jun 16, 2004 12:29 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
I completely understand your point Michael. But I don't think we should now discuss about what products my employer has to buy.
All I can say is that I got the task to implement end to end encryption for MQ! And this would not be the first security solution I am realizing.
All I need is a technical answer or statement to my questions and described idea!
Thanks
Silvano |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Jun 16, 2004 1:19 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| sfari wrote: |
I completely understand your point Michael. But I don't think we should now discuss about what products my employer has to buy.
|
I am not! I suggested to have a look at TAMBI.
You said we have no budget.
I just argued the fact you don't get the budget and have to come up with a solution that doesn't cost anything, that's not the way things work.
To help you ...
- does your environment consist of a platform mixed environment (Win/Unix/zOS)
- do you only use point to point connections or do you use a broker to route?
Just these two points alone make it difficult to develop something on your own that works everywhere... (we ARE talking end-to-end here...)
Also how do you plan on encrypting, using keys or simply hard code, if the later, someone willing to break your encryption in the end will.
I hope this helped...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| JLRowe |
| Posted: Wed Jun 16, 2004 2:42 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
TAMBI is a major proposition, I think there is a lite version that just does encyption for MQ. In anycase, there are several solutions around that use the API exits to encrypt messages.
At the java layer, he could just write a load of wrapper classes for jms and code to those. A whizzbang solution would be to use AOP to intercept the calls that go to JMS. |
|
| Back to top |
|
|
| sfari |
| Posted: Wed Jun 16, 2004 5:09 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
I would like to do something on the Java layer because I need to support only point to point MQ java clients.
It would be nice to have it transparently to the JMS developers so I would like to avoid a wrapper solution. That's the reason why I came up with the (may a bit unconventional, see above) send receive exit idea.
I can not imagine how to intercept the calls and encrypt the data using Aspect Oriented Programming (is it that what you mean with AOP)? Could you explain that?
Are API exits suitable if I am implementing a solution for Java only?
I will also have a look at TAMBI!
Thanks for the answers! |
|
| Back to top |
|
|
| JLRowe |
| Posted: Wed Jun 16, 2004 11:02 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
|
| Back to top |
|
|
| sfari |
| Posted: Fri Jun 18, 2004 1:31 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
This is really a great solution, thanks Jonathan! Since we don't use AOP yet this would mean for us to introduce a AOP product for our Application Platform Suite, which get used by many developers. This takes lot of time because of product evaluation and approvements from Architects and so on.
I found an interesting alternative. But it works only for JMS, which is ok for us.
I am wrapping the com.ibm.mq.jms provider with my own one. I had to extend the class com.ibm.mq.jms.MQQueueConnectionFactoryFactory to ensure that my own QueueConnectionFactory implementation get returned. Then I ensure that all factory methods (createConnection, createSession, createSender, ...) return my JMS provider classes. My own classes also implement the javax.jms interfaces but delegate all the calls to objects of com.ibm.mq.jms classes.
So I am able to manipulate the message in the send and receive calls.
Thanks again!
Silvano |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jun 18, 2004 4:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| sfari wrote: |
I found an interesting alternative. But it works only for JMS, which is ok for us.
I am wrapping the com.ibm.mq.jms provider with my own one. |
You could definately do this with the regular Java classes as well.
It might be a little more work, but it could be done.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sfari |
| Posted: Fri Jun 18, 2004 5:47 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
How would you do that? The main requirement for us is that the message manipulation has to be transparent to the MQ developers.
How could this be achieved with the regular MQ Java classes? Using this api objects are created directly not using factories like:
new MQQueueManager(...), new MQMessage(...), new MQQueue(...)
So in my opinion it is not possible to interfere without exchanging IBMs classees. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jun 18, 2004 6:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You'd have to write wrapper classes that would be used instead of the direct MQ classes.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| markhiscock |
| Posted: Tue Aug 22, 2006 6:58 am Post subject: |
|
|
Novice
Joined: 16 May 2005
Posts: 22
Location: IBM Hursley, UK
|
Hi,
Just to update on this thread that MQ Extended Security Edition (MQ and TAMBI) supports the JMS programming model.
Thanks,
mark |
|
| Back to top |
|
|
|
|
