Guides:

Configuring SCIM involves some network and infrastructure preparation but is otherwise fairly simplereasonably straight forward. In many cases you may already have the required infrastructure in place:

...

network requirements down. A brief summary of the process is as follows:

1. Create a SCIM directory and tenant configuration in Kantega SSO. This gives you

   a bearer token and

   a unique tenant URL

   , e.g. http://jira-internal.example.local:5501/scim/zbs848185728/v2. The IDP will use this URL to send users and groups to the Atlassian app.

2. Network: Set up a load balancer, gateway or reverse proxy to make the internal endpoint accessible from the Internet, and provide HTTPS termination.

   1. HTTPS is an absolute requirement externally. Use an existing host name and certificate package, or register new ones. Certificate requirements are IDP-dependent, and self-signed certs are generally not accepted.

3. Configure the gateway to proxy requests to the internal tenant URL (see above). You should now have an external tenant URL e.g. https://scim.example.com/scim/zbs848185728/v2 which gets proxied to e.g. http://jira.example.local:5501/scim/zbs848185728/v2.

4. Configure SCIM in the IDP:

   • Set the external tenant URL as the SCIM endpoint address.

   • Add the bearer token from #1

   • Do any additional configuration (user assignment, attribute mapping)

...

1. and application secret, which the identity provider (SCIM client) will use to provision users and groups.

2. Configure a Network gateway/proxy to make the tenant URL accessible to the IDP with HTTPS.

   1. This includes obtaining a valid DNS name and certificates.

3. Add/Configure a SCIM application on the IDP.

Proceed to the IDP guides or see the in-app instructions for specific instructions and screenshots for each identity provider.

Troubleshooting

As a general guide line, the main place to look for SCIM status and logs is on the client side, i.e. the identity provider. This is different for each IDP and some have better SCIM features than others, but most have some form of audit or event logs. Some also allow you to see provisioning status per application and assigned user.

On the server side, Kantega SSO allows you to browse the SCIM directory to see the users and groups that have been provisioned:

...

For deeper troubleshooting, there’s also the SCIM event log which shows the last handful of SCIM requests from the identity provider. We will usually ask you for details from this event log when troubleshooting provisioning errors:

...

The identity provider gives me a connection error

This is most likely a problem with your proxy setup. Find your SCIM URL in the Status menu and try invoking the backend directly using a tool like curl or Postman:

$ curl https://backend.example.local/scim/joc9aqnbjyhb/v2/Users
{"schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"status":"401","detail":"Not authorized for this operation"}

If you get a JSON response/authentication error like the above (as we did not include a bearer token) then the endpoint is accessible and the problem is with the gateway or proxy.

If on the other hand you have a network error at this stage already, check the firewall config on the Atlassian application server.

Provisioning fails for some users

A common cause of user provisioning faults is that the user contains invalid data, or is missing some attributes. To create a user account in Atlassian, the following attributes are required:

• Name

• E-mail

• unique username

The SCIM response will from KSSO would contain the reason. show you the error code returned by Kantega SSO

I configured provisioning and the IDP says the endpoint is OK, but no users or groups are being created in my Atlassian application

Check the KSSO event log. Can you see any requests?

Check that you have assigned users and groups to the application in the IDP.

The IDP is getting a 500 error from KSSO

You may have run into a bug. Check the Atlassian application log for any exceptions and stack traces.