- Posted by: RICHARD SMITH
- Posted on: November 03 2008 17:15 EST
- Re: Kaazing Gateway 8.09_2 Atlantis is Now Available by Alexander Bell on November 05 2008 17:11 EST
- Re: Kaazing Gateway 8.09_2 Atlantis is Now Available by RICHARD SMITH on November 17 2008 17:03 EST
Very cool. I tried out the examples, impressive ;-) But in my opinon there are severel security issues. If i'm a bad guy, i could write a webpage that open a TCP connection (e.g. to any Queue-Manager) and for every user who enters the site i start to flood the server... perfect distributed attack :-( In that case the comet alternative is better, isn't it? I've found another Websocket implementation on http://orbited.org/. What are the diffrences between Kaazing Gateway and orbited? Ok orbited is written in python but are there any other differences? cheerz alex
In regard to security, network flooding is no more a security risk than it is in the vanilla Comet case. The general JMS case where we attempt to make the browser a subscriber to a JMS topic is a good example to examine. For Comet, each client browser connection to the Comet server requires the instantiation of a new JMS client. This means that despite having a separation of concerns in terms of the protocol interpreted by the client and the backend service (e.g. Bayuex to the browser and JMS to the Message Queue) there is still a one-to-one ratio between client connections and connections made to the backend service. You can be a little smarter about your connectivity to the JMS Queue by pooling JMS connections so that each Comet client is subscribing and publishing over the same JMS client instance, but this introduces a new security threat in that you allow client browsers to publish and subscribe without authenticating against the destination service. In the case of Kaazing Gateway, each JMS client is instantiated in the browser. This offloads a substantial amount of connection and object management from the traditional Java EE server. Secondly, the browser, in order to publish and subscribe to various topics, must authenticate against the message queue. As an added layer of security, you can also configure the gateway to authenticate users against various credentials stores (e.g. LDAP, database, XML, etc.) prior to attempting to connect to any backend services exposed by the gateway. In addition to layered authentication, the gateway also provides protocol validation, which means that it validates the bytes on the wire to ensure they are compatible with the destination service. This prevents malicious attacks where an end-user could attempt to push random data over a tcp connection in an effort to inundate a backend service. Beyond layered authentication and protocol validation, the gateway also provides an encrypted keyring service that allows you to tie credentials used for HTTP authentication to service authentication, making it easy to integrate SSO logins with service authentication. Thus, in terms of network traffic, poxying connections through Kaazing Gatway does not introduce anymore network traffic than that found in the classic Comet scenario. Furthermore, the gateway provides you with a rich set of security features that help you deture any would-be attackers. In regards to your question about differences between Orbited and Kaazing, both projects provide competing implementations of the HTML 5 WebSocket standard, but beyond high-level APIs the two projects differ substantially. The first major difference is security. The security features outlined above are absent from the Orbited project. The second difference is manageability. Kaazing's gateway is bundled with a number of JMX extensions which allow you to integrate with existing monitoring and management solutions such as OpenView. Another difference is that Kaazing's Entperise Gateway uses a single socket connection as its primary means of emulating the WebSocket interface, while the Orbited project defaults to an emulation mode that requires two HTTP connections. Finally, Orbited is, as you stated, based on Python which unlike Java is not multiprocessor aware. Thanks again for your questions and comments. I look forward to responding to any further questions or comments you may have.