2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies

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:

1. Navigate to Organization Security: Open admin.atlassian.com > Security > Identity providers.
2. Add Identity Provider: Select your provider (e.g., Microsoft Entra ID or Okta).
3. 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.
4. 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).
5. 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)
6. 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)       |                       |
+----------------------+ <-----------------------------+ +-----------------------+

1. 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.
2. 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.
3. 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.
4. 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:

1. 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.
2. 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.
3. Password Requirements: Sets minimum length, character complexity, and password expiration intervals (for non-SSO users).
4. 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:

1. Create a dedicated Emergency Policy in Atlassian Guard that sets Single Sign-On to None (Password Only).
2. In this policy, set Two-Step Verification to Enforced (mandating robust hardware security keys or authenticator apps) and enforce maximum password complexity.
3. Create at least two dedicated break-glass Organization Administrator accounts using a secure, segregated domain or dedicated corporate alias.
4. Assign these break-glass accounts exclusively to the Emergency Policy.
5. 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.