Jira Service Management でカスタマーのアカウントに Atlassian Access の SAML シングル サインオンとユーザー プロビジョニングを構成する
プラットフォームについて: Cloud のみ - この記事は、 クラウド プラットフォームのアトラシアン製品にのみ適用されます。
目的
Atlassian Access をサブスクライブした組織管理者が、内部のカスタマー/ユーザーに SAML シングル サインオンを通じた認証を行わせたり、Jira Service Management Cloud のサイト内にカスタマーのアカウントをプロビジョニングしたりしたい場合があります。
Jira Service Management には 2 つのタイプのカスタマー アカウントがあります。
- ポータル専用カスタマー
- これらは厳密にクライアントと見なされ、ポータルの URL (https://<インスタンス>.atlassian.net/servicedesk/customer/) 経由でメール アドレスとローカルのパスワードを使用したログインのみを行えます
- ポータル専用アカウントは、Atlassian アカウントのカスタマー アカウントに移行され、クラウド サイトのライセンスを消費しないようにすべての製品アクセスを取り除かれている場合 (後述) を除き、ログインに SAML シングル サインオンを使用できません
- Atlassian アカウントのカスタマー
- これらは将来ライセンス アクセスを提供する可能性があるカスタマーです
- これらのお客様は標準ユーザーと同じようにクラウド サイトに追加されますが、製品アクセスは持たず、サービス管理プロジェクトへの権限が付与されます
- これらのカスタマーは (標準ユーザーと同様)、https://<インスタンス>.atlassian.net/ でログインすることで認証に SAML シングル サインオンを使用できます。
- Atlassian アカウントのカスタマーがカスタマー ポータルからログインしようとした場合、Atlassian ID のログイン画面 (https://id.atlassian.com) 経由でのログインを行うように促されます。
- Atlassian アカウントのカスタマーはユーザー プロビジョニングで作成できます
ソリューション
クラウド サイトでカスタマーをジャストインタイムで作成できるようにし、認証に SAML シングル サインオンを使用する
これは、Atlassian Access をサブスクライブ済みで前提条件を完了しており、SAML シングル サインオンが構成済みであることを前提に書かれています。
- クラウド サイトのユーザー管理画面に移動し、製品アクセス設定を更新して、[新しいユーザーはこの製品にアクセスできます] オプションを無効化します
- これにより、クラウド サイトにセルフ サインアップしたアカウントがライセンスを自動的に消費せず、カスタマー アカウントとして扱われるようにすることができます
- 新しいユーザーに製品アクセスが必要な場合、サイト管理者がそのユーザーに対して製品を有効化したり、適切なグループに追加したりする必要があります
- サイト アクセス設定に移動し、招待なしで参加することを許可するドメインを追加します
- Jira Service Management のカスタマー権限設定を確認し、カスタマーがプロジェクトにアクセスできるかどうかを検証します
- エージェントと管理者が追加したカスタマーにサービス プロジェクトへのアクセスを許可するように Jira Service Management プロジェクトが構成されている場合
- エージェントまたは管理者がカスタマーを対象のプロジェクトに追加する必要があります
- Jira Service Management プロジェクトで変更済みのプロジェクト権限スキームを使用している場合、アクセスを付与するには追加のプロジェクト権限を管理する必要がある場合があります
- エージェントまたは管理者がカスタマーを対象のプロジェクトに追加する必要があります
- Jira Service Management プロジェクトが https://<インスタンス>.atlassian.net にアカウントを持つ全員またはWeb 上の全ユーザーと構成されている場合
- 追加の変更は不要です。カスタマーは対象のプロジェクトへのアクセスを持ち、カスタマーはクラウド サイトでアカウントを持ちます
- このオプションのテキストは、Jira Service Management のグローバル カスタマー権限に応じて変わります。
- エージェントと管理者が追加したカスタマーにサービス プロジェクトへのアクセスを許可するように Jira Service Management プロジェクトが構成されている場合
- これらの設定を行ったあとは、認証済みかつ承認済みのドメインに所属する新しいカスタマーは、クラウド サイトのベース URL (https://<インスタンス>.atlassian.net) に移動してアカウントをジャストインタイムでプロビジョニングする必要があります。ログイン エクスペリエンスは次のようになります
- ユーザーは https://<インスタンス>.atlassian.net にナビゲートし、Atlassian ID のログイン画面にリダイレクトされます
- ユーザーがメール アドレスを入力して青色の続行ボタンをクリックすると、アイデンティティ プロバイダーにリダイレクトされます
- ユーザーが IdP への認証に成功したら (あるいはセッションがキャッシュされていたら)、ログインを開始したアトラシアンの Web サイトに戻されます
ヘルプ センターの [Jira 設定] > [製品] > [顧客アクセス] で [外部] アカウント タイプに [顧客にアカウントの作成を許可する] が選択されている場合、そのヘルプ センターを経由する新規顧客は、SAML シングル サインオン認証を利用しないポータル専用アカウントを作成できます。顧客に SAML シングル サインオンを利用させるには、このポータル専用アカウントを Atlassian アカウント顧客に移行する必要があります。
Atlassian Access のユーザー プロビジョニング経由でカスタマー アカウントを作成する
これは、Atlassian Access をサブスクライブ済みで前提条件を完了しており、SAML シングル サインオンとユーザー プロビジョニングが構成済みであることを前提に書かれています。
ご利用のアイデンティティ プロバイダーから "カスタマー" グループをアトラシアン製品にプッシュすることをおすすめします。これは、ユーザーがクラウド サイトにプッシュされたあとに、ライセンスが付与された Jira/Confluence ユーザーとライセンスが付与されないカスタマーを区別するのに役立ちます。また、Jira Service Management プロジェクト内でカスタマーにアクセスを付与するために権限を更新する際にも便利です。
既定では、ユーザー プロビジョニング経由でクラウド サイトにプッシュされたグループは製品アクセスを持ちません。カスタマーがライセンスを付与されない "カスタマー" グループ (Jira または Confluence の製品アクセスが付与されないグループ) にのみ所属している限り、クラウド サイトでは無料のカスタマー アカウントになります。
アイデンティティ プロバイダーでグループとメンバーをクラウド サイトにプッシュしたら、Jira Service Management プロジェクトのカスタマー権限を確認します。
エージェントと管理者が追加したカスタマーにサービス プロジェクトへのアクセスを許可するように Jira Service Management プロジェクトが構成されている場合
プロジェクトのユーザー/ロール設定を更新して、プッシュしたグループ (例: "カスタマー") のメンバーがプロジェクトにカスタマーとしてアクセスできるようにします
- Jira Service Management プロジェクトで変更済みのプロジェクト権限スキームを使用している場合、アクセスを付与するには追加のプロジェクト権限を管理する必要がある場合があります
Jira Service Management プロジェクトが https://<インスタンス>.atlassian.net にアカウントを持つ全員または Web 上の全ユーザーと構成されている場合
追加の変更は不要です。カスタマーの Atlassian アカウントはユーザー プロビジョニング経由でクラウド サイト内に作成されているため、カスタマーはプロジェクトへのアクセス権を持ちます
このオプションのテキストは、Jira Service Management のグローバル カスタマー権限グローバル カスタマー権限 に応じて変わります
JSM のエッジケース シナリオ
Jira Service Management (JSM) では、2 つの組織間のシングル サインオン (SSO) 設定に関する特定のエッジケース シナリオがあります。以下は想定される挙動です。
シナリオ: 組織 A と組織 B の 2 つの組織を想定します。
組織 A:
SSO が設定されている
JSM の SSO は設定されていない
外部/非管理対象ユーザーのポータルへのログインを許可する
組織 B:
SSO が設定されている
想定される挙動: ユーザーのアカウントがカスタマー アカウントから Atlassian アカウントに変更された場合、ユーザーは組織 B の SSO を使用してログインする必要があります。ユーザーは現在、組織 B によって管理されている Atlassian アカウントに属しているため、これは想定される挙動です。
一方、ユーザーが組織 A のカスタマー アカウントのままであれば、SSO 経由でログインする必要はありません。代わりに、組織 A が提供するローカルの認証方法を使用できます。
つまり、組織 A のアカウント タイプによっては、組織 B のユーザーは SSO を使用してログインするか、ローカルの認証方法を使用する必要があります。
分析: このエッジケースのシナリオでは、組織 A のユーザー アカウントのタイプが、組織 B のユーザーに必要なログイン方法に直接影響します。どちらの組織でも SSO が設定されていますが、組織 B のユーザーはログインに SSO を使用する必要があるとは限りません。SSO またはローカル認証の必要性は、組織 B のユーザーが組織 A のカスタマー アカウントと Atlassian アカウントのどちらを持っているか、そして JSM 用に SSO が設定されているかどうかによって決まります。
トラブルシューティング:
問題 | 回避策/トラブルシューティングのヒント |
---|---|
| カスタマーのポータル専用アカウントを Atlassian アカウントのカスタマーに移行します
|