私の組織には Atlassian Access が必要ですか?

Atlassian Access は、アトラシアンのクラウド製品を ID プロバイダーに接続する組織全体のサブスクリプションです。エンタープライズ グレードの認証と追加のセキュリティ オプションを提供し、企業ドメイン全体を監視します。Atlassian Access の機能と価格に関する詳細をご確認ください。

次のような場合は、Atlassian Access サブスクリプションとサードパーティ ID プロバイダー (IdP とも呼ばれる) が必要です。

• ユーザーにシングル サインオンを提供する

• SCIM ユーザー プロビジョニングを使用して、ユーザー アカウントを自動的に作成および管理する

外部のユーザー ディレクトリ (Microsoft Active Directory や Atlassian Crowd など) をアトラシアン製品に直接接続することはありません。代わりに、クラウドベースの ID プロバイダーを接続します。ID プロバイダーによってサポートされていれば、既存の外部ディレクトリからデータを入力できる場合があります。

このページは、シングル サインオンとユーザー プロビジョニングの要件を満たすために Atlassian Access サブスクリプションが必要かどうかを判断するのに役立ちます。Atlassian Access が提供するものは認証だけでありません。データ セキュリティとガバナンスの機能もご覧ください。Atlassian Access の詳細をご確認ください。

ID プロバイダーについて

Atlassian Access の機能の多くには、ID プロバイダーとの接続が必要です。任意の ID プロバイダーを使用できますが、一部の機能は特定の ID プロバイダーでのみ使用できます。

アトラシアンがサポートする ID プロバイダーをご確認ください。

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

Atlassian Access が必要かどうかを判断しやすくするために、Server と Data Center の最も一般的なユーザー ディレクトリと認証の設定を要約し、Cloud で同様の結果を得る方法を説明しています。

内部ディレクトリのみ

この設定は主に、外部ユーザー管理が不要な小規模のインスタンスに使用されます。Jira または Confluence の内部ユーザー ディレクトリのみを使用し、外部ディレクトリは使用しません。

Server / Data Center での仕組み

ユーザーの詳細はすべて、製品の内部ディレクトリで作成、管理、保存されます。

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

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

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

Cloud への移行後の仕組み

Atlassian Cloud でも同様の設定を行うことができます。

• ユーザーはメール アドレスとパスワードで自分の Atlassian アカウントにログインします。

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

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

Atlassian Access は必要ですか?

いいえ、Atlassian Access は不要です。

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

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

Server / Data Center での仕組み

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

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

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

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

Cloud への移行後の仕組み

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

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

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

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

Atlassian Access は必要ですか?

はい。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 は必要ですか?

はい。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 は必要ですか?

はい。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 が必要です。

詳細情報とサポート

移行をサポートするための多数のチャンネルをご用意しています。

• 移行計画の詳細については、アトラシアン移行プログラムの Web サイトをご参照ください。

• 技術的な問題や、戦略やベスト プラクティスによるサポートについては、サポート チームにお問い合わせください。

• 専門的なアドバイスについては「アトラシアン コミュニティ」をご参照ください。

• 専門家によるサポートが必要な場合は、アトラシアン パートナーにご相談ください。