Jama Connect® SCIM configuration with Okta and Microsoft Entra

Published Date: August 6, 2024
Validated: Yes
Audience: Everyone

Products and Versions Covered:

• Jama Connect® (supported SCIM-enabled versions)
• Cloud / CVC
• Self-hosted
• Microsoft Entra (formerly Azure AD)
• Okta Custom Application

IMPORTANT: Access to the REST API is limited to users with a Named Creator Jama Connect license, including access to v1, labs, and SCIM endpoints. Users without a Named Creator Jama Connect license, including those with a Creator Float License, do not have access.

ADFS does not natively support user provisioning. SCIM, in general, is designed to make it easier to manage user accounts across different SaaS applications, whereas ADFS doesn't do so, as it focuses on enabling SSO authentication beyond an organization's network/security zone.

Summary

synchronization of users and organization-level groups between your identity provider (IdP) and Jama Connect®.

This article explains configuration for:

• Microsoft Entra
• Okta Custom Applications

SCIM enables organizations to:

• Automatically provision users into Jama Connect
• Synchronize organization-level groups from the IdP
• Automate user activation, deactivation, and profile updates

Before enabling SCIM, review:

• Username and email alignment requirements
• Organization-level group structure and naming
• Authentication compatibility (Basic, SAML/Auth0, Multi-mode)
• Third-party integrations impacted by username changes

Resolution

Currently, Jama Connect supports SCIM provisioning with the following IdPs: 

• Okta Custom Application 
• Microsoft Entra

Considerations and Pre-Requisites for SCIM

Before enabling SCIM, review the following impact areas to ensure compatibility with your environment:

• SCIM field mappings and data impact
• Authentication method configuration
• Username and email formatting requirements
• Third-party integrations (if username is in use)
• Organization-level group naming and membership rules

⚠️ Depending on your current configuration, data sanitization may be required before enabling SCIM.

Existing Customers – Authentication Requirements

Username and Email Alignment

Review all users to ensure:

• Username matches Email Address
• IdP subject matches Jama Connect email field

For SAML/Auth0 integrations:

• The IdP subject (Okta userName or Entra userPrincipalName) must equal the user’s email in Jama Connect

Microsoft Entra Email Requirement

• Entra does not require an email by default
• Jama Connect requires an email for all provisioned users
• Email must match userPrincipalName

Data State Requirements

Data Sanitization

• Cloud customers: Contact Support
• Self-hosted customers: Available in version 9.6.2+ (Microsoft Gallery SSO for Jama Connect®)

Authentication Type Impact

Existing Customers – Third-Party Integrations

If external applications rely on username-based authentication:

• Evaluate all integrations before enabling SCIM
• If username changes impact integrations, coordinate updates in parallel

Existing Customers – Organization-Level Groups

Before enabling SCIM:

• Review org-level groups and memberships
• Identify groups to sync with IdP
• Remove or rename duplicate group names

Important Behavior

• Inactive Basic Auth users in synced groups will be removed during SCIM sync
• Project-level groups are NOT affected by SCIM

How SCIM Works in Jama Connect

Changes Introduced by SCIM

• Users and groups assigned in IdP are provisioned into Jama Connect
• Users receive licenses automatically (Creator → Creator Float based on availability)
• User updates in IdP overwrite Jama Connect attributes
• Org-level groups are managed in IdP when group provisioning is enabled

Authentication Behavior

• Users not present in IdP remain unchanged (Basic Auth only)
• With Multi-mode, Basic Auth users remain managed in Jama Connect
• IdP-managed users must exist in the IdP for synchronization

Actions That Remain Unchanged

• License assignment by org admins
• Avatar uploads by users
• Project-level group management
• User and group permissions in Jama Connect

SCIM Action Mapping

Configure SCIM Provisioning

• Cloud customers – Contact Support to schedule enablement. 
• Self-hosted customers - Please contact Support for help preparing for a successful implementation. 

Jama Connect Configuration 

Okta (Multi-Mode Requirements)

• Disable “Allow users to change username.”
• Enable “Disable auto-generation of new SAML users.”

SCIM Admin Setup

• Create a dedicated service account with Basic Auth and Org Admin privileges
• Ensure data sanitization is completed

Logging (Optional)

Enable TRACE logging:

• com.jamasoftware.contour.rest.versions.scimv2
• com.jamasoftware.contour.security.saml.SamlUserDetailsAuthenticationProvider
• com.jamasoftware.contour.rest.services.ApiKeyTokenService (Azure AD only)

Microsoft Entra Configuration (SCIM Token Required)

A bearer token (secret token or long-lived bearer token) is required to authenticate Microsoft Azure AD's provisioning for non-gallery apps. 

Token Requirements

• OAuth2-based bearer token required
• Token expires in 6 months

Token Behavior Notes

• First call generates token
• Subsequent calls require a revoke parameter or return 409
• Key pair files are overwritten on regeneration

Token Endpoints

API credentials

• POST /rest/token/apiKeygen – Generate key pair
• GET /rest/token – Retrieve token
• GET /rest/token?revokeExistingToken=true – Rotate token
• DELETE /rest/token/current – Revoke token
• DELETE /rest/token/current?forUser=<userId> – Revoke user token

Token Expiration Warning

When the Entra bearer token expires:

• Provisioning fails
• Azure AD may quarantine the application

Recommendation:

• Set up internal monitoring to rotate the token before expiration

Okta Configuration

1. Enable SAML/Auth0 in Okta 
2. Pre-requisite / Data preparation: 
   • Okta App username = Connect username = Connect email 

Provisioning Users in Okta

1. With your Jama Connect Okta Application selected:

• Go to General > Edit
• Provisioning > select SCIM
• Save your changes

2. Select the Provisioning tab:

• Under Integration > SCIM Connection > select Edit.
• Please fill out the required form (once this is saved, it will allow access to the To App and Okta settings)
  • SCIM connector base URL: Jama Connect application URL + SCIM path (e.g. https://example.jama.net/rest/scimv2)
  • Unique identifier field for users: userName
  • Supported provisioning actions: Push New Users; Push Profile Updates
  • Authentication mode: Basic Auth (note: other authentication methods cannot be used at this time)
  • Username: SCIM Admin username that you created in previous steps
  • Password: SCIM Admin password that you created in previous steps
  • Select the Test Connector Configuration button to ensure everything is configured correctly.
  • Save your changes

3. Select the Sign On tab:

• Go to Settings > Edit
• Under Credential Details, set the following:
  • Application username format: Email
  • Update application username on Create and update
• Save your changes

4. Return to the Provisioning tab:

• Select To App > Edit and set the following:
  • Create Users: enabled
  • Update User Attributes: enabled
  • Deactivate Users: enabled
• Save your changes

5. Now, you can assign new Okta users to your Jama Connect Okta Application!

• Please confirm that the email address format in the Application User username and email fields matches that in the email address field during the assignment process. (You may need to copy/paste the primary email value into the username field.)

6. Existing users assigned to the application will see a warning icon indicating they must be provisioned with the external application (Jama Connect).

• To provision existing users, select the Provision User button, which is available only after step 5 is completed.

Provisioning Groups in Okta

1. Follow the steps above in the 'Provisioning Users in Okta' section through step 2 with the following modification:

• Supported provisioning actions: Push New Users, Push Profile Updates, Push Groups
• Please complete the remaining steps in the 'Provisioning Users in Okta' section if necessary.

2. If you have not created the Okta Groups that you want to provision into Connect as new groups (or to link to existing Connect org-level groups), then create them now

3. With your Jama Connect Okta Application selected:

• You can go to the Push Groups tab.
• Select the Push Groups button > select the By Name section.
• Search for your Okta Group and select the appropriate Group from the suggestion dropdown.
• Under the Match result & push action > select Create Group or Link Group.
  • Create Group will provision the Okta group into Connect.
    • A new org-level Group will be created if no name match is found in Connect.
    • If a group with an exact name match is found in Connect, the Okta group will be linked to the corresponding Connect group, and the users in the Connect group will remain in the Group after the link is created.
    • Users within the Okta group will not be provisioned into Connect (this must be done via Assignment)
  • Link Group will also provide the Okta group with Connect.
    • The Link Group text field dropdown in Okta should remain empty since we do not support importing groups.
    • Suppose a group with an exact name match is found in Connect. In that case, the Okta group will be linked to the corresponding Connect Group, and users within the Connect Group will remain in the Group after the link is created.
    • Users within the Okta group will not be provisioned into Connect (this must be done via Assignment)
• Save your changes

Microsoft Azure AD Configuration

1. In the Azure portal, go to Azure Active Directory > Enterprise Applications

• Select the application that exists for Connect (the same one used to configure SSO for user login)
• Select Provisioning
• Select Get Started, then set Provisioning Mode to Automatic
  • Tenant URL: Jama Connect application URL + SCIM path (e.g. https://example.jama.net/rest/scimv2)
  • Secret Token (aka Bearer Token): Paste in the Bearer Token generated from Connect as described in the above steps
• Click Test Connection
  • If successful, a brief status box will display in the window's top-right for a few seconds.
• Click Save, but do not start provisioning.
  • You must leave Provisioning turned off since the default mappings in Azure AD include unsupported attributes. 
  • The following section will correct the mapping settings.

Configure Actions/Mappings for Users

1. If you had dismissed the screen after the section above, go back to the Enterprise Application > select Provisioning> select Edit Provisioning

2. Expand the Mappings section > select Provision Azure Active Directory Users

3. Change the default Target Object Actions to turn off Delete (see screenshot below)

• Connect supports 'soft delete' (inactive users) but does not handle 'hard delete.'

4. Change the default Attribute Mappings to remove unsupported attributes

• Delete every attribute except the following (under the column customappsso Attribute):
  • userName
  • active
  • emails[type eq "work"].value
  • name.givenName
  • name.familyName

5. Save your changes

Configure Actions/Mappings for Groups

This feature is optional. If you do not want to synchronize Groups and Group Membership from Azure AD to Connect, edit the group mapping and set Enabled to No.

• Even if you turn off mappings for Groups, you can still assign Azure AD users to the Connect application by assigning the Azure AD Group, which contains the users. In this scenario, users will be provided with Connect but will not create a Group in Connect.

1. Go to Provision Azure Active Directory Groups

• The default Target Object Actions are supported. You do not need to adjust any settings in this section.
• The default Attribute Mappings are supported. You do not need to adjust any settings in this section.

Enable Automatic Provisioning in Azure AD

When you are ready, enable Provisioning by selecting Start Provisioning.

• Azure AD provisioning runs a batch job in the background. It can take several minutes for a new provision cycle to start (e.g., 40 minutes).

Viewing Logs from Azure AD Provisioning

You can view provisioning logs by selecting View provisioning logs.

Additional Resources 

• Success Programs
• Success Catalog
• Datasheets
• Request a Solution Offering or Training from the Success Catalog

Feedback:
We welcome your input! Please sign in to leave any comments, suggestions, or ideas for improvement below.