Important: Some of the technical information covered in this guideline is considered legacy, and is maintained primarily for historical reference. Please contact the Authentic8 Support team for the latest configuration details based on your organization's existing (Firewall) solution
Secure Web Gateway Integration (SWGI) provides enterprise customers with the functionality to redirect web browser requests over to the Silo for Safe Access environment, rather than through the local machine's default web browser
Technical Details
When a SWGI designated website is accessed via a hyperlink, or by manually entering a URL, the request is processed within the Silo for Safe Access environment
The URL forwarding process is completed by setting proxy service tokens for the designated sites
Prerequisites
- Silo Access Portal must be configured
- A good working knowledge of your Firewall or Web Proxy service, along with setting of tokens
User Experience
There are three basic SWGI user paths:
- A SWGI designated URL pass on a machine with the Silo Windows client installed can be launched directly into Silo for Safe Access — with prompt or no-prompt
- A SWGI designated URL can be launched directly into the Silo Web Client — with prompt or no-prompt
Configuration
The basic SWGI configuration steps are:
- Silo Portal Configuration
- Determine the designated sites to be rendered in Silo for Safe Access
- Request an SWGI token from Authentic8 Support
- Configure your proxy service with the SWGI tokens for the designated sites, based on your use-case
Silo Portal Configuration
The Silo Portal configuration step consists of setting the Silo Access Portal URL; this URL must be set with an active link for the SAML configuration to work
This is a custom URL value, which activates the Silo Access Portal for your organization
From the Silo Admin Console, click Manage right below Policies, then navigate to Access & Authentication > Silo Access Portal > Edit
Set the Silo Access Portal URL value and click Save
SWGI Token Settings
SWGI functionality is driven by using tokens to validate URL handling requests from the customer and forwarding all designated sites to be rendered in Silo.
The general syntax is: getsilo.com/launch/<vanity_url>/<token>/?url=destination URL
Required Settings
| # | Setting | Definition |
| 1 | <Portal ID> | The Silo Access Portal URL |
| 2 | <token> | The required token provided by Authentic8 Support to initiate SWGI |
| 3 | url=destination URL | The destination URL is the URL that is to rendered in Silo via SWGI. The destination URL must be encoded for SWGI to work |
Customization Settings
The SWGI page flow can be customized by using these customization settings.
| # | Setting | Action |
| 1 | require_click |
Notes
|
| 2 | skip_welcome |
More Info
|
Web Proxy Setting Examples
| # | Example with Description |
| 1 | An example containing the least number of required settings getsilo.com/launch/<vanity_url>/<token>/?url=destination URL Based on the default values for the missing customized setting arguments (i.e., require_click and skip_welcome) the Welcome page will be displayed, and the Launch Silo page will be displayed |
| 2 | A require_click example, with require_click=true getsilo.com/launch/<vanity_url>/<token>/?url=destination&require_click=true The Launch Silo page will be displayed with an explicit click being required on the first pass and every pass thereafter to launch the designated site in Silo |
| 3 | skip_welcome example, with skip_welcome=true getsilo.com/launch/<vanity_url>/<token>/?url=destination URL&skip_welcome=true The Welcome page will be skipped, based on the setting of skip_welcome to True |
| 4 | An example with skip_welcome set as true and require_click set as false getsilo.com/launch/<vanity_url>/<token>/?url=destination URL&skip_welcome=true&require_click=false Based on the customization settings, the Welcome page will be not be displayed, while the Launch Silo page will be displayed and automatically open the URL in Silo |
More Info:
The default settings (i.e., when the argument is not present) for require_click is True and for skip_welcome is False
SWGI Process Pages
SWGI functionality has a set of process pages, which primarily deal with ensuring that Silo for Safe Access is installed and that SWGI will function correctly
SWGI Page Definition
This table lists the SWGI pages, along with a general description and display frequency
| # | Page Name | Description | Display Frequency |
| 1 | Welcome | A welcome page providing options for users to learn about Silo, proceed with Silo Setup and the SWGI process | One-time, on a new user's initial pass |
| 2 | About Silo | A general information page on the Silo product | One-time, on a new user's initial pass |
| 3 | Silo Setup | A page for Silo setup, providing a download and install link | One-time, on a new user's initial pass |
| 4 | Silo Sign-in | A page displayed for PIN users only, requiring a sign-in to proceed with the SWGI process | One-time, on a new user's initial pass |
| 5 | Troubleshooting | A page providing troubleshooting options on setting-up and launching Silo | One-time, on a new user's initial pass |
| 6 | Download and Install | Provides Silo downloading and installation for SWGI users and is linked from the Troubleshooting page | One-time, on a new user's initial pass |
| 7 | Silo Support | Provides mail contact to Support, linked from the Troubleshooting page | One-time, on a new user's initial pass |
| 8 | Launch Silo | A page that provides a button for the launching of the designated URL in Silo | Displayed on every SWGI pass |
| 9 | Relaunch Silo | Follows the same functionality as the Launch Silo page | One-time, on a new user's initial pass |
| 10 | Silo | The designated site is rendered in Silo | Displayed on every SWGI pass |
SWGI Page Flow
The following diagram details the SWGI page flow for both SAML SSO and PIN authentication
SWGI Page Definition
Please see SWGI Process Pages for complete display, content and navigation information, for all SWGI pages
Best Practices
This section provides a set of additional requirements and best practices that need to be reviewed, since some tasks are required to make the SWGI process work
The additional requirements and best practices are divided into three areas:
HTTP/HTTPS Whitelisting
User Interface (UI) Limitations
Forwarded Traffic Limitations
HTTP/HTTPS AllowList
This table lists the URLs to be whitelisted, along with the reason for AllowListing, and whether AllowListing the URL is required or optional for SWGI to perform properly. The URLs that are listed as required must be provisioned in the AllowList, or the SWGI process may not run successfully
# | URL | Reason for Whitelisting | Required/Optional |
1 | authentic8.com | Domain | Required |
2 | getsilo.com | Domain | Required |
3 | yui-s.yahooapis.com | Not whitelisting this URL will break the SWGI process | Required |
4 | s.yimg.com | Not whitelisting this URL will break the SWGI process | Required |
5 | d3ebp2875iucq9.cloudfront.net | Not whitelisting this URL will break the SWGI process, by causing icon issues | Required |
6 | d1fyc34zgepog4.cloudfront.net | Not whitelisting this URL will break the SWGI process, by causing client downloading issues | Required |
7 | fonts.googleapis.com | Not whitelisting will not break the SWGI process, but it may generate display issues | Optional |
8 | fonts.gstatic.com | Not whitelisting will not break the SWGI process, but it may generate display issues | Optional |
9 | ssl.google-analytics.com | Not whitelisting will not break the SWGI process or generate display issues, but it may impact Google analytic reporting | Optional |
10 | www.google-analytics.com | Not whitelisting will not break the SWGI process or generate display issues, but it may impact Google analytic reporting | Optional |
Additionally, proxy rules for the HTTP/HTTPS set should be restricted to HTTP/HTTPS protocols. Narrowing the rules to these protocols varies by proxy vendor and it's advised to review the proxy vendor's documentation
User Interface (UI) Limits
Beyond the underlying limitations, the UI also enforces various limits around URL length. For instance, the browser address bar is capped at 2047 characters. Start> Run is limited to 259 characters (the MAX_PATH limit is 260,which leaves one character for the null-terminator). Internet Explorer versions up to version 11 do not allow you to bookmark URLs longer than 260 characters. The Windows RichEdit v2 control’s Automatic Hyperlink behavior (EM_AUTOURLDETECT) truncates the link after around 512 characters; this limit is higher in RichEdit5Wcontrols
Forwarded Traffic Limitations
For the best SWGI performance, forwarded traffic should be limited to HTTP/HTTPS traffic only
Additional Resources
Please contact Support for any additional questions