Secure Email Gateway (SEG) Process Flow

SEG Architecture

The AirWatch Secure Email Gateway (SEG) is installed on premise through a self-configurable setup utility.  Though the SEG itself is installed on-premise, it can be used both in cloud and on-premise deployments of the AirWatch Console itself, as shown below.

High_Level_Design.png 

In both cloud and on-premise deployments, a quick overview of how the SEG manages email traffic is as follows:

  1. A device enrolls into AirWatch and AirWatch pushes down an email profile that connects the device to the SEG when attempting to sync email.
  2. The SEG will perform a compliance check on the device before completing the connection to the internal email server.
  3. If the device is permitted through the SEG, the SEG will then proxy the connection to the email server.

Technologies that power the SEG and its Associated Processes

Microsoft Message Queues (MSMQs)

  • AWMegPayload – Used to queue up SEG payloads (i.e. device sync time, device access state as reported by the SEG) from the API server before being saved to the database for dashboard real-time updates
  • AWSegCompliance – Used to queue up compliance evaluations (based on device events) before being sent to the SEG server by the MEG Queue Reader Service

Services

  • MEG Queue Reader – Typically resides on Console & Device Services servers, and reads from the MSMQs to either save SEG payloads to the database or fire off single-device policy updates to the SEG
  • EAS Integration – Resides on each SEG server, and allows for integration with the AW API & SEG clustering

AirWatch API Server

The SEG interfaces with the AirWatch API server through a SOAP API endpoint that acts as the interface between the SEG and the AirWatch database. The API serves to either retrieve bulk policy updates to send over to the SEG or receives SEG payloads to hand over to the AWMegPayloads queue to save to the AirWatch database. In many deployments, the AirWatch API is installed directly on the Device Services and/or Console server.

How SEG works

SEG_1.png

How do devices perform email sync via SEG proxy?

  1.  Policy refresh request – Email policies on the SEG server are refreshed in bulk based on the interval defined by the Rules Refresh Interval field (found in Advanced Configuration for the SEG in the AirWatch Console). This typically is defaulted to 60 minutes; thus, a SEG server (in a cluster, each SEG server) will refresh policies every 60 minutes.
  2. Get policies from database – The AirWatch API requests a list of allowed/blocked devices from the AirWatch database, which then sends that information to the SEG.
  3. The SEG then updates the policies and lists of certifications/devices that are able to access email. Note: In addition to the regular policy refresh, the AirWatch Console can notify the SEG to update its policy list any time a device changes compliance status (such as a new enrollment, or a previously enrolled device becoming compromised).
  4. A device then sends a mail sync request to the SEG.
  5. The SEG proxies the request if device is compliant.
  6. Information from the mail server is sent to the device.

Note: When implementing the SEG, it is recommended to allow incoming connections from the AirWatch Console/Device Services server.  This will allow single-policy updates from AirWatch to reach the SEG (as outlined in more detail in the sections below).  Otherwise, the SEG will only update based on its Rules Refresh Interval.

In the case of Google Apps deployments with the SEG server, the process flow changes very little at a high-level. In this deployment, the Web Listener (that is, the main SEG application pool) validates the password (PW1) presented by the device in the request, and then replaces it with the actual Google Apps password (PW2) before proxying the request to the email server.

Google_SEG.png 

How do devices show up on the email management dashboard?

The following figure describes the process to update the email management dashboard when a device tries to access email via the SEG. This process is designed to be near real-time, and allows the admin to view the state of the email environment from a single location.

  1. Device connects to the SEG (Web Listener) to sync for email.
  2. EAS Integration Service then sends the device request info and corresponding access state to the API endpoint.
  3. The API adds this to the AWMegPayloads queue (typically on the same server).
  4. The MEG Queue Reader Service reads this queue.
  5. Once successfully read off the queue, the data is stored in the database.
  6. The admin loads the email management dashboard to retrieve this information from the database.

 SEG_Dashboard.png

How does compliance get evaluated for devices in real-time?

Apart from the bulk policy updates that take place on a scheduled interval, AirWatch also evaluates and executes compliance for devices in real-time. These are called “single-device policy updates," and are sent to the SEG server every time a device state change event occurs — that is, every time the compliance state of a device needs to be updated on the SEG server.

Compliance is evaluated for a device on the following events taking place in AirWatch:

  • Enrollment (Device Services)
  • Scheduled check-in (Scheduler/Device Services)
  • Unenrollment (Device Services)
  • Manual updates from the AirWatch console (Console)

The following figure describes the process flow for single-device updates to the SEG server.

Single-Device_Updates.png 

 

  1. Device state change is triggered, and written to the AWSegCompliance queue.
  2. MEG Queue Reader Service reads the information from the queue.
  3. State change update is sent to the SEGConsole endpoint and is then written to the SEG server cache.
Have more questions? Submit a request

0 Comments

Article is closed for comments.