How do you handle dynamic licenses with Atlassian Guard?

[David Yu]

We're currently on Data Center using the Resolution SSO add-on which is very powerful, and flexible. We have it designed where inactive users are automatically cycled out as our user licenses get low.

The nice thing is if those inactive users try to login in the future, they are automatically reassigned back their license, and we cycle out another inactive user by age automatically. All users can continue to submit Portal tickets.

This solution helps ensure we fully utilize our seat capacity as much as possible.

I'm trying to model a solution as close to this as possible in Guard, but it's a bit more challenging out-of-the-box. So far, the best idea I have is:

1. Provision all my users via SCIM to Okta but place them by default into a non-billable state. This ensures all my users are visible in the user pickers, and they can submit Portal tickets.

2. Setup a rule in Okta that automatically places my core users into jira-users group. But I'll also create a group in Okta called "Inactives" that I can place users in. If they are in that group, they will automatically removed from the jira-users group. I will probably also setup a workflow action in Okta to perform an instant group removal from that group in Jira as well.

The part that I'm stuck on is how can I dynamically reassign them a license back if they attempt to login? Seems like I could create a mini Forge app that listens on user-login events but it would be asynchronous from what I understand. So on the user's first attempt to open a link to a ticket, they may get denied until they refresh. 

[Jorge Cammarota · Accepted solution]

Group Synchronization via SCIM with Filters in Okta

This is the most robust way to manage the user lifecycle in the Cloud.

Strategy: Instead of synchronizing all users, configure Okta to send only users from specific groups to Atlassian Guard.

Automation in Okta:

Create a rule in Okta that removes users from licensed groups (e.g., jira-users-okta) after X days of inactivity.

SCIM will detect the group removal in Okta and instantly replicate it in Atlassian Cloud, releasing the license.

For reactivation, you can use Okta Workflows to detect the "Login Success" event and reassign the user to the group, which will trigger the provisioning back to Jira/Confluence.

[David Yu]

Thanks, I shall give that a try.

For the reprovisioning part, I think the user won't get instant access, and may need to refresh the page since re-adding back to the group won't be instant. But I think that's the best that can be achieved here.

[Ed Letifov _TechTime - New Zealand_]

Hello, @David Yu 

Unfortunately nothing relying on user-login events will work or rather "so far hasn't".

The only "instant" method we are recommending to our customers for now (this does involve our app UserManagement for Jira):

• keep IdP "this user SHOULD have a license" groups and Atlassian local "this user DEFINITELY DOES have a license" groups separate
• assign the "this user DEFINITELY DOES have a license" group as the product access group, not the IdP one
• pre-approve your users' email domain in Atlassian to be added to "this user DEFINITELY DOES have a license" group – note this WILL allow any user from these pre-approved domains to gain access to your applications
• use UserManagement app to keep the groups in sync:
  • regularly add users that IdP thinks should have access to the group that now controls access i.e. a cascade action someone is provisioned in OKTA, OKTA syncs to Cloud, UM syncs to the access groups
  • regularly remove users from the access groups that are NOT on the IdP list i.e. someone who wandered into the application (to look at cat videos posted on Confluence?) but who shouldn't really be occupying the license
  • if IdP keeps pushing someone who shouldn't be licensed – add them to the local exclude group and use this exclusion in the Scheduled Actions in User Management
• to round this up – use the "this user SHOULD have a license" as the ones controlling access to application features e.g. projects/spaces. This will allow you to let people into the application (e.g. to use the Portal) but restrict them from wrecking anything until they get the license from the IdP

See this page with a Loom videos from our development team (perhaps it will explain the solution better):

• User Management for Jira: Cloud: Allowing Atlassian Admins control of IDP synced Users 

Since these matters can also extend to external users:

• User Management for Jira: Cloud: Suspending Idle External Users 

And since this can be set up by access to a specific product rather than in general to Cloud:

• User Management for Jira: Cloud: Removing unused Product Access 

I do realise that using an extra app might not be what you are after even though you are coming off the Resolution one, however, if this sparks your interest – feel free to get in touch, our support is 24x7