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

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

はじめる前に

JIT が有効になっていると、既存のユーザーの認証中に次の変更が行われます。

• ユーザー名が変更された場合は、ユーザーの名前が変更される。

• ユーザーのメールが変更された場合は同様に変更される。

• ユーザーの表示名が変更された場合は同様に変更される。

• ユーザーのグループが認証応答で IdP によって返されなかった場合は、そのユーザーが属するすべてのグループからユーザーが削除される。

• ユーザーのグループが認証応答で IdP によって返された場合は、そのユーザーが現在属していないすべてのグループにユーザーが追加される。

変更がどのように行われたか (手動、またはユーザーが IdP 側で更新されたかどうか) に関係なく、ユーザー データはユーザーが ID プロバイダーから返された状態になるまで常に変更されます。

詳細

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

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

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

JIT が SSO 認証で有効になっている場合、削除されたユーザーはどうなりますか?

Jira で JIT を有効にすると、AzureAD のログイン応答から取得されたユーザー データが Jira の内部ディレクトリに保存されるようになります。

Jira には AzureAD とアクティブに同期する方法がないため、Jira の内部ディレクトリからユーザーを削除する方法はありません。

JIT は AzureAD のログイン応答に依存しているため、AzureAD で無効になっているユーザーまたは AzureAD から削除されたユーザーは、AzureAD で認証することができません。この場合、これらのユーザーは Jira から手動で削除する必要があります。

マッピング表現

マッピング表現は、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 プロビジョニング - 属性マッピングのテスト方法」を参照してください。

その他の注意事項:

SAMLDC-77 - Getting issue details... STATUS

アトラシアンのアプリに同期されたグループを使用して権限 (プロジェクト、スペースなど) を割り当てることができるため、IdP のグループ名によってはユーザーが簡単に認識できないものもあります。たとえば、「Azure AD + 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 と見なされます。