| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Authenticate and Validate http messages in WMB v6 |
« View previous topic :: View next topic » |
| Author |
Message
|
| venkat kurra |
 Posted: Wed Jun 28, 2006 7:05 am Post subject: Authenticate and Validate http messages in WMB v6 |
 |
|
Master
Joined: 18 Oct 2001
Posts: 245
Location: Bloomington , IL
|
We are in the design stage and client want to Authenticate and Validate http messaes coming through HttpInput node.
Requirements are..
All ID and password credentials to be encrypted
All customer and other sensitive data must be encrypted during transport.
Before messages are queued, we need to Authenticate the sender of the message, Validate the message for well-formness,Validate the message for conformance to the defined message schema,If any of these validations fail, an error will be returned to the source system.
Client expected to guarantee delivery of all queued messages.
Can we guarantee? If it is MQ then 'yes'.
I think message validation could be done by messageset. Currect me if i am wrong.
I am not sure how to Authenticate the http message?
_________________
Thanks,
Venkat Kurra
IBM Certified Specialist-MQSeries
IBM Websphere MQSeries Administrator
IBM WebSphere Message Broker System Admin |
|
| Back to top |
|
 |
| vennela |
| Posted: Wed Jun 28, 2006 11:21 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Quote: |
| Can we guarantee? If it is MQ then 'yes'. |
You mean guarantee with transport as HTTP, I doubt.
For encryption etc, you can use SSL. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 28, 2006 2:25 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So, okay.
HTTPS (HTTP over SSL, or really over TLS - but they're the same thing) will allow you to authenticate the person who is PUTTING the HTTP document, because you will have given them a client certificate and you are authenticating against that.
Elsewise, you will have to put in a real web server and add something that will let you do password authentication, and then forward the PUT to the Broker HTTP listener.
If the HTTP message itself is bad for the HTTP standard, either the broker HTTP listener or the web server will fail the message that way.
To validate the data inside the HTTP message, you can model it and then validate it against the model - or you can hand-write validation logic yourself.
You need to make sure that both you and your client fully understand where the line of demarkation for "guarantee" is. From a pure technology point of view, you absolutely can't guarantee anything before the broker HTTP listener or the webserver has received the HTTP POST. You also can't guarantee that the person executing the POST will receive your HTTP reply.
You should read the Broker documentation on the HTTPInput node a little more to understand what levels of "transactionality" and recoverability you have once a message has hit that node. Then you can responsibly discuss with your client whether the "guarantee" demarkation point is in that flow, or only after a message has been put on a queue after the HTTP Reply is sent.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| venkat kurra |
| Posted: Wed Jun 28, 2006 5:49 pm Post subject: |
|
|
Master
Joined: 18 Oct 2001
Posts: 245
Location: Bloomington , IL
|
Thanks Jeff.
Just assume our flow is like this..
httpinput --> compute --> http request to service1 -->compute --> httpreply
if the service1 down for some reason then we are not able to send the responce back and we loose the message too. Is this currect?
I just started development and learning little hard way.
_________________
Thanks,
Venkat Kurra
IBM Certified Specialist-MQSeries
IBM Websphere MQSeries Administrator
IBM WebSphere Message Broker System Admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 04, 2006 6:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay, in this scenario you need to find out how long the sending client (the client hitting your HTTPInput) can wait for your response.
I bet they can't wait very long, and I bet they can't receive the response "later".
If they can wait very long, then you can put some kind of loop around the http request - like using the timeout nodes. Then, eventually, when the other service is available, then you can give the reply to the sending client.
If they can receive the response "later", then you can do
httpInput->httpreply->compute->MQoutput
(other flow)MQInput->compute -> http request->compute->"reply back to sending client".
Then you can do various things to loop in the second flow.
But again, you need to understand the SLA/"contract" that is expected at the HTTPInput node. And your client needs to understand that, and what it means.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
