This page documents web resources which should be accessible for Raven sign in to work. It should be of utility to those looking to determine the "minimal connectivity" required to complete a Raven sign in.
This page is no longer valid
In February 2023, Raven started to use Microsoft Azure Active Directory as a backend to authenticate users. Microsoft provides the following guidance on URLS and IP address ranges, but these could change at any moment with only 30 days notice, see Office 365 URLs and IP address ranges
This page is for guidance only
This page is provided as a courtesy to those implementing Raven sign in for network configuration. It should not be taken as describing a stable interface. The details on this page are subject to change. Where possible the Raven Admins will endeavour to give advantage notice of changes but this will be on a "best-effort" basis.
It is preferred if network filtering can be performed at the level of request URLs. In order to allow Raven sign ins, your network must allow requests with the following base URLs:
Why the Google URLs?
We are transitioning to using Google's multi-factor authentication (MFA) solution for Raven. As more Raven flavours transition, it will become more and more difficult to support Raven users with MFA enabled without allowing the Google URLs.
You may want to allow HTTP to HTTPS redirect for these URLs although correctly configured applications should never use a HTTP URL to request resources from Raven.
We do not recommend IP-based filtering unless the firewall can dynamically fetch IPs based on the hostnames listed above.
In order to support Raven sign-in traffic must be allowed to the following IPs:
In addition traffic must be allowed to IPs corresponding to the Google hosts above. Google may change which IPs these hosts resolve to with no notice. If you want to whitelist all Google IPs, Google publishes their IP ranges but in a somewhat round-about way; they publish a list of all of their IP ranges and IP ranges which may be used by their Cloud customers. They tell you that the IP ranges for their services can be computed by subtracting one from another which is non-trivial to do in your head(!)
The following Python 3 script can be run to save you the trouble. It uses only the standard library and so can be run via an online Python script runner.
#!/usr/bin/env python3 import ipaddress import json from urllib.request import urlopen # All of Google's announced IP networks. with urlopen('https://www.gstatic.com/ipranges/goog.json') as response: all_networks = [ ipaddress.ip_network( prefix_obj.get('ipv4Prefix', prefix_obj.get('ipv6Prefix')) ) for prefix_obj in json.load(response)['prefixes'] ] # Those which can be used by third parties. with urlopen('https://www.gstatic.com/ipranges/cloud.json') as response: customer_networks = [ ipaddress.ip_network( prefix_obj.get('ipv4Prefix', prefix_obj.get('ipv6Prefix')) ) for prefix_obj in json.load(response)['prefixes'] ] # Compute "all" - "customer" networks. remainder_networks = all_networks for n1 in customer_networks: new_remainder_networks =  for n2 in remainder_networks: if n1.version == n2.version and n1.overlaps(n2): new_remainder_networks.extend(n2.address_exclude(n1)) else: new_remainder_networks.append(n2) remainder_networks = new_remainder_networks # Show remaining networks. for network in remainder_networks: print(network)
This is very much a case of "sledgehammer to crack a nut". By allowing all of the IP ranges reported by this script you are in essence allowing use of any of Google's applications. At that point you may want to consider if this firewall configuration is providing any meaningful restriction.