Cloud 移行を計画する
Atlassian Server または Data Center 製品の移行準備に役立つドキュメント。
現在サーバーにあるものと同様のユーザー管理設定を実現できます。ただし、Jira や Confluence の内部ディレクトリ以外を使用している場合、ほとんどのケースで次の追加製品が必要になります。
クラウド ID プロバイダー
Atlassian Guard Standard (旧 Atlassian Access) のサブスクリプション
これは、外部ディレクトリを Atlassian Cloud に直接接続することはできず、クラウド ID プロバイダーを介す必要があるためです。ほとんどの場合、接続には Atlassian Guard Standard のサブスクリプションが必要です。
連携の仕組みは以下のとおりです。
例外があり、カスタム統合 (Google Workspace、入れ子グループ向けの Azure AD) では、Atlassian Guard Standard がなくても一部のユーザー プロビジョニングとシングル サインオン機能を利用できます。
Server または Data Center で最も一般的なユーザー ディレクトリと認証設定、およびクラウドで同様の結果を得るために必要な項目は以下のとおりです。
内部ディレクトリのみ
LDAP 認証を使用した内部ディレクトリ
外部ユーザー ディレクトリまたは Atlassian Crowd
SAML 認証
OpenID 認証
Google Workspace のユーザー プロビジョニングと認証
この設定は主に、外部ユーザー管理が不要な小規模のインスタンスに使用されます。Jira または Confluence の内部ユーザー ディレクトリのみを使用し、外部ディレクトリは使用しません。
Server / Data Center での仕組み
ユーザーの詳細はすべて、製品の内部ディレクトリで作成、管理、保存されます。
ユーザーは、その製品の内部ディレクトリに保存されたユーザー名とパスワードでログインします。
管理者は、製品内のユーザーを手動で追加および削除します。
管理者はグループを作成して、製品内の製品アクセス権を手動で管理します。
Cloud への移行後の仕組み
Atlassian Cloud でも同様の設定を行うことができます。
ユーザーはメール アドレスとパスワードで自分の Atlassian アカウントにログインします。
管理者は admin.atlassian.com でユーザーを追加および削除します。
管理者はグループを作成して、admin.atlassian.com で製品アクセス権を管理します。
Atlassian Guard Standard またはクラウド IdP が必要か
いいえ、Atlassian Guard Standard またはクラウド IdP は必要ありません。
この設定は、中央ディレクトリに対してのみユーザーを認証する場合に使用されます。
Server / Data Center での仕組み
それぞれの Server または Data Center 製品は外部の LDAP ディレクトリに接続され、そのディレクトリはログイン時のユーザー パスワード認証にのみ使用されます。
ユーザーは、LDAP ディレクトリに保存されたユーザー名とパスワードでログインします。
管理者は、製品内のユーザーを手動で追加および削除します。
管理者はグループを作成して、製品内の製品アクセス権を手動で管理します。
Cloud への移行後の仕組み
組織の管理者は、認証が一元的に管理されるように、SAML シングル サインオンを設定できます。
ユーザーは ID プロバイダー (SAML シングル サインオン) 経由でログインします。
管理者は admin.atlassian.com でユーザーを追加および削除します。
管理者はグループを作成して、admin.atlassian.com で製品アクセス権を管理します。
Atlassian Guard Standard またはクラウド IdP が必要か
はい。Atlassian Guard Standard と各自の ID プロバイダーが必要です。
この設定は、ユーザーの詳細と製品アクセス権を中央ディレクトリで管理する場合に使用されます。
Server / Data Center での仕組み
それぞれの Server または Data Center 製品は外部の LDAP または Crowd ディレクトリに接続され、そのディレクトリが同期されてユーザーの詳細とグループ メンバーシップが入力されます。このアプローチにはさまざまなバリエーションがあります。
ユーザーは、LDAP または Crowd ディレクトリに保存されたユーザー名とパスワードでログインします。
管理者は、外部の LDAP または Crowd ディレクトリでユーザーを追加および削除します。
管理者はグループを作成して、外部の LDAP または Crowd ディレクトリで製品アクセス権を管理します。
Cloud への移行後の仕組み
組織の管理者は、認証が一元的に管理されるように SAML シングル サインオンを設定したり、SCIM ユーザー プロビジョニングを設定してアカウントの作成とグループ メンバーシップの管理をしたりすることが可能です。
ユーザーは ID プロバイダー (SAML シングル サインオン) 経由でログインします。
管理者は ID プロバイダーでユーザーを追加および削除します。
管理者はグループを作成して、ID プロバイダーのプロセス アクセス権を管理します。
ID プロバイダーのディレクトリは、プロバイダーがサポートしている場合、LDAP ディレクトリから入力できます。
Atlassian Guard Standard またはクラウド IdP が必要か
はい。Atlassian Guard Standard と各自の ID プロバイダーが必要です。SCIM ユーザー プロビジョニングは、特定の ID プロバイダーでのみサポートされています。
この設定は、SAML シングル サインオンを使用して ID プロバイダーに対してユーザーを認証する場合に使用されます。
Server / Data Center での仕組み
ID プロバイダーまたは Crowd Data Center は、ご使用の Data Center 製品で SAML シングル サインオン認証用に設定されています。一般的には、製品を外部の LDAP または Crowd ディレクトリにも接続してユーザーやグループ メンバーシップを入力するか、ジャスト イン タイム (JIT) プロビジョニングが有効になっているかのどちらかです。
ユーザーは ID プロバイダー (SAML シングル サインオン) 経由でログインします。
管理者は、外部の LDAP ディレクトリ、Crowd、または ID プロバイダーでユーザーを追加および削除します。
管理者はグループを作成して、外部の LDAP ディレクトリ、Crowd、または ID プロバイダーで製品アクセス権を管理します。
Cloud への移行後の仕組み
組織の管理者は、認証が一元的に管理されるように SAML シングル サインオンを設定したり、SCIM ユーザー プロビジョニングを設定してアカウントの作成とグループ メンバーシップの管理をしたりすることが可能です。
ユーザーは ID プロバイダー (SAML シングル サインオン) 経由でログインします。
管理者は ID プロバイダーでユーザーを追加および削除します。
管理者はグループを作成して、ID プロバイダーの製品アクセス権を管理します。
ID プロバイダーのディレクトリは、プロバイダーがサポートしている場合、LDAP ディレクトリから入力できます。
Atlassian Guard Standard またはクラウド IdP が必要か
はい。Atlassian Guard Standard と各自の ID プロバイダーが必要です。SCIM ユーザー プロビジョニングは、特定の ID プロバイダーでのみサポートされています。
この設定は、OpenID Connect シングル サインオンを使用して ID プロバイダーに対してユーザーを認証する場合に使用されます。
Server / Data Center での仕組み
ID プロバイダーは、ご使用の Data Center 製品で OpenID Connect シングル サインオン認証用に設定されています。一般的には、製品を外部の LDAP または Crowd ディレクトリにも接続してユーザーやグループ メンバーシップを入力するか、ジャスト イン タイム (JIT) プロビジョニングが有効になっているかのどちらかです。
ユーザーは ID プロバイダー経由でログインします (OpenID Connect シングル サインオン)。
管理者は、外部の LDAP または Crowd ディレクトリでユーザーを追加および削除します。
管理者はグループを作成して、外部の LDAP または Crowd ディレクトリで製品アクセス権を管理します。
Cloud への移行後の仕組み
現在、OpenID Connect は認証方法としてサポートされていません。SAML 2.0 をサポートする ID プロバイダーを使用する必要があります。
この設定は、Google Workspace (以前の G Suite) を使用してユーザーを認証する場合に使用されます。
Server / Data Center での仕組み
Server と Data Center の各製品に、Google Workspace と接続する機能はありません。利用できるサードパーティ統合がいくつかありました。
Cloud への移行後の仕組み
Google Workspace のドメインとそれらのドメインのユーザーを Atlassian Cloud に同期できます。これにより、メール ドメインのすべてのユーザーが Google アカウントでアトラシアン製品にログインできるようになります。ユーザーは初回ログイン時に既定のグループに追加されます。Google Workspace への連携方法についてはこちらをご確認ください。
ユーザーは自分の Google アカウントを使用するログインを選択できます。
管理者は Google Workspace の管理コンソールでユーザーを追加および削除します。
管理者はグループを作成して、admin.atlassian.com で製品アクセス権を管理します。
Atlassian Guard Standard が必要か
いいえ、Google Workspace のすべてのユーザーを「Google Workspace のすべてのユーザー」という単一のグループに同期するのに、Atlassian Guard Standard は不要です。ただし、グループ メンバーシップを同期したり、ユーザーに対して Google でのログインを必須にしたりするには、Atlassian Guard Standard が必要です。
Atlassian Cloud へのユーザーの移行を開始する
この内容はお役に立ちましたか?