2 回答
- 543
１.ドメイン認証
ユーザへの影響は一切ありません。
ドメイン認証が完了すると続けてアカウント要求の確認ダイアログが表示されます。
ドメイン認証とアカウント要求のタイミングを分けたい場合は、ここではアカウント要求を実行せずに、タイミングを分けてアカウント要求を実行できます。
２.アカウント要求
アカウント要求を実行することにより、ドメイン認証済みのメールアドレスに紐づくアカウントが組織の「管理対象アカウント」となります。
例えば、「rickma.com」でドメイン認証した場合、@rickma.comのメールアドレスを持つ全てのユーザが「管理対象アカウント」となります。
これにより、以下の影響があります。- 管理対象アカウント
各ユーザは、ユーザプロアファイル設定画面から、自身のメールアドレスを変更したりアカウントを削除したりできなくなります。
2段階認証（任意）は設定できます。 - 組織管理者
管理対象アカウントのプロファイル変更やアカウントの有効・無効・削除などのコントロールが実行ができるようになります。
【補足】
管理対象アカウントにはデフォルトの認証ポリシーが適用されますが、初期値は既存ユーザに影響を与えない設定となっています。- デフォルトの認証ポリシーの初期設定は、AtlassianCloud標準の認証方式と同じ（BASIC認証）
- デフォルトの認証ポリシーが適用されてもこの段階ではユーザが個別に設定した２段階認証（任意）は有効
３.IDプロバイダー統合（シングルサインオン）
シングルサインオンの設定をしても、デフォルトの認証ポリシーを変更していなければ、既存ユーザに影響はありません。
４.認証ポリシーの設定
認証ポリシー設定で、デフォルトポリシーを変更した場合、管理対象アカウントに対して、指定したログイン認証方式が強制されます。
例えば、認証ポリシーの設定で、シングル・サインオンをONにした場合、ユーザがAtlassianのログイン画面からアカウント情報を入力するとIDプロバイダーの認証画面にリダイレクトされ、シングル・サインオンによるログインを強制されます。
参考：複数の認証ポリシーの適用
５.IDプロバイダー統合（ユーザプロビジョニング）
ユーザプロビジョニングでは、IDプロバイダーに登録されたグループとグループ内のユーザを組織のユーザディレクトリに同期できます。（JiraやConfluenceのグループ内のユーザがIDプロバイダーの設定で上書きされます）
プロビジョニングで同期されたアカウントは、IDプロバイダー側でしかアカウントのプロファイルの変更や有効・無効・削除が実行できなくなります。
また、Jira、Confluenceは、グループに対してライセンスや権限を紐付けるようになっているため、既存のグループに対してプロビジョニングを実行すると、グループ内のユーザがIDプロバイダーの設定で上書きされ、以下のような影響が出る可能性があります。- 意図しないライセンスの付与・剥奪
- 意図しない権限設定の変更（スペースやプロジェクトの閲覧や編集権限など）
【補足】
ユーザプロビジョニングを実行する前に対象となる製品（Confluence、Jira）の既存グループの設定と利用状況を確認して、どのようにグループ同期を設定するか検討が必要です。コメントを追加... - 管理対象アカウント
- 10-1
以下の処理の影響を書き漏らしていました…
3. Atlassian Access サブスクライブ
Atlassian Accessのサブスクライブしただけであれば、ユーザには特に影響はありません。
意図的に設定を変更しない限り大丈夫。コメントを追加...
Atlassian CloudでIDプロバイダー統合する場合、以下のステップを踏みますが、各ステップで製品の利用ユーザにどのような影響を与えるか知りたいです。