Study guide
2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies
Key Takeaways Explain This Topic AI
Atlassian Guard (formerly Atlassian Access) adds organization-level identity controls such as SAML SSO, SCIM provisioning, and authentication policies, billed per unique user rather than per site.
SAML 2.0 Single Sign-On integrates with corporate Identity Providers (Okta, Microsoft Entra ID, Google Workspace) to enforce centralized enterprise authentication.
SCIM user provisioning automates real-time user lifecycle management, attribute synchronization, group pushing, and instantaneous deprovisioning upon employee departure.
Authentication policies apply only to managed accounts; external users are governed by a separate external user policy that can require two-step verification.
Mandatory Two-Step Verification (2FA), session duration limits, and API token governance prevent unauthorized access, credential stuffing, and unmonitored script execution.
Last updated: September 2026
2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies
Blueprint context: The ACP-120 V2 blueprint expects you to understand managed and unmanaged accounts, licensed and anonymous access, and the admin roles that control them. Deep SAML and SCIM configuration is covered more heavily by the Atlassian Cloud Organization Admin exam (ACP-520). Use this section as background so you can recognize which settings live at the organization level.
Quick Summary: Atlassian Guard (formerly known as Atlassian Access) is the enterprise security and identity governance subscription for Atlassian Cloud. It bridges an organization's verified domains with modern enterprise Identity Providers (such as Microsoft Entra ID, Okta, and Google Workspace) to deliver SAML 2.0 Single Sign-On (SSO), automated SCIM user and group provisioning, multiple authentication policies, session duration governance, and security auditing across all linked sites.
Understanding Atlassian Guard
While domain verification allows an organization to claim and manage accounts at a basic level, enterprise identity federation requires Atlassian Guard . Guard operates at the Organization level ( admin.atlassian.com ) and applies across every Atlassian Cloud product linked to the organization (Jira Software, Jira Service Management, Jira Product Discovery, Confluence, Bitbucket, and Trello).
The Unique Subscription Model
Atlassian Guard is an organization-level subscription, so it is billed per unique user rather than per site:
Billed per unique user: Guard counts each user once, no matter how many sites or apps that user can access.
Multi-site deduplication: If jane@acme.com has access to Jira on Site A, Confluence on Site B, and Jira Service Management on Site C, the organization pays for one Guard user, not three. +-------------------------------------------------------------------------+
- | ATLASSIAN GUARD BILLING |
- | |
- | User: jane@acme.com (Managed Account) |
- | - Site A: Jira Software (Paid Product Seat) |
- | - Site B: Confluence (Paid Product Seat) |
- | - Site C: Jira Service Management (Paid Product Seat) |
- | |
- | TOTAL ATLASSIAN GUARD CONSUMPTION: 1 BILLABLE GUARD SEAT |
- +-------------------------------------------------------------------------+
- SAML 2.0 Single Sign-On (SSO)
SAML 2.0 Single Sign-On delegates user authentication from Atlassian Cloud to an external Identity Provider (IdP). When an employee attempts to log in to Jira, Atlassian redirects their browser to the corporate IdP. Once the user authenticates with their corporate credentials (and any IdP-level MFA), the IdP issues a cryptographically signed SAML response containing an assertion that validates the user's identity.
Supported Identity Providers
Atlassian Guard provides turnkey SAML 2.0 connectors for major enterprise identity platforms:
- Microsoft Entra ID (formerly Azure Active Directory)
- Okta
- Google Workspace
- PingFederate / PingOne
- OneLogin
- Generic SAML 2.0 IdPs (supporting standard metadata XML exchange)
- Step-by-Step SAML Configuration Flow
Configuring SAML SSO requires an administrator to exchange metadata between Atlassian Guard and the Identity Provider:
Navigate to Organization Security: Open admin.atlassian.com > Security > Identity providers .
Add Identity Provider: Select your provider (e.g., Microsoft Entra ID or Okta).
Retrieve Atlassian SP Metadata: Atlassian generates the Service Provider (SP) values you'll enter in the IdP: the SP Entity ID and the Assertion Consumer Service (ACS) URL , both hosted on auth.atlassian.com .
Configure Enterprise App in IdP: In the IdP console, create an Enterprise Application, supply the SP Entity ID and ACS URL, and configure NameID mapping (must map to the user's corporate primary email address).
Supply IdP Metadata to Atlassian: In Atlassian Guard, enter the IdP's configuration parameters:
- Identity Provider Entity ID
- Identity Provider SSO URL
- Public X.509 Certificate (used by Atlassian to cryptographically verify SAML assertion signatures)
Test SAML Connection: Perform a test authentication using a test account to validate certificate signing, NameID attributes, and redirection loops before enforcing SSO globally.
Exam Trap: SAML assertions rely on exact email matching. If the NameID attribute sent by the IdP is formatted as sAMAccountName (e.g., jdoe ) or user principal name (UPN) differing from the Atlassian account email ( john.doe@acme.com ), SAML authentication fails with an attribute mismatch error.
Automated Provisioning: SCIM
While SAML handles authentication (verifying who a user is), SCIM (System for Cross-domain Identity Management) handles provisioning (managing user existence, profile attributes, and group memberships).
Without SCIM, administrators must manually invite users to Jira or rely on Just-In-Time (JIT) provisioning, which only creates accounts when users attempt their first login. SCIM solves this by creating an automated, outbound synchronization pipeline from the IdP to Atlassian Cloud.
- The SCIM Lifecycle +----------------------+ SCIM 2.0 API Push +-----------------------+
- | | -----------------------------> | |
- | Corporate IdP | 1. Create User (Joiner) | Atlassian Guard |
- | (Entra ID / Okta) | 2. Update Attributes (Mover) | (admin.atlassian.com)|
- | | 3. Sync Groups (Push Groups) | |
- | | 4. Deactivate (Leaver) | |
- +----------------------+ <-----------------------------+ +-----------------------+
User Creation (Joiners): When HR adds a new employee to the IdP and assigns them to the Jira application, SCIM makes an automated REST API call to Atlassian Guard, creating the managed account instantly before the employee ever logs in.
Attribute Synchronization (Movers): Updates to user profile attributes (such as first name, last name, department, or title) in the IdP automatically overwrite and synchronize to the Atlassian user profile.
Group Synchronization (Push Groups): Security groups defined in the IdP (e.g., jira-developers , service-desk-analysts ) are pushed directly into the Atlassian organization directory. Adding or removing a user from the group in the IdP immediately updates their group membership in Atlassian Cloud.
Instant Deprovisioning (Leavers): When an employee is disabled or unassigned in the IdP, SCIM immediately deactivates the user account in Atlassian Cloud. This terminates all active web and mobile sessions, invalidates API tokens, and frees all consumed Jira product licenses within seconds.
SCIM Configuration Mechanics
In admin.atlassian.com > Security > Identity providers > Select IdP > User provisioning .
Generate a SCIM Base URL ( https://api.atlassian.com/scim/directory/{directory-id} ) and an encrypted SCIM API Key / Bearer Token .
Enter the Base URL and Bearer Token into the IdP's provisioning settings.
Configure IdP attribute mappings (SCIM userName -> Atlassian email address; displayName -> Full Name; active -> Account status).
Important Nuance: Atlassian SCIM directories are one-way synchronization pipelines (IdP -> Atlassian Cloud). Group memberships pushed via SCIM become read-only inside admin.atlassian.com . Site Administrators cannot manually add or remove users from SCIM-synced groups inside Jira; membership changes must originate in the IdP.
Authentication Policies
Atlassian Guard allows organizations to define multiple Authentication Policies ( admin.atlassian.com > Security > Authentication policies ). Authentication policies dictate the exact security parameters enforced when managed users log in.
Policy Parameters
Each authentication policy allows administrators to independently configure:
Single Sign-On (SSO):
Enforced: Users must authenticate through the configured SAML IdP. Local Atlassian passwords cannot be used.
None (Password Only): Users authenticate using an Atlassian account password.
Two-Step Verification (2FA / MFA):
Can be set to Enforced for non-SSO policies, requiring users to register a mobile authenticator app (TOTP) or hardware security key.
Password Requirements: Sets minimum length, character complexity, and password expiration intervals (for non-SSO users).
Idle Session Duration: Automatically logs users out after a configured period of inactivity.
Scope rule: Authentication policies apply only to managed accounts (accounts on your verified domains). External users, whose email domains your organization doesn't own, are governed by a separate external user policy ( Security > User security > External users ). That policy can require external users to verify their identity with two-step verification before they see your content. It applies to all external users or none of them.
The Emergency Break-Glass Admin Pattern
A critical enterprise best practice heavily tested on the ACP-120 exam is the Emergency Break-Glass Administrator Account .
The Threat Scenario: If your corporate Identity Provider suffers a major service outage, an expired SAML signing certificate, or misconfigured conditional access rules, all standard employees—including Organization Administrators—are locked out of Atlassian Cloud. Because SAML is enforced, nobody can authenticate to resolve the issue.
The Solution Architecture:
Create a dedicated Emergency Policy in Atlassian Guard that sets Single Sign-On to None (Password Only) .
In this policy, set Two-Step Verification to Enforced (mandating robust hardware security keys or authenticator apps) and enforce maximum password complexity.
Create at least two dedicated break-glass Organization Administrator accounts using a secure, segregated domain or dedicated corporate alias.
Assign these break-glass accounts exclusively to the Emergency Policy.
Store the credentials, recovery keys, and hardware tokens in an enterprise password vault requiring dual-custody authorization. +-------------------------------------------------------------------------+
- | AUTHENTICATION POLICY ARCHITECTURE |
- +-------------------------------------------------------------------------+
- | |
- | [ POLICY 1: Enterprise Workforce (Default) ] |
- | - Scope: 5,000 corporate employees (@acme.com) |
- | - SAML SSO: ENFORCED (Microsoft Entra ID / Okta) |
- | - Atlassian Password: DISABLED |
- | - Session Duration: 12 Hours |
- | |
- | [ POLICY 2: External Contractors ] |
- | - Scope: 150 third-party vendors & contractors |
- | - SAML SSO: None (Users lack corporate IdP accounts) |
- | - Two-Step Verification (2FA): ENFORCED |
- | - Session Timeout: 4 Hours idle |
- | |
- | [ POLICY 3: Emergency Break-Glass Admins ] |
- | - Scope: 2 Dedicated Org Admin Emergency Accounts |
- | - SAML SSO: NONE (Bypasses IdP to survive SSO outages) |
- | - Two-Step Verification (2FA): ENFORCED (Hardware Security Key) |
- | - Purpose: Restores admin access if Okta/Entra ID becomes unreachable |
- +-------------------------------------------------------------------------+
- API Token Governance
In Jira Cloud, basic authentication using user account passwords has been permanently deprecated for REST API interactions. Instead, users and automated integration scripts must authenticate using Atlassian API Tokens combined with their email address.
However, unmonitored API tokens introduce security risks, such as data exfiltration or compromised personal developer workstations.
Atlassian Guard API Token Controls
Through Atlassian Guard, Organization Administrators can enforce governance over API tokens created by managed users ( admin.atlassian.com > Security > API token controls ):
View Active API Tokens: Administrators can inspect which managed users have generated API tokens, when each token was created, and when it was last accessed.
Revoke Tokens: Administrators can immediately revoke specific compromised or orphaned API tokens without deactivating the user's primary account.
Block API Token Usage: Organizations can globally prohibit managed accounts from generating or using API tokens, forcing all programmatic automation to utilize dedicated OAuth 2.0 Service App integrations or non-managed service accounts.