Managing Atlassian Cloud access sounds simple until you’re managing hundreds of users with different IdPs across applications like Jira, Confluence, and more. You have to manually onboard users, assign groups, and revoke access at the right time. It’s very tedious, and if you miss a beat, you risk an ex-employee still having access to their Jira account, creating security concerns.
Atlassian Guard provides a solid baseline for cloud security. However, as you grow, you’ll encounter structural and financial walls when it comes to integrating multiple IdPs.
This guide breaks down how cloud identity management functions, how Atlassian Guard processes authentication, and how you can use targeted single sign-on (SSO) and user sync (SCIM) solutions to integrate multiple identity providers (IdPs) while remaining on Atlassian Standard or Premium plans.
Core Components of Identity Management
Identity management is much more than user authentication. A complete identity strategy ensures that users can access the resources they need while IT teams have centralized control over security.
The five core components of identity management are:
Authentication (SSO): Verifying user identities through a centralized IdP such as Microsoft Entra ID, Okta, or Google Workspace.
User Provisioning (SCIM): Automatically creating and updating user accounts across Atlassian applications.
Group Management: Assigning permissions through groups instead of managing users individually.
Deprovisioning: Removing access when users leave the organization or change roles.
Access Governance: Enforcing security policies, reviewing permissions, and maintaining audit visibility.
Atlassian Guard helps address several of these areas, particularly authentication and security policy enforcement. That makes it a foundation for many organizations' cloud identity strategy.
Understanding Identity Management in Atlassian Cloud
Managing user identities within the Atlassian Cloud ecosystem comes with a unique set of architectural rules. Unlike Data Center deployments, where you manage authentication and infrastructure yourself, Atlassian Cloud uses a centralized identity model built around Atlassian accounts.
Here, every user logs in using a unique Atlassian account. This account follows the individual user, but your company can claim administrative control over it through domain verification.
Once you verify your corporate domain within your Atlassian Organization, you can claim accounts associated with that domain and manage them centrally. This centralized structure allows you to enforce security policies, track audit logs, and mandate authentication requirements across Atlassian Cloud apps.
However, this global identity model introduces significant challenges as your operations scale. The most common challenges fall into three areas.
The Site vs. Organization Split
Your security policies are configured at the organization level, but your users collaborate within individual product sites. If you bring in external users, such as vendors or contractors with different email domains, you can grant them access to your Atlassian sites, but you cannot manage their accounts through your verified-domain controls.
Atlassian Shadow IT
Because Atlassian accounts are global, employees may create Atlassian sites outside central IT oversight. Organizations often use Atlassian Guard's discovery capabilities to identify and manage these instances.
Lack of Visibility into Collaboration
When collaborating with external partners, you can either ask them to create accounts in your domain or allow them into your internal projects using unmanaged accounts. This can make it harder to apply consistent authentication policies and maintain visibility into how external users access your environment.
To bring structure into this environment, you need a strong link between your identity infrastructure and Atlassian Organization. When you rely solely on native, out-of-the-box setups, you quickly realize that Atlassian's architecture expects a simple, one-to-one relationship between your corporate directory and your managed accounts. In a complex corporate landscape, that assumption rarely holds true.
This is where SSO becomes important. Once you establish ownership of identities through your Atlassian Organization, you need a secure and scalable way to authenticate users.
Understanding Atlassian Guard's Role in the SSO Process
Atlassian Guard (previously known as Atlassian Access) is Atlassian’s native security framework for cloud environments. It provides organization-level control over your users, allowing you to enforce security policies across all your linked sites and cloud products.
When you implement SSO via Atlassian Guard, it redirects users to the configured identity provider for authentication. Once your IdP verifies the user's credentials, it passes a secure SAML assertion back to Atlassian. The user is then granted access without ever creating separate credentials.
Guard also handles authentication policies. You can set up different rules for different subsets of accounts. For example, you can enforce strict session durations for internal staff while allowing longer sessions for specific automated service accounts.
Configuring Multiple IdPs
Atlassian Guard Standard and Premium allow you to integrate only one IdP. However, many businesses use multiple IdPs.
For instance, you might have external consultants who need to log in with a different IdP. Or a subsidiary that uses a different one.
The native solution for this is to upgrade your entire product ecosystem to the Atlassian Cloud Enterprise plan. However, that plan is designed for massive operations. It carries a steep minimum user threshold, typically requiring a commitment of 800+ users as of now.
If your company has less than that, upgrading to the Enterprise tier just for multi-IdP support is a major financial hurdle. Organizations in this situation often look for ways to support multiple IdPs without moving to the Enterprise tier.
Multi-IdP Support on Atlassian Standard or Premium Plans
Here’s a way to integrate multiple IdPs while remaining on the Standard or Premium plan. You can install the miniOrange SAML SSO + User Sync/SCIM app, which allows you to integrate multiple SAML 2.0 identity providers, including:
- Microsoft Entra ID
- Okta
- Auth0
- Keycloak
- OneLogin
- Ping Identity
- ADFS
- Other SAML 2.0-compliant providers
Advanced Redirection Rules and Routing
To make a multi-IdP setup work seamlessly for your users, the authentication process must be invisible. miniOrange utilizes dynamic redirection rules to route incoming login requests automatically. It can route users based on their domain or their groups to the right IdP.
Domain-Based Routing: If a user types in an email ending in @subsidiary.com, the system automatically routes them to the subsidiary's Okta instance. If their email ends in @parentcompany.com, they go straight to Entra ID.
Group-Based Routing: Users can be directed to specific login providers based on their pre-existing application groups or directory sources.
This level of granular control allows you to stay on the Standard or Premium plan while still taking advantage of advanced identity features.
Modernizing User Lifecycles with Advanced SCIM
Authentication solves the front-door problem. You also have to manage user lifecycles. If that aspect isn’t automated, admins have to manually create accounts, assign groups, and remove access day in and day out. That's where SCIM comes in.
SCIM (System for Cross-domain Identity Management) focuses on user provisioning and lifecycle management. It’s the missing piece that complements SAML SSO by automating user provisioning, synchronization, and deprovisioning.
The miniOrange SAML SSO + User Sync/SCIM app automates user provisioning and de-provisioning. You simply have to add a new user to your IdP, and SCIM automatically creates that user account inside your Atlassian apps with the right groups.
More importantly, miniOrange secures your offboarding process. The moment an employee leaves the company and is deactivated in your central IdP, the app pushes that status change to Atlassian apps.
But what if your IdP doesn’t support SCIM?
REST API-Based Synchronization
The miniOrange app offers a flexible REST API-based synchronization protocol alongside standard SCIM. You can sync users, groups, and attributes from your IdP to Atlassian apps.
This dual-protocol capability ensures that, regardless of your identity provider's underlying technology, you retain 100% automated user lifecycle management without relying on manual workarounds.
Building a Complete Identity Management Strategy
Having robust security should not require you to overpay for your software tier. By pairing Atlassian Guard with the miniOrange SAML SSO + User Sync/SCIM app, you can maintain security and automate user lifecycle management while keeping your Atlassian license cost under control.
Investing in the right identity strategy today helps ensure your Atlassian environment remains secure and easier to scale.
Frequently Asked Questions
1. How does SCIM improve onboarding and offboarding?
SCIM helps automate identity lifecycle workflows.
New users can be provisioned automatically through directory sync.
When users leave your organization or change roles, the status changes are synced into Atlassian applications. This helps maintain cleaner access governance.
2. Does Atlassian support SAML SSO?
Yes. Atlassian supports SAML-based authentication.
Deployment details can vary depending on whether you use Cloud or Data Center environments.
For Atlassian Cloud configurations, enabling SSO functionality may require Atlassian Guard, depending on your setup.
3. What is the difference between SAML and SCIM in Atlassian?
SAML and SCIM serve different identity management purposes.
SAML handles authentication. It allows users to log in to Atlassian applications through an external Identity Provider.
SCIM handles user lifecycle management. It automates provisioning, deprovisioning, group synchronization, and attribute updates.
Leave a Comment