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
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 に移行しました。 良い点を挙げるとすれば、少し見やすくなりました。
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.
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 サブスクリプションでのみ利用可能なページであり、同じアトラシアンの管理エリアです。
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.
連携の仕組みは以下のとおりです。
ユーザー プロビジョニングや認証はなし
ユーザー プロビジョニングを設定しない場合は、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.
関連ページ
この内容はお役に立ちましたか?