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.
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.
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.
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).
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.
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.
The Kaazing WebSocket Gateway adheres to the WebSocket specification of the HTML5 standard, and enhances the standard’s basic security aspects by building security features and functionality into the Gateway to keep users and information safe over the Web. These security features help to protect your data and let you authenticate that users are who they say they are, and that they take only authorized actions. The Gateway provides several mechanisms for secure end-to-end connectivity. This includes WebSocket Secure (WebSocket + TLS/SSL), W3C Cross-Origin Resource Sharing, customizable authentication and authorization, single sign-on capabilities, and other security features. Furthermore, the Gateway integrates with Java Authentication and Authorization Service (JAAS), thus supporting pluggable authentication and authorization modules.
In addtion to support a pluggable model for enterprises to integrate their own security modules, the Kaazing WebSocket Gateway ships with support for the Kerberos authentication protocol, allowing you to proxy traffic to and from a Kerberos Key Distribution Center (KDC). This enables clients to communicate to a KDC over WebSocket. A gateway that is configured to proxy Kerberos traffic will be called a Ticket-Granting Gateway (TGG) in this section. This architecture provides all the benefits of a Kerberos-based security system to Web-based clients, without having to compromise overall site security by placing a KDC closer to the edge of the network.
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.
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.
