Skip to content

fix(controlled-documents): confirm signatures of SSO accounts with an email code - #11143

Open
MichaelUray wants to merge 1 commit into
hcengineering:developfrom
MichaelUray:fix/controlled-doc-sso-signature
Open

MichaelUray wants to merge 1 commit into
hcengineering:developfrom
MichaelUray:fix/controlled-doc-sso-signature

Conversation

@MichaelUray

Copy link
Copy Markdown
Contributor

Refs #10183

Problem and change

The signature dialog re-authenticated the signer only with email and password via the account login. Accounts created through SSO have no password, so they could not approve, reject or submit controlled documents at all.

The dialog now checks whether the account has a password. If it does not, the signer requests a one-time code that is sent to the email of the current account (existing loginOtp/validateOtp flow) and confirms the signature with it; accounts with a password keep the password confirmation. In both cases the dialog now also verifies that the credentials belong to the signed-in account. The verification is extracted into a small helper with unit tests, and the package test script is enabled.

The password setting part of the issue is already covered on develop: accounts without a password are offered an email-confirmed password setup instead of the change-password form.

Tests

New unit tests plugins/controlled-documents-resources/src/__tests__/signature.test.ts; test scripts added to the package so CI runs them. A self-hosted check needs an SSO-only account and a working mail service for the code: open a controlled document as that user and Submit/Approve → the dialog offers "Send code" and accepts the emailed code; a user with a password still gets the password prompt.

Notes

  • The re-authentication is not weakened: password accounts keep the password check, and both modes now also require the returned account to be the signed-in one.
  • Whether an emailed one-time code is acceptable for a given compliance regime is a product decision; it is the same factor the platform already accepts for login. Verifying the code currently goes through the regular code-login operation, so it has the same side effects (code consumed, email marked verified).
  • The "Change password" part of the issue is already handled on develop for accounts without a password ("Set password" flow); hence "Refs".

… email code

The signature dialog re-authenticated the signer only with email and password via the account login. Accounts created through SSO have no password, so they could not approve, reject or submit controlled documents at all.

The dialog now checks whether the account has a password. If it does not, the signer requests a one-time code that is sent to the email of the current account (existing loginOtp/validateOtp flow) and confirms the signature with it; accounts with a password keep the password confirmation. In both cases the dialog now also verifies that the credentials belong to the signed-in account. The verification is extracted into a small helper with unit tests, and the package test script is enabled.

The password setting part of the issue is already covered on develop: accounts without a password are offered an email-confirmed password setup instead of the change-password form.

Refs hcengineering#10183

Signed-off-by: Michael Uray <michaeluray@users.noreply.github.com>
@MichaelUray
MichaelUray force-pushed the fix/controlled-doc-sso-signature branch from 4719267 to b1f9b35 Compare October 19, 2026 06:42

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant