JIT ユーザー プロビジョニング

ジャストインタイム ユーザー プロビジョニング (JIT プロビジョニング) では、SAML SSO または OpenID Connect (OIDC) SSO を使用して Jira、Confluence、Bitbucket などの Atlassian Data Center アプリケーションにログインする際に、ユーザーを自動的に作成および更新することができます。

詳細

JIT を使用しないと、ユーザーがユーザー ディレクトリのいずれか (リモート LDAP または内部ディレクトリ) に存在しない場合、SSO によるログインは失敗します。JIT を有効にすると、ユーザーがその場で作成されるので、インスタント ログインが可能になり、前もって製品でユーザーを手作業で作成しておく必要がなくなります。ユーザーのプロビジョニングに必要なデータは、ユーザーの認証後に SSO レスポンスから取得されます。これは、選択したアイデンティティ プロバイダー (IdP) で設定する必要があります。

JIT でプロビジョニングされたユーザーは、お使いのアプリケーションの内部ディレクトリで作成されます。ユーザーを作成するには、そのユーザーのユーザー名、表示名、メール アドレス、グループ メンバーショップが必要となります。このフィールドには、SSO レスポンスから得られたデータが記入されます。このデータは IdP で構成され、属性 (SAML を使用する場合) または要求 (OIDC を使用する場合) 経由で利用可能にしておく必要があります。この設定の詳細については以降をお読みください。

以降のログイン (および JIT プロビジョニングが有効な期間) では、IdP から得られる変更の情報により、ユーザーのデータが最新に保たれます。これには、JIT プロビジョニング以前に内部ディレクトリに含められたすべてのユーザーも該当します。ユーザーのログイン時にリモート ディレクトリが有効になるのと同時に、JIT プロビジョニングを使用する SSO が有効化されると、リモート ディレクトリが優先されます。ユーザーがリモート ディレクトリに存在する場合、そのユーザーはそこからログインすることになります。

マッピング表現

マッピング表現は、JIT プロビジョニング アプリの一部です。これは、文字列とともに使用するシンプルな式です、変数を宣言し、式を評価する際にそれを提供された値で置き換えます。構文は、確立されたパターン "${variableName}" に従います。例: "some text ${conjunction} some more text" があったときに、"conjunction" = "and" とすると、"some text and some more text" として評価されます。

SSO および JIT プロビジョニングを構成する場合、変数の置き換えは、選択した IdP の SSO レスポンスから発生します。

  • SAML の場合、これらの情報はユーザーに関連付けられている属性になります。

  • OIDC の場合、これらの詳細は、ユーザーに関連付けられている (リクエストされたスコープの) 要求になります。

マッピング表現が必要なフィールドは以下のとおりです。

  • ユーザー名のマッピング
  • 表示名 (JIT プロビジョニングが有効な場合)
  • メール アドレス (JIT プロビジョニングが有効な場合)

JIT プロビジョニング フィールドの "グループ" はマッピング表現をサポートせず、グループ名の一覧を含む属性/要求の名前のみが必要であることにご注意ください。

ユーザーが SAML でプロビジョニングされるときに、display name のマッピングの値が ${firstName} ${lastName} 2020となるコンテキストの例について考えます。

  • ${firstName}firstName という名前の属性の値で置き換えられます。

  • ${lastName} は、lastName という属性の値に置き換えられます。

  • 2020 は変更されません。

John Smith という名前のユーザーがログインする場合、製品でのそのユーザーの表示名は John Smith 2020 になります。

これらの属性/要求が SSO レスポンスに含まれる必要があることに注意してください。含まれない場合、ユーザーが SSO でログインする際にエラーが発生します。構成が有効であることを確認するには、「JIT プロビジョニング - 属性マッピングのテスト方法」を参照してください。

ユーザー名のマッピング フィールドを設定する

JIT プロビジョニングのもう 1 つの変更点は、これまで [Username claim] フィールドと呼ばれていた、OpenID Connect のみで使用できるフィールドへの更新です。このフィールドでは、SSO ログイン時にユーザー名を照合する際に使用する要求を指定できます。このフィールドを現在、SAML (これまではユーザー名のソースとして NameID を使用するように既定で設定されていました) で使用できるようになりました。また、次のようにいくつかの点でも更新されています。

  • このフィールドは現在必須であり、ユーザー名のソースを指定する際の有効な選択肢として推奨されています。
  • このフィールドは、前述のセクションで説明されているマッピング表現です。

プラグインのアップグレード後は、以前の値 (または値のない状態) が移行されることに注意してください。

JIT プロビジョニングに対するこのフィールドの影響

SSO でログインする際、ユーザーのユーザー名はこのフィールドのマッピング表現によって評価されます。JIT プロビジョニングが無効の場合、このユーザー名を使用して、IdP によって認証されたユーザーを製品内のユーザー エントリ (リモート ディレクトリからのエントリの場合もあります) と照合し、そのユーザーをログインさせます。JIT プロビジョニングが有効の場合、製品内でユーザーを一意に識別する方法はユーザー名だけではなくなります。この理由として、ユーザー データの提供を IdP に頼っていることと、そのデータが (ユーザー名を含めて) 変更される可能性があることが背景にあります。これにより、ユーザーが IdP でユーザー名を変更するたびに、製品にログインすることで (同一ユーザーであるにもかかわらず) 新しいユーザー エントリがプロビジョニングされるというシナリオが発生します。このシナリオを避けるには、IdP とユーザー名のマッピングをユーザー名の更新をサポートするように構成する必要があります。これを実現するには、永続 ID という手段でユーザーを一意に識別します。永続 ID の値はユーザーの記録が保持される限り変更されず、IdP により提供されます。

SAML の場合: SAML 仕様 (セクション 8.3.7) は NameID の永続的な id 形式を定義しており、これを IdP で構成する必要があります。また、IdP で、変更可能なユーザー名を含む新しい属性を作成し、それを ユーザー名のマッピング式で使用する必要があります。(例: "${preferredUsername}")。JIT プロビジョニングが有効になっている場合、NameID が永続的な id と見なされます。

OIDC の場合: OIDC の仕様では、サブジェクト識別子 (sub 要求) がアプリケーション内の各ユーザーの標準として定義されています。この識別子が永続 ID であり、通常は IdP で自動的に生成および処理されます。一般的にはその後、標準要求の preferred_username (profile スコープにあります) を変更の可能性があるユーザー名のソースとして使用するので、たとえば [ユーザー名のマッピング] フィールドは "${preferred_username}" と設定されます。JIT プロビジョニングを有効にすると、sub 要求が永続 ID とみなされます。

最終更新日 2020 年 6 月 25 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.