Atlassian Access とクラウド IdP が必要かどうかを確認する

現在サーバーにあるものと同様のユーザー管理設定を実現できます。ただし、Jira や Confluence の内部ディレクトリ以外を使用している場合、ほとんどのケースで次の追加製品が必要になります。

• クラウド ID プロバイダー

• Atlassian Access のサブスクリプション

これは、外部ディレクトリを Atlassian Cloud に直接連携できないためです。外部ディレクトリと Atlassian Cloud の間にはクラウド ID プロバイダーが必要です。ほとんどの場合、連携には Atlassian Access のサブスクリプションが必要です。

連携の仕組みは以下のとおりです。

例外は、 Atlassian Access なしで一部のユーザー プロビジョニングとシングル サインオン機能を提供するカスタム統合 (Google Workspace、ネストされたグループの場合は Azure AD) です。

現在のユーザー管理設定を比較する

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 Access かクラウド IdP は必要ですか?

いいえ、Atlassian Access またはクラウド IdP は必要ありません。

LDAP 認証を使用した内部ディレクトリ

この設定は、中央ディレクトリに対してのみユーザーを認証する場合に使用されます。

Server / Data Center での仕組み

それぞれの Server または Data Center 製品は外部の LDAP ディレクトリに接続され、そのディレクトリはログイン時のユーザー パスワード認証にのみ使用されます。

• ユーザーは、LDAP ディレクトリに保存されたユーザー名とパスワードでログインします。

• 管理者は、製品内のユーザーを手動で追加および削除します。

• 管理者はグループを作成して、製品内の製品アクセス権を手動で管理します。

Cloud への移行後の仕組み

組織の管理者は、認証が一元的に管理されるように、SAML シングル サインオンを設定できます。

• ユーザーは ID プロバイダー (SAML シングル サインオン) 経由でログインします。

• 管理者は admin.atlassian.com でユーザーを追加および削除します。

• 管理者はグループを作成して、admin.atlassian.com で製品アクセス権を管理します。

Atlassian Access かクラウド IdP は必要ですか?

はい。Atlassian Access とご自身の ID プロバイダーが必要です。

外部ユーザー ディレクトリまたは Atlassian Crowd

この設定は、ユーザーの詳細と製品アクセス権を中央ディレクトリで管理する場合に使用されます。

Server / Data Center での仕組み

それぞれの Server または Data Center 製品は外部の LDAP または Crowd ディレクトリに接続され、そのディレクトリが同期されてユーザーの詳細とグループ メンバーシップが入力されます。このアプローチにはさまざまなバリエーションがあります。

• ユーザーは、LDAP または Crowd ディレクトリに保存されたユーザー名とパスワードでログインします。

• 管理者は、外部の LDAP または Crowd ディレクトリでユーザーを追加および削除します。

• 管理者はグループを作成して、外部の LDAP または Crowd ディレクトリで製品アクセス権を管理します。

Cloud への移行後の仕組み

組織の管理者は、認証が一元的に管理されるように SAML シングル サインオンを設定したり、SCIM ユーザー プロビジョニングを設定してアカウントの作成とグループ メンバーシップの管理をしたりすることが可能です。

• ユーザーは ID プロバイダー (SAML シングル サインオン) 経由でログインします。

• 管理者は ID プロバイダーでユーザーを追加および削除します。

• 管理者はグループを作成して、ID プロバイダーのプロセス アクセス権を管理します。

ID プロバイダーのディレクトリは、プロバイダーがサポートしている場合、LDAP ディレクトリから入力できます。

Atlassian Access かクラウド IdP は必要ですか?

はい。Atlassian Access とご自身の ID プロバイダーが必要です。SCIM ユーザー・プロビジョニングは、特定の ID プロバイダーでのみサポートされています。

SAML 認証

この設定は、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 Access かクラウド IdP は必要ですか?

はい。Atlassian Access とご自身の ID プロバイダーが必要です。SCIM ユーザー・プロビジョニングは、特定の ID プロバイダーでのみサポートされています。

OpenID Connect 認証

この設定は、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 のユーザー プロビジョニングと認証

この設定は、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 Access は必要ですか?

いいえ、Google Workspace のすべてのユーザーを「Google Workspace のすべてのユーザー」という単一のグループに同期するのに、Atlassian Access は不要です。ただし、グループ・メンバーシップを同期したり、ユーザーに対して Google でのログインを必須にしたりするには、Atlassian Access が必要です。

関連ページ

Atlassian Cloud へのユーザーの移行を開始する