Identity and Access Management for Atlassian Government Cloud: A Practical Guide

Identity and access management should be one of the first design decisions in any Atlassian Government Cloud (AGC) program.

For government organizations, the question is not only how users will sign in. Teams also need to decide who should have access, how that access is granted, how permissions are structured and how access is reviewed over time.

AGC operates in a government-focused cloud environment with FedRAMP Moderate authorization and the customer still owns important parts of access governance. That makes identity design a core part of the AGC operating model.

A strong setup should answer four questions from the start:

Who can access AGC?
How do they authenticate?
What can they see and do?
How is access removed when it is no longer needed?

Start With the Identity Provider

The identity provider should be the foundation of the AGC access model.

Rather than managing users separately inside Atlassian, government teams should align AGC with the identity system they already use for enterprise access.

This usually includes reviewing:

• Current identity provider
• Verified domains
• Employee and contractor accounts
• Existing security groups
• User lifecycle processes
• Administrative accounts
• Access policies

The objective is to avoid maintaining one identity model in the enterprise directory and another inside Atlassian.

When the identity provider remains the main source for users and groups, account management becomes easier to control and easier to review.

Make SSO the Standard Access Path

Single sign-on should be treated as the normal entry point into AGC.

AGC supports SAML SSO, allowing users to authenticate through the organization’s identity provider rather than maintaining a separate Atlassian login process.

For government organizations, this helps keep authentication aligned with existing agency security controls.

Before production rollout, teams should test:

• User login
• Domain configuration
• Authentication policies
• Group-based access
• Admin access
• Recovery procedures

The test should cover the complete user journey, from the identity provider through to Jira, Jira Service Management and Confluence.

SSO is not only a technical configuration. It is part of the overall access model.

Use Provisioning to Control the User Lifecycle

Authentication determines how users sign in. Provisioning determines who should exist in the environment in the first place.

A strong provisioning model should account for:

• New employees
• Role changes
• Department transfers
• Contractor access
• Group membership changes
• Account deactivation
• User departures

This is especially important in government environments where access can remain active long after someone changes teams or leaves an assignment.

Provisioning helps tie Atlassian access to the organization’s broader identity lifecycle so that account changes are not handled as separate manual tasks.

Build Groups Around Real Business Roles

Groups are one of the most important parts of a manageable permission model.

Instead of assigning access directly to individual users, groups should reflect real roles or responsibilities.

Examples might include:

• JSM Agents
• Jira Project Users
• Confluence Editors
• Security Reviewers
• HR Service Team
• Finance Service Team
• Application Administrators

This gives teams a cleaner way to manage access and makes future reviews easier.

The challenge is not to create too many overlapping groups.

Group structures should remain understandable so administrators can quickly answer who has access and why.

Separate Administrative Roles From Daily Access

Administrative access should be treated differently from standard user access.

Not every administrator needs the same level of control.

A practical model can separate responsibilities such as:

Organization admins for top-level organization and security settings.

Product admins for Jira, Jira Service Management, or Confluence configuration.

Project admins for local project administration.

Standard users for day-to-day work.

This reduces the number of users with broad access and makes privileged permissions easier to review.

It also supports better accountability because each administrative role has a defined purpose.

Apply Least Privilege Across the Environment

Least privilege should be part of the design from the beginning.

The principle is simple: users should receive only the access they need to perform their role.

That principle should be applied across:

• Organization access
• Product access
• Group membership
• Jira project permissions
• Confluence space permissions
• JSM roles
• Administrative access

Broad default access may be easier to configure initially, but it becomes harder to govern over time.

A better question is:

Who needs access to this resource right now and what business role justifies it?

That keeps permissions tied to actual requirements.

Make Access Reviews Part of Normal Operations

Identity and access management does not stop after deployment.

People change roles. Contractors leave. Projects close. Admin responsibilities move. Teams are reorganized.

That means access should be reviewed regularly.

A good review process should include:

• Active and inactive users
• Group membership
• Organization admins
• Product admins
• Project permissions
• Confluence permissions
• External users
• Dormant accounts
• API access

The review process should have a clear owner, a defined frequency and a documented way to remove access that is no longer needed.

Treat External Access as Its Own Design Area

Government organizations often work with contractors, vendors, implementation partners and other external users.

External access should not simply inherit the same model as internal employees.

Teams should define:

• Who can approve external access
• What products external users can access
• Which projects or spaces they can reach
• How long access should remain active
• Who reviews that access
• How access is removed at the end of an engagement

Time-bound access is especially important for contractors and short-term partners.

Without defined ownership, external access can remain active long after the original need has ended.

Use Audit Activity to Support Governance

Audit information can help administrators understand changes in the environment.

This is most useful when there is already a process for reviewing it.

Government teams should decide:

• Who reviews admin activity
• Which changes require attention
• How often reviews happen
• How evidence is retained
• How unusual activity is escalated

The point is not simply to collect logs.

The value comes from connecting audit information to an actual governance process.

Design Identity Before Migration

For organizations moving from Data Center to AGC, identity should be designed before production migration.

Data Center environments may rely on LDAP, legacy directories, local users, inherited groups, or permission models that do not map directly into Government Cloud.

If identity is left until the end of the migration, teams can end up with data successfully moved into AGC but users unable to reach the content they need.

That is why identity should be tested alongside migration.

The test should include:

• User creation
• SSO
• Group assignment
• Project access
• Confluence access
• JSM roles
• Admin access
• Deactivation

Build the Access Model as One Connected System

A strong AGC identity model works best when each layer supports the next.

The flow can be viewed as:

Identity Provider → SSO → Provisioning → Groups → Roles → Permissions → Access Reviews

The identity provider establishes who the user is.

SSO controls how they authenticate.

Provisioning manages the lifecycle.

Groups organize users by role.

Permissions control what they can access.

Access reviews make sure those decisions are still valid.

When these pieces are designed together, identity becomes easier to manage, easier to audit and easier to maintain over time.

Why Clovity for AGC Identity and Access Design?

Clovity brings direct experience with Atlassian Government Cloud in real public sector environments.

Clovity was the first Atlassian partner to deploy Atlassian Government Cloud and was named Atlassian Partner of the Year 2026 – Government Americas.

That experience gives our team practical knowledge of the identity, migration, access and governance considerations that public sector organizations need to address when moving into AGC.

The goal is not simply to give users access to AGC.

It is to create an identity model that is controlled, manageable and aligned with how the organization actually works.

🌐 Visit www.clovity.com to get started today