Welcome!

@CloudExpo Authors: Yeshim Deniz, Elizabeth White, Pat Romanski, Zakia Bouachraoui, Liz McMillan

Related Topics: Cloud Security, Agile Computing

Cloud Security: Blog Feed Post

Kaazing WebSocket Gateway Security is Strong

Part 2 in a two-part blog post that discusses HTML5 WebSocket and security

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.

Read the original blog entry...

More Stories By Kaazing Blog

Kaazing is helping define the future of the event-driven enterprise by accelerating the Web for the Internet of Things.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


CloudEXPO Stories
Organizations planning enterprise data center consolidation and modernization projects are faced with a challenging, costly reality. Requirements to deploy modern, cloud-native applications simultaneously with traditional client/server applications are almost impossible to achieve with hardware-centric enterprise infrastructure. Compute and network infrastructure are fast moving down a software-defined path, but storage has been a laggard. Until now.
Adding public cloud resources to an existing application can be a daunting process. The tools that you currently use to manage the software and hardware outside the cloud aren’t always the best tools to efficiently grow into the cloud. All of the major configuration management tools have cloud orchestration plugins that can be leveraged, but there are also cloud-native tools that can dramatically improve the efficiency of managing your application lifecycle. In his session at 18th Cloud Expo, Alex Lovell-Troy, Director of Solutions Engineering at Pythian, presented a roadmap that can be leveraged by any organization to plan, analyze, evaluate, and execute on moving from configuration management tools to cloud orchestration tools. He also addressed the three major cloud vendors as well as some tools that will work with any cloud.
Transformation Abstract Encryption and privacy in the cloud is a daunting yet essential task for both security practitioners and application developers, especially as applications continue moving to the cloud at an exponential rate. What are some best practices and processes for enterprises to follow that balance both security and ease of use requirements? What technologies are available to empower enterprises with code, data and key protection from cloud providers, system administrators, insiders, government compulsion, and network hackers? Join Ambuj Kumar (CEO, Fortanix) to discuss best practices and technologies for enterprises to securely transition to a multi-cloud hybrid world.
With the proliferation of both SQL and NoSQL databases, organizations can now target specific fit-for-purpose database tools for their different application needs regarding scalability, ease of use, ACID support, etc. Platform as a Service offerings make this even easier now, enabling developers to roll out their own database infrastructure in minutes with minimal management overhead. However, this same amount of flexibility also comes with the challenges of picking the right tool, on the right provider and with the proper expectations. In his session at 18th Cloud Expo, Christo Kutrovsky, a Principal Consultant at Pythian, compared the NoSQL and SQL offerings from AWS, Microsoft Azure and Google Cloud, their similarities, differences and use cases for each one based on client projects.
In his session at 21st Cloud Expo, Raju Shreewastava, founder of Big Data Trunk, provided a fun and simple way to introduce Machine Leaning to anyone and everyone. He solved a machine learning problem and demonstrated an easy way to be able to do machine learning without even coding. Raju Shreewastava is the founder of Big Data Trunk (www.BigDataTrunk.com), a Big Data Training and consulting firm with offices in the United States. He previously led the data warehouse/business intelligence and Big Data teams at Autodesk. He is a contributing author of book on Azure and Big Data published by SAMS.