Set up other SIA components
āSIAā provides workflows in Enterprise Center that guide you through the process of setting up these features:
-
āSIAā Proxy. You can set up these configurations of āSIAā Proxy:
-
Selective Proxy. Scans risky domains and any of its associated URLs. For more information on setting up the selective proxy, see Set up selective proxy.
-
Full Web Proxy. Allows āSIAā Proxy to act as a Secure Web Gateway (SWG). The full proxy performs URL filtering and anti-malware scanning on all web traffic. For more information on setting up the full web proxy, see Set up a full web proxy.
-
-
Identity providers. You can set up an identity provider (IdP) to enable authentication and restrict access to specific users or groups in your organization. For more information, see Set up an identity provider.
Set up the selective proxy
The Selective Proxy Setup workflow guides you through the process of configuring āSIAā Proxy as a selective proxy. The selective proxy is a configuration of āSIAā Proxy that scans only risky domains and its URLs. With the selective proxy, āSIAā Threat Intelligence detects that a domain contains a suspicious URL. Traffic to risky domains is then sent to āSIAā Proxy where specific URLs are blocked, monitored, or analyzed in accordance with a policy. With the easy integration of the selective proxy, you can optimize security with minimal impact to users. If your enterprise needs to scan all web traffic, see Set up a full web proxy.

To set up the selective proxy:
-
Generate the āSIAā Proxy certificate.
āSIAā Proxy is a "trusted intermediary" that decrypts, inspects, and re-encrypts all Transport Layer Security (TLS) traffic from enterprise managed computers. This gives āSIAā visibility into TLS encrypted traffic and allows it to protect an enterprise from threats, while preserving confidentiality and integrity of traffic to origin websites.
For āSIAā Proxy to decrypt and inspect traffic, a man-in-the-middle (MITM) certificate authority (CA) TLS certificate is required. This certificate needs to be distributed to an organization's trust store or TLS clients in your network.
You can generate this certificate in āSIAā or you can upload an intermediate certificate. You upload an intermediate certificate if your organization already has a public key infrastructure and maintains an internal CA root certificate. For more information, see āSIAā Proxy MITM certificate.
To complete this step in the workflow, you need to:
-
Generate a certificate in āSIAā, distribute it to TLS clients, and activate it in āSIAā. For instructions, see Create an āAkamaiā certificate.
-
Generate a certificate signing request (CSR) in āSIAā, sign the request with your organization's CA, and upload the certificate to āSIAā. You can then distribute the certificate to client devices and activate it in āSIAā. For instructions, see Create a non-āAkamaiā certificate.
For instructions on distributing the certificate to desktop devices, see Distribute the āSIAā Proxy certificate. For more information on how to distribute the certificate to mobile devices for āETP Clientā, see Distribute the mobile client and go to the instructions that are specific to your Mobile Device Management (MDM) solution.
-
-
Configure a policy for the selective proxy.
This process involves:
-
Enabling āSIAā Proxy
-
Choosing Selective Proxy as the Operating Mode setting for access control.
-
Choosing Selective Proxy as the mode for iOS, Android, and Chrome OS devices. The mobile mode settings are currently in beta.
For instructions on configuring the policy, see Enable selective proxy.
-
-
If you havenāt done so already, deploy the policy.
For your policy configuration to take effect, you need to deploy it to the āSIAā network.
For more information, see Deploy configuration changes.
Set up the full web proxy
The Full Proxy Setup workflow guides you through the process of configuring āSIAā Proxy as a full web proxy that scans all web traffic. This configuration allows āSIAā Proxy to act as a SWG that performs URL filtering and anti-malware scanning in your current network configuration.
You configure āSIAā Proxy as a full web proxy with one of these methods:
-
Proxy chaining. Directs all HTTP and HTTPS traffic from your organizationās on-premises web proxy to āSIAā Proxy. For more information, see Set up proxy chaining.
-
āETP Clientā. You can forward all HTTP and HTTPS traffic to āSIAā Proxy. This occurs when you set āETP Clientā as the local web proxy on the userās machine, you use āETP Clientā with an existing enterprise proxy, or you enable transparent traffic interception. For more information, see About āETP Clientā.

While not shown in this workflow, you can also configure the full web proxy with Security Connector as an HTTP Forwarder, by directing traffic from the userās browser or system to the proxy, or with IPsec tunnels. To learn more, see Security Connector as an HTTP Forwarder, Configure the proxy in browsers, or Set up IPsec tunnels.
To set up the full proxy:
-
Generate the āSIAā Proxy certificate.
āSIAā Proxy is a ātrusted intermediaryā that is able to decrypt, inspect, and re-encrypt all TLS traffic from enterprise managed computers. This gives āSIAā visibility into TLS encrypted traffic and allows it to protect an enterprise from threats, while preserving confidentiality and integrity of traffic to origin web sites.
For āSIAā Proxy to decrypt and inspect traffic, a MITM CA TLS certificate is required. This certificate needs to be distributed to an organizationās trust store or TLS clients in your network.
You can generate this certificate in āSIAā or you can upload an intermediate certificate. You upload an intermediate certificate if your organization already has a public key infrastructure and maintains an internal CA root certificate. For more information, see āSIAā Proxy MITM certificate.
To complete this step in the workflow, you need to:
-
Generate a certificate in āSIAā, distribute it to TLS clients, and activate it in āSIAā. For instructions, see Create an āAkamaiā certificate.
-
Generate a CSR in āSIAā, sign the request with your organizationās CA, and upload the certificate to āSIAā. You can then distribute the certificate to client devices and activate it in āSIAā. For instructions, see Create a non-āAkamaiā certificate.
For instructions on distributing the certificate to desktop devices, see Distribute the āSIAā Proxy certificate. For more information on how to distribute the certificate to mobile devices for āETP Clientā, see Distribute the mobile client and go to the instructions that are specific to your MDM solution.
-
-
Configure internal IP addresses, domains, and DNS suffixes for traffic that you donāt want scanned by āSIAā Proxy.
If there are domains, IP addresses, and DNS suffixes that you donāt want directed to āSIAā Proxy, such as domains for internal websites, you can configure them in the Local Bypass Settings. For instructions, see Configure local bypass settings.
-
If you want to direct web traffic to the proxy with āETP Clientā, set up the client. You can deploy the client to desktop or mobile devices on your network. You can configure āETP Clientā as a local web proxy that forwards requests to āSIAā Proxy or if your enterprise includes an on-premises proxy, you can also configure proxy chaining to forward requests from the on-premises proxy to āSIAā Proxy. You can also use the full web proxy by enabling transparent traffic interception. For more information, see āETP Clientā for web traffic.
If you plan to use āETP Clientā as a local web proxy, make sure you enable these settings.
-
Enable āETP Clientā as Proxy. This policy setting modifies the local web proxy settings on the userās machine and in turn, enables āETP Clientā as the local web proxy.
In addition to choosing whether to enable this setting, you can also choose to modify the local web proxy only when no web proxy is configured on the userās machine.
You can also enable the Configure āETP Clientā as local computer web proxy setting in the client configuration. For more information, see āETP Clientā configuration settings. The Enable āETP Clientā as Proxy setting in the policy takes precedence over the client configuration setting.
-
Proxy Port. If āETP Clientā modifies the local web proxy settings on the userās computer, it listens for traffic on port 8080 by default. If this port is used by another process in your network, you can enter a new port into this field. You enable this setting in the client configuration settings. For more information, see āETP Clientā configuration settings.
To set up the desktop or mobile version of the client, see Prepare for āETP Clientā setup.
Using āETP Clientā for a full web proxy configuration is optional in this setup only if you plan to implement a proxy chaining configuration. To set up a full web proxy, you need to either set up āETP Clientā for web traffic or set up proxy chaining.
-
-
If you want to forward traffic from your on-premises proxy to āSIAā Proxy, configure proxy chaining. For more information, see Set up on-premises proxy for āSIAā full web proxy.
As part of a proxy chaining configuration, you need to enable these policy settings:
-
Trust X-Forwarded-For (XFF) header. The XFF header contains the client IP address. It prevents users from anonymizing their IP address or configuring their browser to inject a fake XFF with a fake IP address. Make sure you enable the XFF setting only if the on-premises proxy is configured to add this header and your firewall blocks direct access to outbound port 443 for users who attempt to bypass the proxy.
-
Proxy authorization. Requires that āSIAā Proxy authorize connections from the on-premises web proxy. You need to configure proxy credentials in āSIAā and configure these credentials in the on-premises proxy. For more information, see Configure proxy authorization.
The Proxy host information that you use to configure the on-premises proxy to send all traffic to āSIAā Proxy is available in a policy configuration.
Proxy chaining is an optional step in the workflow only if you plan to set up āETP Clientā. To set up a full web proxy, you need to either set up āETP Clientā for web traffic or implement proxy chaining.
-
-
Configure your policy for the full web proxy.
In addition to enabling āSIAā Proxy and the settings that are required for āETP Clientā or a proxy chaining configuration, you also select Full Proxy as the Operating Mode and as the mobile mode for iOS, Android, and Chrome OS device. The mobile mode settings are currently in beta.
For instructions on configuring the policy, see Enable full web proxy.
-
If you havenāt done so already, deploy the policy.
For your policy configuration to take effect, you need to deploy it to the āSIAā network.
For more information, see Deploy configuration changes.
Set up an identity provider
An IdP is a service that creates, manages, and saves user identity information. This identity information is used to authenticate users within a network. Identity information or attributes are stored in a directory. By setting up an IdP, you can enable user authentication. You can configure authentication to require that users or groups authenticate to access websites, web applications, sensitive data, or specific file types. With this configuration in place, you can also report usernames and groups in access control events. To learn more about IdPs, see About identity providers.
āSecure Internet Access Enterpriseā supports these IdPs:
- āAkamaiā
- Third-Party security assertion markup language (SAML)
- Okta
- PingOne

To set up an IdP:
-
Set up an identity connector.
An identity connector is a complete virtual appliance that you download in āSIAā and deploy behind the firewall in your data centers or hybrid cloud environments. Identity connectors allow āSIAā to synchronize with your organizationās AD or LDAP servers.
To download an identity connector, see Create and download an identity connector.
-
Add a directory.
A directory is a service that your enterprise uses to manage users and user groups. To authorize user access to domains or URLs in a policy, you add directories to āSIAā and associate them with IdPs.
āSIAā supports these directory services:
- Cloud Directory
- AD
- LDAP
- Active Directory Lightweight Directory Services (AD LDS)
- System for Cross-domain Identity Management (SCIM)
Cloud directory is a directory that's included with āSIAā to provide user access to the Internet without integrating LDAP. By default, all users you add to this directory are part of the main Users group.
As part of a directory configuration, you need to associate an identity connector.
For more information about directories, see About directories. To add a directory service, see Add a directory.
-
Add an IdP.
To add an IdP, see Add an identity provider.
The online help includes detailed procedures that guide you through the process of setting up these specific identity providers.
-
Enable authentication in a policy.
Enable authentication, assign an identity provider, and select the users or groups that can access websites in a specific category. For instructions, see Require authentication to access a website or web application.
-
If you havenāt done so already, deploy the policy.
For your policy configuration to take effect, you need to deploy it to the āSIAā network.
For more information, see Deploy configuration changes.
Updated 3 months ago