Documentation Index
Fetch the complete documentation index at: /llms.txt
Use this file to discover all available pages before exploring further.
This article describes what the enterprise app gateway is, the pain points of accessing intranet apps, solutions for accessing intranet apps, and how to enable and configure the enterprise app gateway.
| Pain Point | Description |
|---|---|
| High financial cost | Traditional VPN solutions are costly to deploy, and dedicated lines incur substantial fees every year. |
| Poor user experience | - Employees must install and configure the VPN client in advance, which is cumbersome. - They must first dial up the VPN before use, and the VPN disconnects on weak networks and requires reconnection. |
| Data insecurity | The inbound firewall ports must be kept open, which lets hackers scan the ports of intranet apps and launch attacks. |
| Difficult device delivery | The process from raising a purchase request to receiving, installing, and configuring a device usually takes several months and involves complex debugging. |
| Solution | Description |
|---|---|
| Set access policies for specific apps | Set access policies for specific apps by organization, department, role, or individual. |
| Simple configuration and fast delivery | Deploy only the Connector within your organization (which establishes a reverse persistent connection to the DingTalk server). A one-line installation script is provided. After installation, the admin completes delivery with simple configuration in the gateway console. |
| Full-link encryption | Quickly onboard intranet apps to DingTalk. After you install and deploy the Connector on your intranet server, a securely encrypted transmission channel is established between the gateway and the intranet. Requests from the employee’s DingTalk client are transmitted to the intranet server through this channel, and the server response is returned to the employee’s DingTalk client through the same channel. |
| Block illegal identities | Based on DingTalk identity authentication, the gateway’s authentication protects intranet resources and blocks malicious access from external parties. Only requests that pass DingTalk identity authentication are forwarded to the organization’s server. |
| Support for rewrite | With custom rewrite rules, the gateway supports rewriting the request header, request body, response header, and response body. |
| Product | Product Design Description |
|---|---|
| Client-side | - The DingTalk client mainly verifies user identity information to ensure the legitimacy of accessing users. - It binds employee identities based on DingTalk accounts to achieve secure identity verification and state maintenance. - It ensures account security through DingTalk’s built-in account risk control logic. - It prevents malicious attacks such as credential stuffing, account theft, and brute-force cracking. |
| Security gateway | - The core component of the DingTalk zero-trust security solution, this gateway is an identity-aware proxy. - It works at Layer 7 (the application layer) of the OSI model and implements a reverse proxy for the HTTP(S) protocol while verifying the legitimacy of every access request from the client. - Because the HTTP(S) protocol supports short connections and does not require persistent connections, it delivers highly stable remote access, works reliably on weak networks, and never “drops offline.” - This gateway is a SaaS service deployed as clusters across multiple regions. |
| Connector | - The Connector is deployed in the DMZ of the customer’s equipment room. - It establishes a reverse connection to the DingTalk enterprise app security gateway through the firewall, forwards client requests to internal apps, receives the returned content from internal apps, and sends it back to the client through the DingTalk enterprise app security gateway. - With this component, the intranet is hidden, and internal apps do not need to be exposed to the Internet through the firewall, greatly reducing attacks. |
Was this page helpful?
Developer Guide