System for Cross-Domain Identity Management (SCIM) is a standard protocol/API that allows users and groups to be automatically provisioned from identity provider that support SCIM, to your Atlassian application. SCIM is supported by most major identity providers, including but not limited to Azure AD, Okta, OneLogin etc. Kantega SSO primarily supports SCIM version 2. The older SCIM v1.1 legacy protocol is only supported and tested for use with Okta's on-prem provisioning agent.
In brief, SCIM works by having the identity provider send provisioning instructions to registered applications whenever changes occur. As such it can be a far more efficient way to synchronize users than connectors as only actual changes need to be transimtted, rather than full snapshots of directory state.
Network Overview
SCIM provisioning requires an inbound connection to your Atlassian servers. In many cases, however, the company’s Atlassian servers will sit behind a corporate firewall. This makes load balancer or reverse proxy configuration a necessity to use SCIM, unless your IDP provides a solution like Okta’s provisioning agent: https://support.okta.com/help/s/article/29448976-Configuring-On-Premises-Provisioning.
The figure illustrates what a typical Jira Datacenter environment 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 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.
API server
Kantega SSO's SCIM endpoints are hosted through a bundled internal API server by default. This is part of the addon and not something you'll need to install or start separately. This allows SCIM endpoints to be served using a port and thread-pool separate from the rest of the Atlassian application. This makes it easier to separate the two types of traffic, and helps ensure the external proxy isn't used to access the core application.
As the API server is intended to always sit behind a gateway, it does not itself provide HTTPS transport. This makes a reverse proxy or gateway a requirement even for single-node envs where you don't need load balancing.
Additional security/hardening
SCIM endpoints need to be available from the Internet, and access to them are protected by the use of HTTPS transport and a secret bearer token. Changing the bearer token regularly is recommended.
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.
If the Bearer token is stolen, and an attacker obtains physical access to the SCIM endpoints, it is potentially possible to provision fake users and set roles as they see fit.
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.