Versions Compared

Old Version 4

changes.mady.by.user Audun Røe

Saved on

compared with

New Version 5

changes.mady.by.user Audun Røe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 , requiring a 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, gateway or load balancer in at the perimeter in most cases. 

The figure illustrates what a typical Jira Datacenter environment 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 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 's 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 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 need generally needing to be available from over the Internet, and access to them are is protected by the use of HTTPS transport and a secret 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. 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.