このドキュメントでは、Atlassian Cloud でドメイン認証～ID プロバイダ統合を実施した際に、利用ユーザーへどのような影響があるかを記載します。
(2022年7月23日時点の情報です)
Atlassian Cloud で、ドメイン認証 → ID プロバイダー 統合する際のステップは以下の通りです。
１．ドメイン認証
ユーザへの影響は一切ありません。
ドメイン認証の詳細は、ドメイン認証 (Atlassian Cloud) をご確認ください。
２．アカウント要求
アカウント要求を実行することにより、ドメイン認証済みのメールアドレスに紐づくアカウントが組織の「管理対象アカウント」となります。
例えば、「example.com」でドメイン認証した場合、@example.com のメールアドレスを持つ全てのユーザが「管理対象アカウント」となります。これにより、以下の影響があります。
管理対象アカウント
各ユーザは、ユーザプロファイル設定画面から、自身のメールアドレスを変更したりアカウントを削除したりできなくなります。
※2段階認証（任意）は設定できます。組織管理者
管理対象アカウントのプロファイル変更やアカウントの有効・無効・削除などのコントロールができるようになります。
管理対象アカウントにはデフォルトの認証ポリシーが適用されますが、初期値は既存ユーザーに影響を与えない設定となっています。
デフォルトの認証ポリシーの初期設定は、Atlassian Cloud 標準の認証方式 (Basic 認証) と同じ
デフォルトの認証ポリシーが適用されても、この段階では各ユーザーが個別に設定した２段階認証（任意）は有効のままになる
３．Atlassian Access サブスクライブ
Atlassian Access のサブスクライブのみであれば、ユーザーには影響はありません。
Atlassian Access の機能詳細は、Atlassian Access 概要 をご確認ください。
４．ID プロバイダー統合（シングルサインオン）
シングルサインオンの設定をしても、デフォルトの認証ポリシー（Basic 認証）を変更していなければ、既存ユーザーに影響はありません。
シングルサインオンの設定については、Atlassian Access の ID プロバイダー連携によるユーザー管理 (Atlassian Cloud) > SAML シングル サインオンを構成する をご確認ください。
５．認証ポリシーの設定
認証ポリシー設定で、デフォルトポリシーを変更した場合、管理対象アカウントに対して、指定したログイン認証方式が強制されます。
例えば、認証ポリシーの設定で、シングル・サインオンを ON にした場合、ユーザが Atlassian Cloud のログイン画面からアカウント情報を入力すると ID プロバイダーの認証画面にリダイレクトされ、シングルサインオンによるログインを強制されます。
認証ポリシーの設定については、STEP2. 認証ポリシーに SAML シングル サインオン を適用する をご確認ください。
Atlassian Access は管理対象アカウントに対するセキュリティ系機能を提供するサービスですので、自身が管理している組織配下の製品以外の環境にも、設定したポリシーが適用されます。
６．ID プロバイダー統合（ユーザプロビジョニング）
ユーザプロビジョニングでは、ID プロバイダーに登録されたグループとグループ内のユーザーを、Atlassian Cloud の組織のユーザディレクトリに同期できます。（Jira や Confluence のグループ所属ユーザーが ID プロバイダーの設定に上書きされます）
プロビジョニングで同期されたアカウントは、ID プロバイダー側でしかアカウントのプロファイルの変更や有効・無効・削除が実行できなくなります。
また、Jira、Confluence は、グループに対してライセンスや権限を紐付けるようになっているため、既存のグループに対してプロビジョニングを実行すると、グループに所属しているユーザーが ID プロバイダーの設定で上書きされ、以下のような影響が出る可能性があります。
意図しないライセンスの付与・剥奪
意図しない権限設定の変更（スペースやプロジェクトの閲覧や編集権限など）
ユーザプロビジョニングを実行する前に、対象となる製品（Confluence、Jira）の既存グループの設定と利用状況を確認して、どのようにグループ同期を設定するか検討が必要です。
ユーザープロビジョニングの設定については、 ユーザー プロビジョニングを構成する をご確認ください。