Atlassian Cloud でのユーザー管理の仕組み

User management in Atlassian Cloud is different from what you know from Server or Data Center. The main difference is that it’s separated from cloud apps, like Jira or Confluence. If you used Crowd, it would be the closest comparison. This page explains the main concepts of how you’ll manage users in cloud.


集中型のユーザー管理

In cloud, users are managed from a central location called admin.atlassian.com, available under the same URL. This is a platform shared by Atlassian cloud apps where you manage, for example:

  • ユーザーとグループ

  • Access to apps

  • ユーザー プロビジョニングとシングル サインオン

  • Apps, subscriptions, billing

admin.atlassian.com のユーザー ビュー

When you deploy a cloud app, you always get access to your own admin.atlassian.com. It can only be accessed by organization admins who are a rank higher than Jira or Confluence admins, though they’re really just a different type. Think system admins, though we don’t have system admins in cloud.

組織

The admin.atlassian.com platform is divided into organizations – you can have one or more if you prefer to keep things more separated. Every organization has a separate user base, including individual app access, user provisioning configuration, and so on. When accessing the platform, you always choose which org you want to view.

組織がアトラシアン環境にどのように適合するかを示す図

Organizations are further divided into sites that hold app, like Jira and Confluence. All sites (and app) within one organization share the same user base and configuration. You can have many sites, and many apps, within one org.

組織の詳細を確認する

Server または Data Center のユーザー管理エリア

Server や Data Center にあるユーザー管理エリアは、クラウドには存在しません。Server では、組み込み Crowd (Jira と Confluence に組み込んだ一連のライブラリ) に基づいてユーザーを管理します。クラウドでは利用できません。また、このエリアにアクセスすることはできません。すべてを admin.atlassian.com に移行しました。 良い点を挙げるとすれば、少し見やすくなりました。

Jira Data Center のユーザー ビュー

App access

App access is the first layer of access that controls whether users can even open a specific app. You grant it from admin.atlassian.com together with an additional role (Admin, User, Customer) to groups or individual users. Once it’s granted, all users with app access start counting towards your cloud subscription. This works in the same way as application access in server.

グループの製品アクセス設定

We migrate your app access from server, but we won’t apply it to groups until you confirm it after the migration, because it affects billing.

Learn more about app access in cloud

No app access

Users without any app access still exist and can log in to Atlassian Cloud. But, they won’t be able to do much apart from changing their preferences or uploading an avatar. They won’t count towards your cloud subscription.


権限

Permissions are the second layer of access, and allow you to give your users more granular permissions than just access to app – for example, permission to view secret projects or spaces. They work in the same was as in server – they’re managed on the app level, and not from admin.atlassian.com. That’s because they’re really more on the data protection side rather than user management.

Jira Cloud からの権限の割り当て

Permissions depend on your app, like in server. In Jira, you’d have project roles, permission schemes, and more granular permissions. In Confluence, that’s space permissions, with additional restrictions on pages. We’ll migrate your roles, schemes, permissions, or restrictions when you migrate projects or spaces (with the exception of most global permissions).

ロールと権限の詳細を確認する


Atlassian Guard Standard のサブスクリプション

Atlassian Guard Standard, although seen as a separate app, is really an expansion for admin.atlassian.com. It’s an additional subscription that enables such features as:

  • SCIM ユーザー プロビジョニング

  • SAML シングル サインオン

  • データ セキュリティ ポリシー

  • 組織監査ログ

Atlassian Guard Standard をサブスクライブしても、ユーザーの管理は引き続き admin.atlassian.com から行いますが、表示されるタブ、オプション、機能が増えています。外部ディレクトリ (Google Workspace 以外) のユーザーを同期する際は、多くの場合、Atlassian Guard Standard が必要になります。

admin.atlassian.com のページ例を示します。これは、Atlassian Guard Standard サブスクリプションでのみ利用可能なページであり、同じアトラシアンの管理エリアです。

Sample page that is available with Atlassian Guard subscription

Atlassian Guard について


Atlassian Cloud アカウント

Atlassian Cloud では、ユーザーはメール アドレスによって識別されます。そのため、すべてのメールが有効かつ一意でなければなりません。サーバーでは、ユーザー名によって識別されていました。そのため、メールの見逃しや無効なメールにより、多くの人がユーザー移行に関する問題を抱えています。作成、招待、プロビジョニング、または移行するすべてのユーザーは、メール アドレスに基づいて Atlassian Cloud アカウントを取得します。

Access to multiple apps

When users are granted access to multiple apps, they’ll access them through their single Atlassian Cloud account. In server, they would have separate users in each instance.

When you migrate users from multiple Data Center instances (Jira, Confluence), we’ll match them by their email address and link all of their references (mentions, comments, and so on) to their single Atlassian Cloud account.

アカウントと管理対象アカウント

Individual users own their accounts by default. You still control app access, but you can’t modify the account itself. If you want more control, you can verify that you own the domain (@atlassian.com) and claim all accounts from this domain. This transfers ownership of the account to the organization that verified the domain, and the accounts become managed accounts. They’re the same accounts, you just have more control. Atlassian Guard Standard specific features can be used only for managed accounts.

メールでログイン

ユーザーにとってのログイン時の主な違いの 1 つが、サーバーへのログイン時とは異なり、ユーザー名ではなくメール アドレスを使用してログインする点です。

  • クラウドでシングル サインオンを使用している場合、ユーザーはシングル サインオンでログインし、同じパスワードを使用します。

  • シングル サインオンを使用しない場合、ユーザーは「パスワードを忘れた場合」を選択し、新しいパスワードを入力する必要があります。パスワードは移行されません。

  • アバターは移行されないため、ユーザーは新しいアバターをアップロードする必要があります。


ユーザー プロビジョニングと認証

ユーザーを管理したり、外部ディレクトリからクラウドに同期することはできますが、追加要件があります。

クラウド ID プロバイダー

外部ディレクトリを admin.atlassian.com に直接接続することはできません。間にクラウド ID プロバイダーが必要です。持っていない場合は、移行に最適な IdP のリストをこのガイドで見つけてください。また、Okta と提携して、無料アカウントを設定することもできます。

Atlassian Guard Standard のサブスクリプション

You’ll need a subscription for Atlassian Guard Standard to enable SCIM user provisioning and SAML single sign-on. If you use Google Workspace, you can use our integration for user provisioning that doesn’t require Atlassian Guard Standard, but has limited functionality without this subscription.

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

図: シングル サインオンとプロビジョニングのために ID プロバイダーを Atlassian Access に接続する

ユーザー プロビジョニングや認証はなし

ユーザー プロビジョニングを設定しない場合は、Jira や Confluence の内部ディレクトリのように、admin.atlassian.com でユーザーを作成およびアップデートできます。シングル サインオンを設定しない場合、ユーザーはメール アドレスとパスワードを使用してログインします。パスワードは移行されないため、移行後にリセットする必要があります。


他にもいくつかの相違点や知っておくべき情報があります。

入れ子グループ

Atlassian Cloud は入れ子グループをサポートしません。引き続き外部ディレクトリ内で入れ子グループを持つことはできますが、クラウドと同期するときに入れ子グループをフラット化する必要があります。admin.atlassian.com で、それらは常に同じレベルに表示されます。ほとんどのクラウド ID プロバイダーはフラット化をサポートしています。当社はさらに、Google Workspace や Microsoft Azure AD から同期するときにグループをフラット化するカスタム統合も構築しました。

重複するグループ名

All groups are managed from a single location, so you can’t have multiple groups with the same name. When you try to migrate a group whose copy already exists, we’ll migrate its users, but not the group itself. This is important if you’re migrating from both Jira and Confluence. If each of these Data Center instances had a group admins with a different set of users, after migration all of these users would belong to a single admins group, with access coming from the group that was migrated first. Permission escalation at its finest. This guide will tell you more about that.

Crowd Server または Data Center

Crowd doesn’t have an equivalent cloud app, although admin.atlassian.com works in a similar way. If you’d like to continue managing users in Crowd, you can connect it to a cloud identity provider, and then connect the provider to admin.atlassian.com.


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

さらにヘルプが必要ですか?

アトラシアン コミュニティをご利用ください。