SCIM provisioning requires an inbound connection to your Atlassian servers. In many cases, the company’s Atlassian servers will sit behind a corporate firewall, requiring a an intermediate reverse proxy, gateway, or load balancer in at the perimeter or in most casesthe DMZ.
The figure illustrates what a typical Jira Datacenter deployment would look like with SCIM:
...
An external load balancer routes inbound SCIM requests to Kantega SSO API servers on port 5501 on each Atlassian/Jira node.
You may use which ever whichever proxy, gateway or load balancing solution that suits your needs. Most likely, your organization already has a preference.
An internal load balancer is responsible for routing regular Web (user) traffic to each Jira node on port 8080. In the figure, this is only available internally.
Note, the load balancers don’t strictly need to be separate. It’s up to you.
...
For production environments, we recommend the API server as a proxy/gateway will be needed in most cases anyway, but it’s up to you. The added advantage of the API server is the stronger separation of SCIM and regular application access and traffic. For example, you will be less likely to accidentally expose all of Confluence to the Internet when only intended to proxy SCIM endpoints.
...
If possible, restricting access by IP in the company firewall or gateway is also recommended. By only forwarding request that originate from a whitelisted IP-range, you will have an extra layer of safety on top of the bearer token. Some IDPs publish their IP ranges either in the form of regular documentation or as JSON files that can be consumed and converted to firewall rules/scripts. As an example, Azure AD ranges can be downloaded here: https://www.microsoft.com/en-us/download/details.aspx?id=56519
Data Center vs Server
While Atlassian Datacenter is not required to use SCIM, we do recommend it for the added redundancy it provides. In a single server environment, provisioning can occur simply because the only server is taken down for temporary maintenance or a reboot, as that makes SCIM endpoints temporarily inaccessible. Depending on the IDP, this could simply mean a newly added user or group doesn't get provisioned for another hour (when the IDP automatically retries), or it could mean a manual refresh/force sync is needed for that user. Some IDPs, Azure among them, will disable SCIM provisioning and send the admin an e-mail if enough SCIM operations fail within a certain time frame.