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 が有効化されると、リモート ディレクトリが優先されます。ユーザーがリモート ディレクトリに存在する場合、そのユーザーはそこからログインすることになります。

What happens to deleted users when JIT is enabled with SSO authentication?

When JIT is enabled, Jira saves user data retrieved from AzureAD’s login response to Jira’s internal directory.

Since Jira doesn’t have a way to actively synchronize with AzureAD, there is no way to delete the user from Jira’s internal directory.

Because JIT relies on AzureAD’s login response, users disabled in or deleted from AzureAD won’t be able to authenticate with AzureAD. In this case, these users must be manually deleted from 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 プロビジョニングが有効な場合)

Note that the JIT provisioning field Groups does not support mapping expressions and requires only the name of an attribute/claim containing a list of group names.

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

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

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

• 2020 は変更されません。

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

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

その他の注意事項:

SAMLDC-77 - 課題情報を取得中... ステータス

アトラシアンのアプリに同期されたグループを使用して権限 (プロジェクト、スペースなど) を割り当てることができるため、IdP のグループ名によってはユーザーが簡単に認識できないものもあります。たとえば、「Azure AD + JIT」などです。前述の機能リクエストを通じてこの統合の改善を追跡しています。

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

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

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

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

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

When logging in with SSO, the user's username will be evaluated by the mapping expression in the field. 

With JIT provisioning disabled, that username will be used to match the user as authenticated by the IdP to a user entry within the product (which may come from a remote directory) and log them in.

If JIT provisioning is enabled, the username can no longer be the only way in which we uniquely identify a user within the product. The reason behind this is that we are relying on the IdP to provide us with the user's data and that data, including the username, can change. This creates a scenario where every time a user changes their username in the IdP, logging into the product will cause a new user entry to be provisioned (even though it is the same user).

To avoid this scenario, your IdP and username mapping needs to be configured to support username updating. This is done by uniquely identifying the user by means of a persistent id, meaning that the value of this id does not change throughout the lifetime of the user's record, which should be provided by the IdP.

In SAML: The SAML specification (section 8.3.7) defines a persistent id format for the NameID, which you should configure in your IdP. Also in your IdP, you should then create a new attribute that will contain the changeable username and use it in your Username mapping expression, for example: "${preferredUsername}". When JIT provisioning is enabled, it is assumed the NameID is a persistent id.

In OIDC: The OIDC specification defines the Subject Identifier (the sub-claim) as standard for each user within an application, which is a persistent id and usually generated and handled automatically in IdPs. It is common practice to then use the standard claim preferred_username (found in the profile scope) as the source of the changeable username, so the Username mapping field would be configured as "${preferred_username}" for example. When JIT provisioning is enabled, it is assumed the sub-claim is a persistent id.