User Sync Configuration

Go to your Atlassian product and navigate to the User & Group Sync settings. Click Create Connector and choose SCIM 2.0.

You can change or add a Name for your SCIM 2.0 Connector. You can copy your SCIM Base URL and the Bearer Token. We will need both later for the configuration of the IdP SCIM application.

Don't forget to save "Save and Return" your settings!

We will have a look at the 'Provisioning' and 'Sync' settings later. However, first we create an Application (SCIM client) in your Oracle Cloud.

Oracle Identity Cloud Service Configuration

Login into your Oracle Identity Cloud Service and add a new Application (click Applications).

Next, hoover over +Add and click App Catalog.

Then, start a search with the string 'generic' and add 'GenericScim - Bearer Token' as new Application.

Please provide a Name and add a Description if needed. Click Next to continue.

Enable Provisioning to create or delete accounts.

Now, we need to add the following:

• Host Name: your Atlassian Server base-URL (without https://)
• Base URI: SCIM Base URL (without https://)
  • User Sync SCIM 2.0 Connector specific Settings page
• Access Token: Bearer token 
  • User Sync SCIM 2.0 Connector specific Settings page

Please do a test via 'Test Connectivity'.

After a successful test you can configure the Attribute Mapping (Configure Attribute Mapping → Attribute Mapping). You can map Identity Cloud Service attributes to attributes in your Application Account. In most cases the default mapping is fine as is and should not be changed.

Please enable Synchronization this allows you to control how operations like creating and deleting accounts in Software as a Service (SaaS) applications are reflected in Oracle Identity Cloud Service. 

Custom applications are non Oracle Public Cloud (OPC) services. You can modify custom applications by assigning users to them. To assign a User or a Group to your SCIM application, please go to Users and/or Groups and assign the necessary users/groups.

Don't forget to Activate the application, once it gets created.

Back to our SCIM 2.0 User Sync Connector. Let's have a look at the Provisioning Settings tab first.

You can configure three main sections in the provisioning settings.

Copy Behaviour

Copy behaviour is useful if you add User Sync to an existing Atlassian application like Jira or Confluence and want to migrate existing data. It allows you to find the user record with the same username in a different Atlassian application directory and copy the contents to the User Sync directory (i.e. Group memberships, last login time, user properties, etc.).

Attribute Mapping

Within the Attribute Mapping, you can map data coming from SCIM 2.0’s API to fields within the Atlassian Application. You can also apply a lot of advanced functions to transform, change or filter the data from SCIM 2.0 before applying it to the Atlassian Application.

Group management

Group management can be one of the trickiest elements to understand in User Sync. Atlassian does not have the concept of groups from different sources, i.e., from SCIM 2.0 or groups created locally.
In its default configuration, User Sync treats SCIM 2.0 as the single-source of truth for group memberships of users synchronized from SCIM 2.0. If a synchronized user is a member of a group in your Atlassian application (i.e. locally assigned) but not in SCIM 2.0, the next sync does remove that membership. With the settings below, you can adjust this behaviour to your use case.

Common configurations are:

• Automatically assign groups to every synchronized User
• Do not use groups from SCIM 2.0 and treat every given group as local
• Limit the groups assigned & imported from SCIM 2.0 to specific patterns
• Allow mixed-use, where you define some groups as locally managed and others to be assigned & managed from SCIM 2.0.

IdP group management

Here, you configure in detail how the plugin deals with groups loaded from the Identity Provider. The two settings are:

• Only Assign these Groups
  If you add group names here, the plugin will only assign these from the IdP and drop all others that the IdP sends for a particular User. Essentially, this is a IdP group whitelist.
  You can also use regular expressions (e.g: to match multiple group names at once, like jira-.* for everything that starts with jira-)

• Never assign these Groups
  If you add group names here, the plugin will never assign the groups from the IdP, but assign all others that the IdP sends for a particular User. Essentially, this is a IdP group blacklist.
  You can also use regular expressions (e.g: to match multiple group names at once, like jira-.* for everything that starts with jira-)

Usually you only use one of the options and not necessarily both at the same time.

Local group management

Here, you control how the plugin adds/ removes groups that you may have assigned locally to the user.

• Always assign Users to certain Groups
  This allows you to add every user to the groups listed in this field. For example, it can be handy to add every user to an application access-group like jira-users. This is re-applied during every sync, so if you manually remove a user from one of these groups, he will be re-added during the next sync.
  
  More flexible use-cases can be achieved with the attribute mapping's transformation features.

• Never remove users from these Groups
  You control which groups are not automatically removed by User Sync from users. By default, if we detect that a synchronized user is a member of a group in Jira, but that membership is not reported by SCIM 2.0, we would remove the User from that group. That is great for group memberships you want to be managed on SCIM 2.0. It's not suitable for those you would like to assign manually from within Jira via the UI.
  
  You need to list all groups that User Sync should not remove in this setting. This can either be by listing the Group names as they appear in Jira or by using regular expressions.

Note

Applying .* in "Never Remove Users From These Groups" and .* in "Never Sync These SCIM 2.0 Groups" will only synchronize User Data from SCIM 2.0 but no group memberships. Essentially something like a "remote directory with local groups" that you know from Atlassian LDAP connections.

See https://wiki.resolution.de/doc/usersync/latest/knowledge-base/group-management-and-filtering-with-user-sync for more information.

Sync Settings

The Sync Settings give you the possibility to configure the Cleanup Behavior. What happens to users that have been synchronized into Confluence once...

• they get deleted in SCIM 2.0
• they are not member of any required groups anymore
• they are dropped by a transformation in the attribute mapping

The default behaviour is to disable these users, as Atlassian recommends.

Other Settings

Here you will find some User Sync SCIM Connector related information.

Connector ID > Unique ID, which can be used for REST API calls (as an example).

Directory ID > The field contains the directory ID, which the SCIM Connector use. This can also be used for REST API calls.

Logging > If you enable the option 'Log free memory during sync' the memory consumption / utilization is displayed during the sync (see example sync status).