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:

Open

• An external load balancer routes inbound SCIM requests to Kantega SSO API servers on port 5501 on each Atlassian/Jira node.

  • You may use 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.

SCIM endpoints

Kantega SSO can serve SCIM endpoints in two ways:

• On the base URL: SCIM endpoints are accessible through the standard URL and port, and these can be used to configure the identity provider directly. Provided the Atlassian application is available to the IDP (i.e. available on the Internet) of course.

• API server: SCIM endpoints are only available through the internal API server, on a separate port and thread pool. It is intended for use with a reverse proxy or gateway and so does not provide HTTPS itself.

Note: The API server is part of the addon and not a separate process that needs to be installed or started separately.

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.  

Additional security/hardening

With SCIM endpoints generally needing to be available over the Internet, access is protected by the use of HTTPS transport and a bearer token. Changing the bearer token regularly is recommended but not enforced in any way.

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.