try at Atlassian Marketplace
Give everyone the right to access Jira and pay only for active users

Give everyone the right to access Jira and pay only for active users

How can you provision 42,000 users into a 15,000 users Jira instance without destroying usability? Learn how to set it up in this step-by-step guide

Table of Contents

Jira Access Management can be universal. This is a technical guide on how to make that happen in an automated fashion without losing control of license consumption.

We want everyone in the company to potentially have access to Jira

Jira access management requirements
Today’s recipe: Provision everyone, give access upon login and revoke it when there’s no activity in 6 months

Here’s a real question that our support team got recently from one of our customers:

We want everyone in the company to potentially have access to Jira, but we don’t want everyone to have an active Jira account unless they use Jira. We have 42,000 user accounts in Azure AD, but only 15,000 Jira licenses. We have around 11,500 active Jira users.

In short: the company wants everyone to have the right to use Jira, but only pay for active users. This request is very common: it removes requests for access to the IT team and greatly encourages the use of Jira to manage every piece of collaborative work in the organization.

With this kind of setup, Jira tasks can be assigned to any user, even before they have accessed Jira for the first time. High-friction activities like onboarding and project initiation become way more efficient.

Translated into operational terms, the solution must combine three requirements:

RequirementSpecification
User ProvisioningEvery user is synchronized from Azure AD into Jira
Access ManagementUsers get application access only when they log into Jira
User DeprovisioningUsers who don’t use the application for a certain amount of time have their access revoked automatically

All three steps in the section above can be accomplished using different settings of resolution’s Single Sign-On, and specifically User Sync connectors. From a high level, this is what the solution looks like:

Lifecycle stepRequirementHow to do it with Single Sign-On & User Sync
User ProvisioningEvery user is synchronized from Azure AD into JiraRun full sync of an Azure AD connector
– no required groups
– no access group set (jira-users)
Access ManagementUsers get application access only when they login into JiraAccess group (jira-users) is set Just in Time when users try to log in via SSO.

Additionally, a groovy script blocks access in the event that the license limit is reached.
DeprovisioningUsers who don’t use the application have their access revokedUsers are disabled with two methods:
Cleanup inactive users connector. A user is automatically disabled when doesn’t log in for 180 days.
Scheduled sync with Azure AD. When an account is disabled on the IdP, this change will propagate to Jira.

Step-by-step Guide

This guide will take you through every step needed to complete the process using just your Atlassian stack and current apps, without the need to ask any help from the central IdM team.

Note that your current settings may be different to the default configuration we are assuming in the article. If you’re unable to figure out how to tweak it to meet your needs, we recommend scheduling a screenshare session with a specialist so we can figure it out together.

Prerequisites

  • A license of resolution’s Single Sign-On configured with your Identity Provider
  • An existing User Sync connector with the same Identity Provider

Configuring the Azure AD Connector in User Sync

Where: User Sync >

The User Sync Azure connector needs to provision every user without giving access.

To do this:

Step 1: Configure provisioning in the Azure AD Connector

The User Sync Azure connector needs to provision every user without giving access.

Let’s assume for simplicity that you’re about to work on a fresh installation and your users are not in Jira yet. In this case, the easiest way to provision users is to configure User Sync with Local Group Management.

This option will be activated by adding the any operator “.*” in the options “Never Remove Users from These Groups“, and “Never Assign These Azure AD Groups“. In combination, they mean that no groups will be changed whenever a user is synced.

And what if you have an already existing installation? Well, I could tell you that you have to remove the jira-users group from the Always Assign Users to Certain Groups, and then add it to the Never Assign Group from Azure… but this would assume that you’re sending the jira-users group from Azure AD.

80% of the folks reading this will have a different starting point… so reach out to us and let’s figure it out together!

Step 2: Filter out users that shouldn’t be provisioned into Jira.

Where: User Sync >

In this article we are assuming that your goal is to provision every employee. In that case, then you simply need to remove any required groups.

Required groups work as a filter. If you set jira-users as a required Azure AD group, then the User Sync connector will look up which users are members of that group on Azure AD.

If you leave the field empty as in the image above, you will be removing any filtering based on group memberships. As a result, every user in the IdP directory will be carried over into the User Sync directory.

It’s highly likely that your situation is in between: you may want to give access to almost everyone, with some exceptions like staff, contractors, interns, blue collar employees, or simply parts of the company that don’t need Jira at all. To use the filter in that case, simply:

  • add the users that should be provisioned to the group of your choice in Azure AD
  • set the same group as a required group in this step

Step 3. Set the cleanup behavior for users leaving the company and getting deactivated in AzureAD

Where: User Sync > Sync Settings

In the Cleanup behavior options, simply select “Disable Users” and optionally also enable “Remove group memberships during cleanup”. This will deactivate the accounts on the instance and (optionally) also removes all group memberships.

This optional step depends on whether you need or desire to completely deprovision your users. You may be interested in complying with ISO 27001 Annex A.9.2. Or you may want to make extra sure that access groups are not a back door for lingering access to your instance after a user has been deprovisioned.

Once set up, you should also schedule the connector to run periodically. It’s common practice to make it run every day at night, but it depends on how large your instance is and how frequently changes will have to be synced from the IdP.

Adding product access during login

Now we are going to move out of the User Sync connector and into the main part of the app: the SAML Single Sign On configuration. The goal is to use the SSO process to give access rights to every user who logs in successfully.

Step 4: Update with User Sync & SAML attributes

Change the method to update users to the option Update with User Sync Connector and apply SAML attributes

Where: SAML Single Sign On > > Identity Provider Settings
User Creation and Update option

Step 5: Add the jira-users group during login.

There are two ways of doing this:

  • via SAML attributes. If the groups for application access and granular permissions are already being set in Azure AD, it makes sense to add them dynamically. This option is interesting when different users have different group memberships already on Azure AD.

    To implement this option, simply map the Groups in the Jira attribute to the groups schema on Azure AD, using the following resource:
    http://schemas.microsoft.com/ws/2008/06/identity/claims/groups

    Note that you will need to create a group transformation for each group as per these instructions to have readable group names like some-azure-group instead of a cryptic group ID like “ajkj34i9fkfnjf”!

    Of course, you may be using a different IdP, in which case you can raise a ticket to get help in mapping exactly your groups.
  • via forced group memberships. The second option is to add the jira-users and any other mandatory groups during the SAML login in the option Always add users to these groups. Obviously, every user will belong to the same groups initially, and changes will have to be managed locally.

Group setting for users always added to groups

Applying a license limit with groovy script

Up until now, it could still happen that the number of users who need or want to use Jira grows overtime until the license limit is exceeded. This groovy script will block users that try to log into Jira for the first time, once there are less than 5 licenses available.

Step 6: Transform the username with groovy

Edit the attribute that is being used to find users in Jira (normally, the username) and add a custom transformation with Groovy Code as the source type.

Where: SAML Single Sign On > Attribute Mapping
Attribute Mapping menu
adding a custom groovy code

Finally, add the following code to the editor:

// In this example, it's assumed that the SAML Name ID contains the username.
 
// Check if the user already exists in the system and just
// return the Name ID in this case
def existingUser = findUserKeyByUsername(mapping.ATTR_NAMEID)
if(existingUser != null) {
    return mapping.ATTR_NAMEID
}
 
int freeLicenses = getAvailableJiraSoftwareUserLicenses();  // Jira Software
//int freeLicenses = getAvailableJSMUserLicenses();           // Jira Service Management
//int freeLicenses = getAvailableJiraCoreUserLicenses();      // Jira Core
//int freeLicenses = getAvailableBitbucketUserLicenses();     // Bitbucket
//int freeLicenses = getAvailableConfluenceUserLicenses();    // Confluence
 
// If there are less than 5 free licenses available, drop the user with an appropriate message
// Which will be shown on the error page.
if(freeLicenses < 5 ) {
    return dropAll("Not enough Licenses: $freeLicenses")
} else {
    return mapping.ATTR_NAMEID
}

Setting up the Connector to Disable Inactive Users

By this time we have almost all the ingredients:

  • Every user is being synced to the Atlassian product without consuming licenses
  • Licenses are used only as users log in
  • When licenses are used up, the Just in Time access is blocked.

With this last operation, users who haven’t accessed Jira or Confluence in 6 months will have their access revoked. This setting should make the groovy script a last resort only and ensure that there is a healthy buffer between the active users and the license limit.

Step 7. Create a Cleanup Inactive Users connector

The feature to cleanup inactive users comes with its own connector, since it’s not actually syncing from the IdP, but rather removing from the local directory.

Where: User Sync >
Create Connector dialog

Step 8. Choose the local directory to disable inactive users

Where: User Sync > Specific Settings

Step 9. Add the maximum number of days since the last successful login.

We usually recommend 180 days, or 90 days if you want to be more strict.

Step 10. Set the cleanup behavior for inactive users

In the Cleanup behavior options, simply select to “Keep Users without modification” but enable “Remove group memberships during cleanup”. This will keep the accounts active on the instance, so they will still be provisioned, but will have their application access revoked.

Where: User Sync > Sync Settings

Step 11. Schedule the connector!

For instances with over 3,000 users, we recommend running the connector maximum once every night or twice per day. Otherwise, the sync can overload and be prone to fail.

Cron expression

Configuration Summary

With this configuration, you will provision all users from Azure AD automatically, but you won’t assign any application access groups. This enables you to already assign work to accounts who are not using Jira yet without handing out a license. As soon as Jira access is required the users just needs to log in via SSO using their credentials from Azure AD and gain access to Jira seamlessly. It’s only then that a license starts being consumed by the user.

When users leave the company: The account will be deprovisioned in Azure AD, and User Sync will deprovision them in Jira with the next sync.

When users don’t need to access Jira anymore: The user license will be automatically revoked after 180 days of inactivity.

The plugin actively checks the number of remaining licenses and throws a login error message when the limit is reached an a new user is trying to access Jira. This ensures that it is not possible to over-provision Jira – which would cause an outage for all users.

References

Here are the documentation articles for the settings discussed in this guide:

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: