FINERACT-2003: Enforce password reset on first login

[DeathGun44]

Description

Implemented FINERACT-2003: Enforce password reset on first login.
This PR adds a configurable, optional policy forcing users to change their password upon first login or after an admin reset.

Key Changes

• Database: Added password_reset_required column to m_appuser.
• Configuration: Added force-password-reset-on-first-login global flag (disabled by default).
• Security:
  • AuthenticationApiResource returns HTTP 403 with credentials when reset is required
  • SpringSecurityPlatformSecurityContext enforces the check for all API calls
  • PlatformUserDetailsChecker handles standard credential expiration checks
• Logic:
  • Set flag: On user creation and admin password reset (only when feature enabled)
  • Clear flag: On successful self password change
  • Exemption: Password update requests are exempted to allow users to complete the reset
• Testing: Added PasswordResetIntegrationTest to verify enforcement and optionality

Checklist

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green")
• Create/update unit or integration tests
• Follow our coding conventions
• Add required Swagger annotation and update API documentation
• This PR must not be a "code dump"

[IOhacker]

LGTM

[DeathGun44]

@IOhacker I looked into the failed tests ,failures are in LoanDelayedScheduleCaptures and LoanMerchantIssuedRefund but these appear to be unrelated to the Authentication changes in this PR. could you please re-run them?

[DeathGun44]

@adamsaghy Happy to take reviews, if any

[adamsaghy]

Please make sure this is optional, not enforced by default and properly tested.

[DeathGun44]

Please make sure this is optional, not enforced by default and properly tested.

Understood. I will update the logic to be optional and remove the redundant Liquibase scripts. And a new integration test (PasswordResetIntegrationTest.java) to this PR to verify the enforcement and optionality as requested.

[DeathGun44]

@adamsaghy Ready for re-review whenever you have a moment!

[adamsaghy]

@DeathGun44 please rebase

[DeathGun44]

@adamsaghy Done!

[adamsaghy]

I don’t believe this PR adequately addresses the requirements.

Any user with permission to change their password can simply override the existing one.

We need a system where the authenticated user is responsible for changing their own password!

[DeathGun44]

@adamsaghy Hi Adam, thanks for the feedback. I've reworked the implementation to strictly enforce self-service as requested:

Dedicated Endpoint: The exemption now targets POST /users/{id}/pwd (ChangePassword) instead of the general updateUser. This limits changes to password fields only.

Identity Check: I added a check to ensure entityId == currentUser.getId(). The exemption now only applies if the user is changing their own password.

Verified Flow:

POST /users/{ownId}/pwd → Allowed (Self-check passes, account unlocked).

POST /users/{otherId}/pwd → Blocked (Self-check fails).

PUT /users/{ownId} (General update) → Blocked (Wrong endpoint).

Note: Admins can still reset passwords via the standard flow, which re-triggers the passwordResetRequired flag for the target user.