JIT user provisioning - Group and Resource updates are silently skipped when the SSO assertion username case does not match CMN_SEC_USERS.USER_NAME
search cancel

JIT user provisioning - Group and Resource updates are silently skipped when the SSO assertion username case does not match CMN_SEC_USERS.USER_NAME

book

Article ID: 449775

calendar_today

Updated On:

Products

Clarity PPM SaaS Clarity PPM On Premise

Issue/Introduction

In the SSO Just-In-Time user flow, the lookup that resolves the user's primary key on the update path is case-sensitive.
When the IdP asserts a username whose character case differs from the value stored in CMN_SEC_USERS.USER_NAME, JIT correctly detects the user already exists and takes the update branch, then fails to resolve the user id and security group synchronization and Resource attribute updates silently never reach the real user. The user still authenticates successfully

STEPS TO REPRODUCE:

  1. Connect to Clarity on Oracle or PostgreSQL with SAML and JIT provisioning enabled.
  2. Create a Clarity user with USER_NAME in lowercase, for example jsmith, and assign a known set of security groups.
  3. Configure the IdP so the user_name claim in the assertion comes across in a different character case, for example JSmith.
  4. Include user group mappings in the JIT assertion so provisioning has work to do. Also include Resource parameter mappings as well.
  5. Log in through SSO as that user.
  6. Check the user's group membership under Administration - Resources, and check the Resource attributes if Resource parameters were mapped.

Expected Results: JIT recognizes the existing user regardless of character case and applies the asserted security groups and Resource parameters to that user. 

Actual Results: The security groups asserted by the IdP are not applied to the user, and mapped Resource parameters are not updated. No error is shown to the user and login succeeds.

Environment

Clarity 16.4.1, 16.4.2, 16.4.3 with JIT 2.0

Cause

DE209746

Resolution

Fixed in Clarity 16.5.0

Workaround: Correct the stored USER_NAME in Clarity so its character case exactly matches what the IdP asserts, or change the IdP mapping to emit the same case as stored.