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 an intermediate reverse proxy, gateway, or load balancer at the perimeter or in the 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 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
...