This is the second post of a two-part blog post that discusses HTML5 WebSocket and security. The first post, HTML5 WebSocket Security is Strong, talked about the security benefits that derive from being HTTP-compatible and the WebSocket standard itself. In this, the second post, I will highlight some of the extra security capabilities that Kaazing WebSocket Gateway offers.

Kaazing WebSocket Gateway makes your Web application architecture more secure. We leverage the HTTP and WebSocket standards as well as Kaazing-specific technology for capabilities beyond what the standard provides, but what real-world applications typically need. What are some of those things? Read on…

• HTTP Authentication (Challenge/Response)

  Specified by RFC 2617, a WebSocket gateway/server can issue a standard HTTP challenge and receive a token or other authentication information in the HTTP Authorization header.

  The WebSocket gateway/server is the front line protecting your back-end server or application code. Rather than letting an untrusted (possibly malicious) user get access to the back-end service before discovering they don’t have credentials, you could prevent an unauthenticated user from even establishing a WebSocket connection in the first place.

  It’s the difference between letting someone through your front door in order to check their id versus checking their id outside the door first.

• Single Sign-On (SSO)

  Our customers are enterprise companies that will usually have an SSO or authentication framework already in place. Rather than impose our own (proprietary) security restrictions on them, Kaazing’s vision is to utilize standards and plug in to your existing security architecture using an open and customizable interface.

  When the Kaazing Gateway issues a (standards-based) challenge for a new WebSocket connection, if the client has an existing token or cookie then that can be returned to the Gateway for validation. Thus if a user is already signed into your SSO framework then they can also use a WebSocket application without the need to log in again.

  Users can authenticate using a token provider from popular security vendors, or public token providers such as Facebook or Twitter, or your own proprietary token service.

• Authentication Re-validation

  When using HTTP, a server has an opportunity (and overhead) with each individual request to re-authenticate the user. However a WebSocket connection is persistent; once a user has established the connection how do you enforce authentication rules?

  You could terminate the session and make the user re-authenticate. But what if have configured short sessions, such as 30 minutes? You don’t want to disconnect your users too often thereby causing them inconvenience. However you might not want long sessions either.

  Kaazing WebSocket Gateway can perform re-authentication without disconnecting your WebSocket connection. Staying consistent with the idea of plugging into your existing security framework, the Gateway will still rely on session rules dictated by your token provider rather than hard-coding them into the Gateway. And that’s the way it should be.

• Fine-grained Authorization Control

  Once a user is authenticated and logged in, you know they are who they claim to be. However that doesn’t entitle them to perform any operation or see any data they want. With Kaazing WebSocket Gateway you have fine-grained authorization that lets you specify precisely what application-level operations users can perform or what data they can see.

  In keeping with Kaazing’s philosophy of adhering to standards, the Gateway uses a standard authorization model based on JAAS (Java Authentication and Authorization Service).

• Distributed DMZ (DDMZ)

  Kaazing WebSocket Gateway was designed to live in a DMZ as the front-level protection for your back-end services. It offers encryption, authentication, authorization, and SSO to keep your trusted data safe.

  In addition, some security-conscious companies utilize layered DMZs for extra levels of protection on the Web. The Gateway has the capability to be distributed across DMZs so that each layer offers protection for the layer behind it. Users that don’t authenticate can fail fast closer to the user rather putting a burden on the center only to discover a user is not valid.

• Secure Emulation

  In the real-world, emulation is a vital component for a WebSocket application. Users may be using old browsers, or intermediaries can interfere with a WebSocket connection. Over time this problem will fade as WebSocket becomes ubiquitous, but in the meantime a robust application needs to contend those times when a WebSocket connection become established.

  Kaazing has the premier WebSocket emulation on the planet. One of the important reasons for that is because any security configuration you specify in the Gateway will apply to both native and emulated WebSocket connections. This is completely seamless and transparent. Your developers and administrators not only won’t have to configure things differently for native versus emulated, but they won’t be aware there even is a difference. In other words, configure the Gateway with your security preferences once, and those settings will apply to both native and emulated connections, as well as for all clients whether they are JavaScript, Flash, Silverlight, Java, or whether desktop, browser, or mobile.

• Unified Security

  Kaazing WebSocket Gateway unifies your architecture by acting as a single access point for your back-end services for a variety of client types. It doesn’t matter if your client is browser or mobile based, or whether you use JavaScript, Flash/Flex, Silverlight, or Java: you access the Gateway (and thus your back-end services) in the same way. Moreover it doesn’t matter if you’re using native WebSocket or emulation.

  This carries over to security as well. You configure security options once on the Gateway and those settings apply to all clients,irrespective of the client technology and whether desktop, browser, or mobile.

In case you can’t already tell, at Kaazing we take security seriously. That’s because we have to. Many of our customers are banks and financial institutions with stringent security requirements, providing critical data from back-end system to users over the Web.

While standard security techniques can make a WebSocket connection secure (assuming your WebSocket vendor implements them), robust, real-world applications need more. The ability to plug in to your existing SSO framework, adhere to your existing session rules, offer fine-grained authorization, and so on are key differentiators that provide security, flexibility, and ease-of-use.

Instead of developers building security elements into the application itself, administrators can configure various security options independently of the app. This lets your developers focus on what they should be focusing on: application logic and slick user interfaces.

• HTML5 WebSocket Security is Strong
• Kaazing Appoints Wall St Technology Expert as Director of Technology
• How to Deliver Rich Web Apps Accessible from Any Web-Enabled Device