开发者

Websphere MQ Topic and SSL

开发者 https://www.devze.com 2023-01-31 15:38 出处:网络
I\'m trying to understand how common is the开发者_如何学Python usage of MQ Topics in the industry.

I'm trying to understand how common is the开发者_如何学Python usage of MQ Topics in the industry. And MQ with SSL?

Thanks, Guy


Pub/Sub
Prior to v7 of WMQ, Pub/Sub was available either as a separate component of WMQ or as part of the functionality of WebSphere Message Broker. Now in v7 pub/sub is integral to WMQ and allows topic-level security. There is a certain amount of pub/sub adoption that is occurring just because it is now baked into WMQ as native functionality.

Another factor influencing uptake on WMQ pub/sub is that more people are being exposed to it through WMQ File Transfer Edition. WMQ FTE makes status of file transfers available as publications and many people with this product are writing applications that monitor these topics to provide a variety of custom functionality. Once they start using pub/sub, many of these shops begin to see other uses for it.

Pub/Sub also solves some common problems with messaging such as an application that currently writes to a queue and a new requirement comes up to get a copy of that message to another consumer. Prior to v7, switching an app from writing to a queue to writing to a topic was somewhat invasive and required configuration changes for JMS apps or code changes for other types of code. The simplest way to address the problem was to intercept the message with an application or exit that wrote copies to two or more queues. As of v7 an application that was written for queues can be provided with an alias over a topic. The producer still thinks it is writing to a queue but WMQ is publishing the messages to a topic instead. Consumers can then either subscribe directly or, in the case of legacy code that requires a queue, an administrative subscription can cause the messages on the topic to be delivered to a queue. I am seeing a lot of uptake on pub/sub to address these kinds of requirement.

There are also the cases where pub/sub is the appropriate solution and it is used for that reason alone. In the past the requirement for separate components, administrative skill or a WMB license were barriers to adoption that caused a certain portion of pub/sub apps to be reworked as point-to-point. With pub/sub built into WMQ, these barriers are eliminated or at least significantly reduced which leads to more uptake simply because it is the right architecture for the problem at hand.

In general, I would say that WMQ pub/sub has gone mainstream with v7. Since v6 end-of-life has been announced for September 2011, there will be a mass migration to v7 this year and subsequently even more adoption of pub/sub as a result.

SSL/TLS
As for SSL, WMQ security is approaching mainstream. I wouldn't say SSL is the norm - just yet - but over the last two or three years it is in enough demand that my WMQ Hands-On Security Lab sessions at the IMPACT and European WebSphere Technical conferences have had overflow attendance. I recently wrote...

The term "trusted internal network" was coined to differentiate that part of the network that was internal from destinations outside the firewall. But the term "trusted" as used in this context is relative. It was not supposed to indicate that the internal network was trusted implicitly, only that it was more trusted than things outside the firewall. Unfortunately, the term is sometimes interpreted quite literally. I have had clients quite earnestly tell me by definition we trust everything on the "trusted internal network", that's why we call it that. Of course, this overstates the case, because even the staunchest believers in trusting the internal network still enforce password-based login to servers, databases, and applications. So the internal network is trusted, but only up to a point, and even on the internal network authentication and authorization are essential.

Although SSL (TLS, actually) channels encrypt, they also authenticate. As more people realize that they need to authenticate WMQ connections on the "trusted" internal network, SSL has been a common method of achieving that. Of course, there is also a growing requirement for privacy (encryption) and integrity services on the WMQ channels for both internal and external connections and this is driving adoption of WMQ SSL channels as well.

Now that SSL is more common, there are a number of secondary challenges that pop up when people do not fully understand WMQ security. The fact that these are now common topics on the WMQ listserve and on MQSeries.net attests to the level of SSL adoption. Some of these secondary issues are the inclusion of unused Certificate Authority root certs in the QMgr's keystore, or lack of QMgr channel settings like SSLPEER (which filters connections by distinguished name) or MCAUSER (which maps authorizations to a specific user account). Frequently people enable SSL but overlook one or more of these other settings and do not achieve the level of security they had intended. Since you must have enabled SSL for these things to present an issue, it is as a friend of mine says "a luxury problem." It is much better to be challenged by SSLPEER settings than not to have applied SSL at all.

In summary...
So I suppose the short answer to both of these questions is that use of pub/sub and SSL in WMQ is quite common. Both are on a sharp upward trend right now and if I were writing new applications I would definitely use SSL and would not hesitate to use WMQ pub/sub where called for.

0

精彩评论

暂无评论...
验证码 换一张
取 消