To ensure a trouble-free OnBoard experience, organizations need to be certain that requests to OnBoard and its affiliated service providers are allowed past their firewalls.
OnBoard has been architected to follow well-established best practices and operates primarily on established ports common to all web traffic: ports 80 and 443. These ports are well known to network administrators as the ports for clear text (unencrypted) web traffic (port 80) and for secure traffic (port 443). This clear text/encrypted separation is in use by the vast majority of sites on the web, and should be no surprise to any system or network administrator. With these ports in mind, it is important to note that only the initial request to OnBoard is handled in plain text on port 80, and that this request will be redirected to the secure port 443 for all subsequent requests and responses. At no time is customer information transferred in an unencrypted state.
The next thing to consider when assessing OnBoard’s interaction with your organization’s firewall are the specific domains that will need to be allowed to pass traffic to your local machines. In all cases, the domains listed below will need to be allowed through the firewall.
These sites are:
Public URL for OnBoard.
Our authentication server.
This is our API gateway for CC so we can spin up services without individual domains for them.
Messaging feature in OnBoard.
Public posting from OnBoard.
User and Organization Image storage.
Used for in-app tutorials
Consider adding wildcard to cover any future services we certify
In addition to the domains above, to utilize a third-party authentication provider at least one of the approved OAuth 2.0 providers (Microsoft, Yahoo, and Google) must be allowed to traverse the firewall in order for users to be able to login. These sites are:
All of these domains are the official endpoint for their respective OAuth services. These are the most conservative URIs that can be allowed. This means that allowing https://www.google.com/accounts/o8 is necessary to keep users from accessing https://www.google.com. While adding the shorter URI https://www.google.com to the allowed sites list will work for OnBoard, it will allow all traffic that matches this shorter, less distinct pattern to flow through the firewall, potentially circumventing an organization’s network security policies. The longer, more distinct URI will insure only the OAuth endpoint traffic will pass through the firewall.
If you or your network administrator have trouble accessing OnBoard, please feel free to contact Passageways Technical Support by submitting a ticket request and or emailing firstname.lastname@example.org, which will open a ticket automatically.