try at Atlassian Marketplace
Managing JSM Portal Customers with User Sync: A How-To Guide

Managing JSM Portal Customers with User Sync: A How-To Guide

Managing JSM Portal Customers with User Sync: A How-To Guide

Table of Contents

Introduction

If you’re using our SAML SSO app for Jira and you are provisioning your users with the User Sync module, you may find yourself in a situation where you need to provide access to JSM portal customers who are not part of the required groups of UserSync. This can be challenging, but with the right settings applied to your UserSync connector, it is possible. In this article, we will explain how you can achieve this.

Starting Point and Prerequisites

Let’s say that you find yourself in the following situation:

Access Configuration: Syncing a subset of users and assigning the default access group

You have defined access to Atlassian applications as follows:

  1. You are using Required Groups to limit the sync to only a subset of users from the identity provider.
  2. You are also assigning the jira-software-users group to everyone who is synced by default.

Access to the JSM Portal: Customers should also trigger SSO

At the same time, you would like to enable SSO redirection for customers who are accessing JSM portals. However, you find two obstacles:

  1. First, they are not part of the groups that you have defined for syncing your regular Atlassian users from the IdP;
  2. Second, you obviously don’t want to assign thejira-software-users group to them by default when they log in, as they would start consuming licenses and may gain access to your Jira.

The first obstacle relates to how User Sync decides which users should be provisioned; the second has to do with what happens by default when a user is provisioned.


Keep reading about our Support Cases

Solution

The solution designed by our support team ensures that JSM portal customers who are not part of the required groups of UserSync are still provisioned by UserSync but are not assigned the jira-software-users group by default when they log into the JSM portal URL.

Generally speaking about the changes to the User Sync Connector, we can say the IdP filter from the first obstacle can stay, but we’ll get rid of the default assignment in two steps:

  • First, the default assignment of the jira-software-users group is removed from the Always Assign Users to Certain Groups section.
  • Then, a new Crowd attribute is created with a value that is added only when the user logs in via SAML. The cleanup behavior will have to be tweaked so that it doesn’t clean up users with a value in that new Crowd attribute.

Let’s see it in more detail. Remember that you can always reach out to us if you can’t get this to work, or have different requirements that you need to deal with!

Step-by-step Guide

The following settings need to be applied to your UserSync connector settings:

Step 1: Removing the default assignment of the application access group

Where: User Sync Connector >
  • Remove the default assignment of the jira-software-users group from the Always Assign Users to Certain Groups section: 
removing the access group from the default assignment

Step 2: Assigning the application access group conditionally

  • Scroll down to the Attribute Mapping section, and click on Edit beside the Groups attribute:
  • Click on Show Details, then choose Groovy Code for the Source Type, and enter the following Groovy code:

def defaultGroup = ["jira-software-users"]
def grps = con?.GROUPS ?: []
if (saml?.ORIGINAL_URL?.contains("/servicedesk/")) {
return grps
} else { grps.addAll(defaultGroup) return grps }

jsm portal customers are excluded with groovy code

Click on Apply, and Save the connector settings.

The above should only assign the jira-software-users group to users when they don’t access the Service Management URL. If the customer accesses the JSM portal URL, the group will not be added.

Step 3: Mapping a new Crowd Attribute

Where: User Sync Connector > Attribute Mapping
  • Click on Add New Attribute Mapping, and choose Crowd Attribute
creating a new attribute for customer login that will apply to JSM portal customers
  • Give it a name: customerLogin, and click on Next:
customer login attribute
  • Choose Groovy Code as the Source Type for the mapping, and enter the following line of code. This will add the value of the Name ID to the new attribute only when the user logs in via SAML. Otherwise, that attribute will remain empty:

1saml?.ATTR_NAMEID ?: DROP

groovy code example to drop a SAML attribute

Then click on Apply.

Step 4: Changing the Cleanup Behavior to protect customer accounts

Where: User Sync Connector >
  • Change the Cleanup Behaviour to Disable Users
  • enable the “Use Groovy to decide about cleaning up a user“ option
Determining how disable users with groovy code
  • add the following code:

boolean shouldCleanup(AtlasUser atlasUser, long syncStartedAtTimestamp) {
return timestamp(atlasUser) < syncStartedAtTimestamp
&& !atlasUser.containsKey("customerLogin")
}

  • Save the connector settings.

What the above would do is, when the customers log in to Jira via the portal URLs and SSO, they would have a new Crowd attribute with a value, and the cleanup behavior (in addition to its normal function) would also not clean up the users who have a value in that new Crowd attribute.

Conclusion

By following these steps, you can allow JSM portal customers who are not part of the required groups of UserSync to access the portal using SSO redirection without assigning the jira-software-users group to them by default. Using Groovy code to customize your UserSync connector settings can help you enable SSO redirection for JSM portal customers who are not part of the required groups, while still limiting UserSync to a specific subset of users.


The solution does not apply only to this specific use case, but to any scenario in which you need to split agents from customers, guarantee access to users that are not being properly managed on the idp side, or simply any case in which you want to separate types of users and manage their access to Jira more effectively, without compromising on security or convenience.

Spread the word!

This piece is part of a new series that showcases solutions to some of the most challenging problems that our enterprise customers have to face. They are based in real customers, real Atlassian environments, and real implementations, and are written for the technical folks with whom we love to work.

Reach out to us for help with implementing this solution or if you’d like us to cover any specific challenge in this series.

Subscribe to our newsletter:

Related articles: