📛
Atlassian のアカウント管理モデル

2025/12/05に公開
 はじめにAtlassian のクラウドでのアカウント管理に関して、コンセプトというか概念を自分なりにまとめたのもです。具体的な機能や操作方法には触れません。

 初めて Jira / Confluence を使い始める初めてJiraやConfluenceを使う場合、alice@example.comのaliceがConfluenceのトライアル開始ページからボタンをクリックし、パスワード設定やメール確認を行うと、Confluenceが利用可能になります。
aliceはConfluenceの管理者であり、同時にユーザーでもあります。管理者としてはスペースの作成や設定ができて、ユーザーとしてはページの編集ができます。
図を見ると、aliceのアカウントはAdminロールのリストに入っています。AdminロールのアカウントはConfluenceの管理機能を使えて、User権限のアカウントは普通にConfluenceの機能を使えます。
ここで「App」はJiraやConfluenceのことを指します。実際には、他のユーザーを招待する権限とAdmin権限は別のロールで、Jiraの管理者とユーザーの関係も複雑です。この記事ではその細かい部分は省いています。

 外側を詳しく見るさて、ここから alice は知り合いの bob やら charlie を App に招待していくわけですが、その前に App の外側を詳しく見ていきます。
alice のアカウントは Atlassian クラウド全体でユニークです。
App 作成時に明示されませんが、Organization という管理単位が作成され、その中に App が配置されます。Free、Standard、Premium では各 App を1インスタンスのみ持てますが、Enterprise では複数持てます。
Organization には Org Admin というロールがあり、この場合は alice のみが含まれます。ほかのアカウントも招待可能です。Org Admin は App の作成、設定、削除を行えます。

 Bob を招待するさて、alice は知り合いの bob を招待します。

 Atlassian にアカウントがない場合もし bob がこれまでに Atlassian を使ったことがなければ、新規に unverified な bob@example.com 用アカウントが作成され、招待メールが送信されます。また App のユーザーリストに bob が含まれます。
bob がメールを確認しアカウント設定を完了すると、Organization Zoo 内の App にアクセスできます。

 Atlassian にアカウントがある場合もし bob がすでに Atlassian を使っている場合、Atlassian クラウドにアカウントがあります。現役であれば、どこかの Organization の管理者かユーザーでしょう。その場合は、既存の bob のアカウントはそのままで、alice が管理する Organizaiton Zoo のロールのリストに bob が追加されます。

 App の詳細を隠すさてここからは、Organization レベルの話をするので、App の詳細をちと省いていきます。

 Guard Standard を導入するAtlassian Guard Standard という管理プロダクトがあります（App と呼ぶのが正しいですが、この文脈ではややこしいためプロダクトとします）。大まかに言うと、アカウントの認証ポリシーを強化します。
Guard Standard を使う際、多くの場合はまず domain verification を行います。管理するアカウントのメールアドレスのドメイン名が、管理者または属組織の所有であることを確認します。DNS レコードの追加などを行い、この Organization の verified domains リストにドメイン名が追加されます。
このドメインを持つユーザーを、この Organization の管理対象アカウント (managed account) に設定します。ドメインの全ユーザーを自動的に管理対象アカウントに設定することも、明示的に指定することも可能です。
次に認証ポリシー (authentication policy) を定義します。例えば 2FA の必須化やパスワード強度の指定が可能です。この認証ポリシーを適用するメンバーも指定します。SCIM による自動プロビジョニングも可能ですが、ここでは扱いません。
これにより、alice と bob は Atlassian クラウドにログインする際、認証ポリシーで設定したルールが適用されます。

 SAML の SSO を使うここまでやると、Single Sign-On (SSO) したくなりますよね。
まず、管理画面の機能で IdP (ID Provider) と Organization を関連づけます。trust 情報を交換するっていうんですかね。そういう操作です。
次に、認証ポリシーの SSO 項目に、先ほど設定した IdP を指定します。これで alice と bob は、指定した IdP による SSO が強制されます。やったね。

 他の Organization で管理されているアカウントにアクセスを許可する最後に、別のOrganizationで管理されているアカウントcharlieを招待することを考えます。いくつかのユースケースがあります。
charlieはaliceと同じ会社のメンバーだが、charlieの部署は別のOrganizationを運用している
charlieは関連会社、サプライヤー、顧客組織のメンバーで、協業している
など
この場合、外部ユーザー認証ポリシーを設定します。
最もシンプルなのはノーガード戦法で、制限を設けないパターンです。マジかよって思いますよね。補足します。charlieがAtlassianクラウドにログインする際は、所属組織Organization Yardの認証ポリシーか個人アカウントのID/passwordで認証します。ノーガードの場合でも同様です。なので認証なしで公開するわけではないです。
外部ユーザーの認証ポリシーは、aliceのOrganization ZooのAppアクセス時に、どんな追認チェック機構を使うかを指定します。OTP (One-Time Password)やSSOを設定できます。
SSO設定には、charlieの所属組織のIdPとの接続が必要です。通常、同じ企業で複数Organizationを運用している場合や、親会社/子会社関係でIdP設定が可能な場合になるでしょう。

 まとめというわけで、アカウント管理のコンセプトというかモデルの考え方をまとめました。もしかしたら間違ってるかも知れないので、指摘してもらえたら直します。よろしくお願いします。