Fix user creation via UI when SSO authentication is enabled

[Copilot]

Describe your changes:

User creation via UI fails with 409 "Entity already exists" when SSO is enabled because the UI unconditionally sends password-related fields (password, confirmPassword, createPasswordType) regardless of authentication provider. These fields are only valid for Basic/LDAP auth where OpenMetadata manages passwords directly.

Changes:

• CreateUser.component.tsx: Conditionally include password fields only when isAuthProviderBasic is true (Basic or LDAP providers)

  // Before: always included password fields
  : {
      password: ...,
      confirmPassword: ...,
      createPasswordType: CreatePasswordType.AdminCreate,
    }
  
  // After: conditional on auth provider
  : isAuthProviderBasic
    ? { password: ..., confirmPassword: ..., createPasswordType: ... }
    : {}

• CreateUser.test.tsx: Added test coverage for both Basic auth (password fields rendered) and SSO auth (password fields excluded)

Impact:

Auth Provider	Password Fields in Payload	Status
Basic/LDAP	✅ Included	Works (unchanged)
SSO (Google, Okta, Azure, SAML, etc.)	❌ Excluded	Fixed
Bot (JWT)	N/A (uses JWT config)	Works (unchanged)

Type of change:

• Bug fix

Checklist:

• I have read the CONTRIBUTING document.
• My PR title is Fixes <issue-number>: <short explanation>
• I have commented on my code, particularly in hard-to-understand areas.
• For JSON Schema changes: I updated the migration scripts or explained why it is not needed.

• I have added a test that covers the exact scenario we are fixing. For complex issues, comment the issue number in the test for future reference.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>User creation via UI fails with "Entity already exists" when SSO is enabled and self-registration is disabled</issue_title>
<issue_description>## [Bug] User creation via UI fails with "Entity already exists" when SSO is enabled and self-registration is disabled

Affected Module

UI and Backend

Describe the Bug

When OpenMetadata is configured with SSO authentication and self-registration is disabled, creating a new user through the UI fails with the error:

{"code":409,"message":"Entity already exists"}

However, creating the same user via the API succeeds.

Root Cause

The UI includes "createPasswordType": "ADMIN_CREATE" in the payload when creating users, which triggers a conflict error. This field is intended for basic authentication setups and should not be included when SSO is the authentication method.

UI Payload (fails):

{
  "description": "",
  "name": "username",
  "displayName": "User Name",
  "email": "[email protected]",
  "isAdmin": false,
  "domains": [],
  "isBot": false,
  "createPasswordType": "ADMIN_CREATE"
}

API Payload (works):

{
  "name": "User Name",
  "email": "[email protected]",
  "displayName": "User Name",
  "isAdmin": false
}

Removing createPasswordType from the payload allows user creation to succeed.

To Reproduce

1. Configure OpenMetadata with SSO authentication (e.g., Okta, Azure AD, Google, etc.)
2. Disable self-registration
3. Login as admin
4. Navigate to Settings → Users → Add User
5. Fill in user details and submit
6. Observe error: {"code":409,"message":"Entity already exists"}

Expected Behavior

• User should be created successfully via UI when SSO is enabled
• The UI should not include createPasswordType field when SSO authentication is configured (since passwords are managed by the SSO provider)

Suggested Fix

The UI should conditionally exclude createPasswordType from the payload when:

• SSO authentication is enabled, OR
• Self-registration is disabled

Alternatively, the backend could ignore the createPasswordType field when SSO is the configured authentication method.

Environment

• OpenMetadata version: 1.10.1
• Authentication: SSO (specify your provider)
• Self-registration: Disabled
• Deployment: (Docker / Kubernetes / Bare Metal)

Additional Context

This issue prevents administrators from creating users through the UI when using SSO, forcing them to use the API as a workaround.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes User creation via UI fails with "Entity already exists" when SSO is enabled and self-registration is disabled #25007

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[gitar-bot]

🔍 CI failure analysis for 2f33a36: 11 Playwright tests failed, but all failures are unrelated to this PR's user creation changes - likely pre-existing issues from main branch merge.

Issue

The playwright-ci-postgresql (3, 6) job (Job ID: 60315845378) has 11 test failures.

Root Cause

The test failures are NOT related to this PR's changes. This PR only modifies user creation UI logic in two files:

• CreateUser.component.tsx
• CreateUser.test.tsx

However, the failing tests are testing completely different features:

Failed Tests (11 total):

1. SearchIndex Service Permissions - allow common operations permissions
2. Query Entity test
3. Glossary Permissions - team-based permissions
4. Settings Navigation Page - drag and drop reordering
5. Settings Navigation Page - reset functionality and navigation blocker
6. Settings Navigation Page - multiple items being hidden
7. Tags and glossary terms consistency in search
8. Customize Landing Page - Add, Remove and Reset widget (failed twice including retry)
9. Explore Assets Discovery - soft deleted assets in search suggestions
10. Metric Entity - verify metric expression update

Details

None of these tests touch user creation functionality. They test:

• Permissions systems
• Landing page customization
• Settings navigation
• Query entities
• Glossary features
• Search functionality
• Metrics

Context: This PR was recently merged with the main branch (commit 2f33a36), which brought in 200+ file changes including:

• StarRocks database connector
• Test definition updates
• AWS credentials handling
• Search configuration changes
• Multiple resource endpoints

These test failures are likely:

1. Pre-existing flaky tests in the main branch
2. Tests broken by other changes in the main branch merge
3. Infrastructure/timing issues unrelated to code changes

Previous Analysis Context

Earlier, 9 CI jobs failed due to missing 'safe to test' label. That label was since added, allowing tests to run. Now we're seeing actual test execution, but the failures are in unrelated test suites.

Code Review ✅ Approved

Clean, well-targeted bug fix that correctly conditionalizes password field inclusion based on auth provider. Test coverage for both Basic and SSO scenarios is appropriate.

What Works Well

Good use of conditional spread pattern to cleanly handle the auth provider check. Test cases properly cover both Basic auth and SSO scenarios using appropriate mocking strategies.

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off Gitar will not commit updates to this branch.
Display: compact Hiding non-applicable rules.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | This comment will update automatically (Docs)}

[github-actions]

Jest test Coverage

UI tests summary

Lines	Statements	Branches	Functions
	65.32% (52855/80920)	43.33% (26332/60768)	46.79% (8229/17588)

[sonarqubecloud]

Quality Gate passed for 'open-metadata-ui'

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud