How SSO and user provisioning closed an Atlassian access gap

What the customer asked for

The customer wanted two things. They wanted a more secure Atlassian environment, and they wanted user management to be easier. Both goals pointed to the same project: connect Atlassian to Okta, the company's identity provider.

On the surface, that sounds like a quick SSO setup. It rarely is. How access was built over the years decides how much work the connection takes.

What was really going on

Access had grown without a standard. That showed up in several places at once.

Groups did not map to anything clear

There was no single group you could point to and say, this is who has access to this product. Access to each app, and to admin rights, was spread across several groups. Some groups were shared across apps, so getting access to one app quietly gave people access to another. Licensing followed the same tangled path, which made it hard to know why anyone held a seat.

Spaces were not mapped to groups and roles

Inside Jira and Confluence, space permissions were not tied to groups and roles in a consistent way. So even if the product-level groups had been clean, access inside the apps was still hard to reason about.

Nobody was checking who was still active

No one had reviewed which users should have been deactivated. Accounts stayed open long after the people behind them had moved on.

Teams were creating their own Atlassian sites

Some groups had set up their own Atlassian sites outside the organization, using their company email addresses. Nobody in IT was managing those sites, and company security policies did not apply to them. Because the company accounts were not managed, nothing stopped a user from moving company data, such as Jira work items, into a site the organization could not see or control.

How we found it

We did three things before changing anything.

1. Inventoried groups. We listed every group, what it granted, and which apps it touched.
2. Reviewed space permissions. We checked how access inside Jira and Confluence was assigned.
3. Reviewed authentication policies. We looked at how people were actually logging in.

The third step produced the finding that surprised everyone.

Former employees could still log in

Many people who had left the company still had working access. Their Atlassian accounts were not synced with Okta. They were local Atlassian accounts with their own passwords.

So when someone left and IT disabled their Okta account, that person lost access to email and every other connected app. But they could still sign in to Atlassian with the password they had set up there years before. Each of those accounts was a security hole, and each one was still taking a license seat.

Put that next to the unmanaged sites, and the risk grows. An account that IT cannot control, with a password that still works, can reach company data and move it somewhere IT cannot see. That combination changed how the customer saw the project. It was no longer about convenience. It was about closing doors they did not know were open.

The rollout

We ordered the work so the biggest risk closed first, then moved toward finer control.

1. Set up SSO with Okta. We connected Atlassian to Okta so authentication happened in one place.
2. Enforce SSO for managed users. Using authentication policies in Atlassian Guard, we required managed accounts to sign in through Okta. That ended password logins to Atlassian and closed the hole right away.
3. Turn on user provisioning. With SCIM provisioning from Okta, accounts are created and deactivated based on the identity provider. People who had already left were cleaned up, their license seats came back, and future departures are handled automatically.
4. Bring unmanaged sites under control. With company accounts managed, admins can see the Atlassian sites those users create and decide whether users can create new ones on their own.
5. Rebuild product access groups. We set up standard groups for each app and for admin roles, so each group grants one clear thing and nothing extra.
6. Go granular inside the apps. With clean groups in place, we mapped spaces to groups and roles so access inside Jira and Confluence followed the same logic.

The first three steps were a simple win. They closed the security gap and freed up licenses before we touched a single space permission. That early result also bought the trust we needed for the more detailed work that followed.

The decisions they had to make

The main worry was control. The Atlassian admins thought that if groups came from Okta, they would lose the ability to create groups and grant access when teams asked.

That concern is common, and it is fair. With provisioning, group changes do involve the team that runs Okta. Some decisions that used to happen inside Atlassian now happen one step earlier.

But the admins did not lose control. They gained a standard process that everyone understood. Requests went through a clear path, groups meant one thing each, and nobody had to chase down stale accounts anymore. Day-to-day work for the teams using Jira and Confluence did not change at all.

How it turned out

It was a net positive. The security hole closed immediately. Licenses went back to people who actually needed them. The admin team spent less time on maintenance, not more, even with the identity team involved in some decisions. Access became something the customer could explain and review, instead of something they had to reverse engineer.

What I tell teams about to do this

1. Check authentication before anything else. Find out whether local Atlassian passwords still work.
2. Look for Atlassian sites your users created outside the organization.
3. Enforce SSO for managed accounts as early as you safely can.
4. Turn on provisioning so deactivation happens in one place.
5. Inventory groups and give each one a single, clear purpose.
6. Stop sharing groups across apps unless that access is intended.
7. Map spaces to groups and roles after the product-level groups are clean.
8. Agree up front on how group requests flow between the Atlassian admins and the identity team.

Where this connects to identity and agents

The gap here was simple. An identity existed in Atlassian that Okta did not control, so turning off the person did not turn off the access. Agents raise the same question. Every agent that acts in Jira or Confluence acts as some identity, with some set of permissions. If that identity is not created, reviewed, and removed through the same process as everyone else, you end up with access that outlives its purpose. The fix is the same one we used here: one source of truth for identity, clear groups that grant one thing each, and deactivation that happens in one place.