SOP — Subscribe to and Manage Jira & Confluence for Enterprise

Goal: stand up Jira and Confluence for MPT Work so users sign in through the company IdP(s), accounts are provisioned/deprovisioned automatically, and the org supports both Microsoft and Google as identity providers.

0. Choose products, plan, and identity approach

Plans (Jira and Confluence each, per user, annual billing):

Identity — the decisive requirement for "Microsoft and Google":

• Atlassian Guard is required for SAML SSO and SCIM provisioning. Guard Standard connects ONE identity provider.
• Connecting multiple identity providers requires the Atlassian Enterprise plan (which includes Guard Standard at no extra cost). To run both Microsoft Entra and Google Workspace SSO, you need Enterprise.

Constraint & fallback: Atlassian Enterprise has a minimum of 801 users. If MPT Work is below that, you have one IdP via Guard Standard — pick Microsoft or Google for SAML SSO, and optionally allow the other through third-party login (Google/Microsoft social sign-in) without full SAML/provisioning. This SOP assumes Enterprise so both IdPs can be configured.

Other notes: Atlassian Data Center is end-of-sale for new customers (March 30, 2026), so Cloud is the path. Prefer annual billing — monthly subscribers are subject to Maximum Quantity Billing (billed on peak user count in the period).

Part 1 — Subscribe and create the organization

1. Sign up for Jira and Confluence Cloud (start trials at atlassian.com); they share one Atlassian Cloud site (e.g., mptwork.atlassian.net).
2. An Atlassian organization is created; manage it at https://admin.atlassian.com. Add initial organization admins (keep them minimal).
3. Subscribe to the Enterprise plan for Jira and Confluence (engage Atlassian sales / an authorized reseller — bundling Jira + Confluence + Guard typically improves pricing). Guard Standard is included with Enterprise.

Part 2 — Verify the mptwork.com domain and claim accounts

1. In admin.atlassian.com → Settings → Domains → Add domain → mptwork.com. Add the TXT (or HTML/DNS) verification record GitHub-style at your DNS host and Verify.
2. Claim accounts: once verified, all @mptwork.com Atlassian accounts become managed accounts your organization controls (apply policies, enforce SSO, deactivate).

Part 3 — Add the identity provider directories

On Enterprise you can add more than one IdP directory. Create both:

1. Security → Identity providers → Add identity provider → create a Microsoft Entra ID directory.
2. Add identity provider again → create a Google Workspace directory.
3. Link the verified domain mptwork.com (and/or specific user populations) to the directories per your plan for who authenticates where (see authentication policies, Part 6).

Part 4 — Configure Microsoft Entra SSO + SCIM

1. In Entra → Enterprise applications → New application → add the Atlassian Cloud gallery app → Single sign-on → SAML.
2. In Atlassian (Entra directory) → Set up SAML single sign-on:
   • Paste the Entra Login URL → Identity provider SSO URL.
   • Paste the Entra Identifier → Identity provider Entity ID.
   • Upload the Entra SAML certificate.
   • Copy Atlassian's SP entity ID and SP assertion consumer service (ACS) URL into the Entra app's Basic SAML config.
   • Save the SAML configuration.
3. SCIM provisioning: in the Atlassian directory generate the SCIM API key; in the Entra app → Provisioning → Automatic, enter the Tenant URL and Secret token, map attributes (ensure SAML NameID and SCIM email map to the same attribute), assign the user group (e.g., Staff-Atlassian-MS), and start provisioning. Group sync flows to Jira/Confluence.

Part 5 — Configure Google Workspace SSO

1. In the Google Workspace directory in Atlassian → Set up SAML single sign-on (or the Google Workspace SSO option) and follow the exchange with the Google Admin console (Apps → Web and mobile apps → add the Atlassian SAML app): map the IdP SSO URL, Entity ID, and certificate.
2. Provisioning: connect Google Workspace for user provisioning to sync accounts.

Google caveat: Google Workspace provisioning syncs users but does not reflect group categorization on your site, and SAML SSO means Google's MFA/password policy governs those users. For the richest group-based provisioning, prefer Entra for that population.

Part 6 — Authentication policies (who uses which IdP, and enforcement)

Atlassian governs SSO through authentication policies applied to subsets of managed accounts.

1. Security → User security → Authentication policies.
2. Create policies and assign members, e.g.:
   • MPT Microsoft SSO → users who authenticate via Entra → Enforce single sign-on.
   • MPT Google SSO → users who authenticate via Google → Enforce single sign-on.
   • MPT Admin Test → a couple of admin accounts → test SSO/IdP changes before rolling out.
3. Test on a small policy first, confirm sign-in works, then enforce broadly. Keep a non-billable policy for accounts that shouldn't consume a Guard seat where applicable.
4. Keep at least one org admin reachable (a break-glass admin) in case an IdP misconfiguration blocks SSO.

Part 7 — Products, access, and structure

1. Jira: create projects (company-/team-managed), permission schemes, and roles; grant access via groups (synced from the IdP) rather than individual adds.
2. Confluence: create spaces with appropriate permissions; map space access to groups.
3. Product access: in admin.atlassian.com → Products, control which groups have access to Jira vs Confluence; set sensible default access for new managed accounts.

Part 8 — Security baseline

1. Enforce SSO (Part 6); MFA/2-step is then governed by the IdP (Entra Conditional Access / Google 2SV).
2. Set session timeouts/expiry and API token controls in authentication policies.
3. Audit logging: stream the organization audit log to Microsoft Sentinel or your SIEM (Guard).
4. Guard Premium (optional upgrade): data security policies/DLP, shadow IT detection, and advanced access controls across the Atlassian estate.

Part 9 — User lifecycle (SCIM)

To prevent REST-API data access after offboarding, deactivate the user in the IdP (which deactivates them in Atlassian when provisioning is configured). Reconcile billed users vs seats regularly; on monthly billing, remember Maximum Quantity Billing charges peak counts.

Part 10 — Ongoing operations

Appendix — Notes and caveats

• Two IdPs need Enterprise. Guard Standard = one IdP; multiple IdPs require the Enterprise plan (Guard Standard included). Enterprise has an 801-user minimum — below that, use one SAML IdP plus optional third-party login for the other.
• SSO bypasses Atlassian-native MFA/password policy — the IdP becomes the authentication authority; ensure Entra/Google enforce MFA.
• Google provisioning doesn't reflect groups on the site; use Entra for group-driven provisioning where it matters.
• Only SAML 2.0 is supported (no OIDC). Don't mix one IdP for auth and another for the same users' provisioning in unsupported combinations.
• SAML certificates expire — track both the Entra and Google signing-certificate expiry to avoid SSO outages; keep a break-glass org admin.
• Cloud only for new buyers (Data Center end-of-sale 2026); prefer annual billing to avoid Maximum Quantity Billing; Marketplace apps add significant per-user cost — audit them.
• Verify current pricing/steps at atlassian.com and Atlassian Support — tiers, Guard packaging, and admin console layout change periodically.