- 17 Nov 2023
- 3 Minutes to read
Allow/Block Network Traffic
- Updated on 17 Nov 2023
- 3 Minutes to read
Allowing and Blocking Traffic To/From RapidIdentity Cloud
This document describes how to explictly allow (and, therefore, block) network traffic to and from the RapidIdentity Cloud service.
Traffic Originating From the Customer's Site
Most customer traffic originates at the customer's site (like their school campus) and connects to RapidIdentity Cloud servers. These servers are configured in a highly-available (HA) configuration, so they may be accessed by multiple IP addresses. Additionally, due to behaviors imposed by our Cloud Service Provider (CSP) the IP addresses may change during our planned maintenance windows, or at the discretion of our CSP. For this reason, administrators can add resolved IP addresses to their allow-list, but they should understand that there may be additional upkeep of those IP lists as our CSP changes them in the future.
For most customers, there is no need to configure any rules to allow this traffic to occur, since most customer environments allow all outbound traffic on HTTP ports 80 and 443. However, this additional detail may be useful for some customers so we are including it on this page.
Examples of traffic Originating from the Customer site:
- Students, parents, teachers, and adminsitrators accessing the RapidIdentity Cloud portal via web browser from the school campus or from home
- Identity Bridges configured to shuttle data between RapidIdentity Cloud and on-prem servers
Moreover, in RapidIdentity Cloud, different services run on different ports. Services running on RapidIdentity Cloud:
- HTTP Port 443
- Serves thet RapidIdentity portal used by students, parents, teachers, and admins
- HTTP Port 80
- Redirects unencrypted portal traffic to https/443 (this is just a convenience for users who don't explicitly add https:// to the URL)
- Serves the Identity Bridge server service by listening for encrypted webservices protocol connections; all traffic is encrypted inside the http/80 protocol using an ssh-like protocol encapsulated inside the http traffic
- For more information on how Identity Bridge works, watch the Identity Bridge webinar.
Some endpoints in RapidIdentity Cloud can be built dynamically. (For example, each Identity Bridge has its own hostname.) For this reason, explictly allowing traffic to RapidIdentity Cloud should include these domain names. All child (and grandchild, etc.) subdomains should be allowed.
All customers should allow traffic to:
Additionally, depending on where the customer's tenants are homed, these domains should be allowed:
Lastly, some customers have vanity domains, which include dedicated endpoint IP addresses used only by that customer. Obviously, this domain should be included, too.
To summarize, let's say that a customer whose tenant is on the us001 cluster has a vanity domain called portal.sampledistrict.edu. Their firewall should be configured to allow traffic to:
- all subdomains of rapididentity.com on ports 80, 443
- all subdomains of us001-rapididentity.com on ports 80, 443
- portal.sampledistrict.edu on ports 80, 443
Traffic Originating From RapidIdentity Cloud
For most customers, there is no need to configure any rules to allow this traffic to occur, since on-prem traffic is tunneled over one or more encrypted Identity Bridges, and those tunnels originate from the customer site. However, the additional detail in this section may be useful for some customers so we are including it on this page.
Examples of this traffic:
- RapidIdentity Connect jobs that connect to other Internet SaaS application APIs over the Internet to pull data
- RapidIdentity Connect jobs that push data to an SFTP server for later synchronization
Traffic originating from the Cloud cluster will come from one of the following Elastic IP addresses associated with the NAT Gateways. These IPs may need to be explicitly allowed.
Again, this section does not apply to Identity Bridges, since they originate from the customer site. RapidIdentity Connect jobs will connect to on-prem resources over these tunnels which have already been established.