Security Overview

Before you protect an application built with TX Text Control .NET Server, it helps to know where its documents are processed, which of its parts can be reached from the network and which protections TX Text Control provides itself. TX Text Control runs inside your application and on your servers, and it leaves decisions such as who may open a document to your code. The sections below describe this model and lead to the pages that show how to protect each part.

Where Documents Are Processed

Every part of TX Text Control .NET Server runs in your environment:

• ServerTextControl and MailMerge run in the process of your application. They need no separate service, backend process or network connection.
• The Document Viewer loads and renders documents in your ASP.NET Core application, with the engine in the same process.
• The Document Editor keeps each open document in the memory of its backend process TXTextControl.Web.Server.Core, in a worker process of its own for each connected editor. A document isn't stored anywhere until your code saves it, for example in a database.
• The license is compiled into your assembly. TX Text Control doesn't need an Internet connection or a license server to run your application.

Text Control states that it doesn't access, process or store customer data unless this is explicitly agreed upon in a separate contract. Generating documents on the server also keeps the data they're made from in your environment, where access control, encryption and logging can be enforced, as the blog article When to Generate Documents Server-Side Instead of Client-Side: A Focus on Data Security explains.

Some optional features reach outside your servers when you use them:

• Trusted timestamps. A digital signature with a timestamp sends a hash of the signature to the time server you specify. The document itself doesn't leave your system.
• Hosted language models. When the AI features of TX Text Control use a hosted model instead of a local one, the model receives the prompts and the document text in them, as Local and Hosted Models describes.
• PDF.js. The Document Viewer can render PDF documents with PDF.js, whose files come from your application or from a CDN, as Loading Documents describes.

The Text Control Private NuGet Feed is involved only while your project restores its packages, not at run time.

What an Application Exposes

An ASP.NET Core application with the Document Editor and the Document Viewer accepts these connections:

Browser
   |
   |  HTTPS: your pages and controllers, requests of the Document Viewer
   |  WSS:   editing sessions of the Document Editor at /api/TXWebSocket
   v
Your ASP.NET Core application
   WebSocketMiddleware, Document Viewer backend,
   ServerTextControl and MailMerge
   |
   |  plain TCP, port 4283 by default
   v
TXTextControl.Web.Server.Core (Document Editor backend)
   |
   v
One worker process for each connected editor

CORS policies don't apply to WebSocket connections, so the Document Editor connects to the WebSocket endpoint from any origin unless you restrict the origins, as WebSocket Security describes. The Document Viewer on another origin needs a CORS policy in the backend. WebSocket Architecture describes the path of an editor's connection in detail.

What TX Text Control Secures and What You Secure

The endpoints of the editor and the viewer are part of your application, and they need the same protection as the rest of it. TX Text Control provides the endpoints, and your application decides who may use them:

• Authentication and authorization. TX Text Control leaves them to ASP.NET Core and your code. The authentication and authorization middleware of ASP.NET Core covers the WebSocket connection of the editor only when it comes before UseTXWebSocketMiddleware in the pipeline. Text Control recommends a middleware that checks an access token before a request reaches the editor or the viewer; the tokens come from your own authorization layer, such as OAuth.
• Access to documents. The editor and the viewer show the documents your code loads into them. Whether a user may open, change or download a document is decided by your code.
• The backend port. The Document Editor backend accepts TCP connections from any client that reaches its port. Binding it to the loopback address or a private network keeps other clients out.
• The documents themselves. TX Text Control encrypts PDF documents, restricts their permissions, protects documents in the editor and signs PDF documents. Your code decides which of these a document gets.

The Software Supply Chain

• Packages. The TX Text Control packages come from the Text Control Private NuGet Feed, which authenticates you with your email address and an API token. Treat the token like a password; it's needed only while packages are restored. Keep Secrets Out of the Deployment keeps it out of servers and images.
• No secret at run time. Because the license is compiled into your assembly, a deployed application holds no license key or other secret for TX Text Control.
• Dependencies. Text Control develops TX Text Control almost entirely in-house, and its packages have few external dependencies. For the packages of version 34.0 and later, Text Control provides signed SBOMs that list their components, as SBOM describes.
• The supplier. Compliance covers the information security certification of Text Control and the regulations that apply to documents and software.

Next Steps

• Authentication: protect the endpoints of the editor, the viewer and your controllers.
• WebSocket Security: check the connection of the Document Editor before it's accepted.
• Secure Deployment: harden the server, the backend port and the deployment.
• Product Architecture: the parts of TX Text Control .NET Server and how they connect.