SeaCat Mobile Secure Gateway Architecture

Introduction

SeaCat Mobile Secure Gateway is built using the SeaCat Application Security Platform. It provides strong protection against multiple types of cyberattacks by securing all application components, including the mobile application, network paths, which present an entry point to the enterprise network and application’s backend servers. It reduces an administrator's workload with easy PKI administration of distributed large-scale mobile applications. SeaCat Security Platform has been carefully designed to be flexible, fast, and highly secure.

SeaCat Mobile Secure Gateway is built for easy integration, along with providing a high level of protection against cyber threats on the application level, high data throughput with easy scale-out, and no single point of failure - all with no impact on the functionality of your apps. It provides a pleasant user security experience when other traditional methods fail (e.g. VPN for B2C mobile applications). SeaCat technology is FIPS 140-2 compliant, so, there’s no need to make security compromises.

SeaCat Mobile Secure Gateway Architecture Diagram

SeaCat Mobile Secure Gateway consists of two main parts: SeaCat Gateway and SeaCat SDK. The former is a server software that acts as a security gate between a public network and a private network to protect against threats and orchestrate its clients. It is typically deployed in the demilitarized zone as a cloud or on-premise appliance. SeaCat SDK is a software library, designed to be integrated with a protected mobile application with broad framework support.

SeaCat Gateway

SeaCat Gateway is built using POSIX standard and runs on various Linux, Apple Mac OS X and Windows operating systems. It supports all major virtualization platforms. It forwards valid and authorized client requests to respective application backends, simultaneously keeping out unauthorized users.

SeaCat Gateway shields application backends from direct internet exposure. This protects you against cyber attacks (such as volumetric DDoS, robots probing, or ports scanning), and prevents unauthorized access to application backends. Additional SeaCat Gateways are typically deployed to provide high availability and load resistance/balancing. The technology is designed to be easily scalable to handle potentially hundreds of thousands of client connections at the same time.

SeaCat Gateway is equipped by API for integration with other information systems like identity management or SIEM. It produces detailed audit trail for broad visibility to the behavior of application users. On the top of that, all SeaCat Gateways are connected to the Security Operation Centre with 24/7 surveillance and proactive reaction to identify anomalies.

The high efficiency of the C-programming language code results in low-performance needs: one CPU with 2GB of RAM can handle 1500 concurrent client connections with less than 20ms latency increase.

SeaCat SDK

SeaCat SDK acts as a SeaCat Gateway client. All protected applications need to integrate SeaCat SDK to access the application backend via SeaCat Gateways in a secure manner.

SeaCat SDK works independently of operating system capabilities. It contains the OpenSSL cryptographic module to allow the use of FIPS 140-2-compliant cryptography even on old devices. SeaCat SDK processes all relevant cryptographic procedures such as client onboarding, secure data store, renewals and revocations of client certificates. These functions are automated and don't require any attention from mobile application developers or administrators.

SeaCat SDK is also able to manage encrypted data storage, and integrates with iOS Secure Enclave or Android Keystore for advanced client security. Authorization techniques like two-factor authentication by PIN or NFC token are ready to perform even more secure authorization.

SeaCat SDK supports all major mobile operating systems. The size of SeaCat SDK is approximately 700kB per CPU architecture.

Application Backend

SeaCat’s transport channel works regardless of what data is transmitted over it. Application backends could use an HTTP/HTTPS service (such as REST, SOAP, or XML), or any other network service (e.g. JDBC connector, network share) - everything runs smoothly regardless. SeaCat Gateway simply forwards requests from authorized clients to one or more application backends, and then sends back the response.

Application backend selection depends on the discover service responsible for pinning SeaCat Gateways to a particular application backend. A Discover service is operated by TeskaLabs to allow load balancing across all SeaCat Gateways related to a particular application and thus corresponding application backends. These SeaCat Gateways share one certification authority for client authentication and authorization.

Authorization and Authentication

All client authorization and authentication are based on PKI. The client has its own private security key and certificate signed by SeaCat Gateway Certification Authority. Once the client has this valid and signed certificate, it can access the application backend resources. The client’s certificate is produced after the certification authority accepts their signing request.

The acceptance process for the client’s certificate signing request can either be done manually, automatically, or in a combination of both. Manual signing is best suited for business-critical applications where all clients are known and where all access requests to application backends require some approval process. Semi-automatic signing works in tandem with third-party applications like Identity Management or Microsoft Active Directory. Automatic signing has been created with B2C applications in mind, and is necessary for when the user is unknown, such as a new customer.

Application administrators can decline access to a client at any time. This unauthorization process then blacklists the client’s security certificate, and immediately disconnects them from all gateways.

If you’d like to get a true assessment of the security of your mobile application and its backend, please request a FREE Demo. Alternative you can visit our documentation or our SeaCat Mobile Secure Gateway product page to know how we can help you with the security of your mobile solutions.

About the Author

Ales Teska

TeskaLabs’ founder and CEO, Ales Teska, is a driven innovator who proactively builds things and comes up with solutions to solve practical IT problems.




You Might Be Interested in Reading These Articles

From State Machine to Stateless Microservice

In my last blog post, I wrote about implementing a state machine inside a microservice I call Remote Control that will automate deployments of our products and monitor the cluster. Here I would like to describe how all this was wrong and why I had to rewrite the code completely.

Continue reading ...

development tech eliska

Published on February 15, 2023

What’s The Difference Between Seacat and VPN?

One of the most common questions people asked us is if SeaCat some kind of a VPN? It's not. Virtual Private Network (VPN) extends a private network across a public network, providing secure connectivity from/to a mobile device. Every application on this device, thus now has access to the private network through the channel opened by VPN. This is safe up to a certain level because it is almost impossible to ensure the integrity of every application on the devices. Especially now when there are apps for everything, and users can download them from Google Play and the Apple store.

Continue reading ...

tech

Published on November 25, 2014

The Outrageous Cost of HTTPS - Why?

Mobile applications use HTTP communication between the application backend and the clients. Because of the demand for higher level of security, IT people implement HTTPS by setting up certificates issued by LetsEncrypt Certification Authority in their application backend server. The shift between non secure HTTP connections to HTTPS connections leads to a significant increase of amount of data being transferred from/to the clients. How is this possible?

Continue reading ...

tech

Published on June 14, 2016