**As** a user
**I want to** Begin of the insertionrework the "change password page",
**so that** I canEnd of the insertion see Begin of the insertionand manage whether login through password is possible forEnd of the insertion Begin of the deletion which external accounts are connected toEnd of the deletion my Begin of the insertionaccount.End of the insertion Begin of the deletion OpenProject accountEnd of the deletion

**Context**

Begin of the insertionInitiallyEnd of the insertion Begin of the deletion * A user's account can be connected to other IDPs, (eg. Google, Entra...)

* InEnd of the deletion the Begin of the insertionintention was that logging in through an SSO provider would clear one's password andEnd of the insertion Begin of the deletion past,End of the deletion only Begin of the insertionallow for login via SSO. However, there was/is a bug, that when an existing account (with password login) authenticates via SSO andEnd of the insertion the Begin of the insertionSSOEnd of the insertion Begin of the deletion last-usedEnd of the deletion provider Begin of the insertionis subsequently added to the account via the "remap existing account" feature, the password loginEnd of the insertion would Begin of the insertionstillEnd of the insertion be Begin of the insertionpossible.

This bug turned out to be a desired feature for some customers, which leaves usEnd of the insertion Begin of the deletion savedEnd of the deletion in Begin of the insertiona position where it's hard to fixEnd of the insertion the Begin of the insertionbug, but we don't really support this setup either.

**Acceptance criteria**

(SuggestionEnd of the insertion Begin of the deletion DB (?)

* In some cases, when the ID comesEnd of the deletion from Begin of the insertionJan to be turned into DesignEnd of the insertion Begin of the deletion an external IDP, some fields are not editable (firstEnd of the deletion and Begin of the insertionthen back into Acceptance criteria)

End of the insertion Begin of the deletion last name), but some are (eg. email)

End of the deletion * Begin of the insertionRename (account preferences) menu item "Change password"End of the insertion Begin of the deletion There is a note when this is the case.

* \[Pavel can write a list of places affected by this, with screenshotsEnd of the deletion to Begin of the insertion"Password & Login"

End of the insertion Begin of the deletion illustrate current behaviour\]

End of the deletion * Begin of the insertionView of that menuEnd of the insertion Begin of the deletion So when using an IDP, thereEnd of the deletion is Begin of the insertionsplitEnd of the insertion Begin of the deletion nevertheless a corresponding accountEnd of the deletion in Begin of the insertiontwo sections:End of the insertion Begin of the deletion OpenProject (existing or a new one is created)

* A user _could_ theoretically log into their OP account using _two_ different IDPs.End of the deletion

* Begin of the insertion1: Password

End of the insertion Begin of the deletion All of the different IDPs are now stored in the DB.

End of the deletion * If Begin of the deletion the same email address is used,End of the deletion a Begin of the insertionpassword is set

End of the insertion Begin of the deletion new IDP can take over login for that account.

End of the deletion * Begin of the insertionShows last time password was changed ("x days ago")

End of the insertion Begin of the deletion Having multiple providers is nevertheless less common.

End of the deletion * Begin of the insertionallowsEnd of the insertion Begin of the deletion Why a user might wantEnd of the deletion to Begin of the insertionopen change password modal via button

End of the insertion Begin of the deletion remove a connection:

End of the deletion * Begin of the insertionallowsEnd of the insertion Begin of the deletion remove an existing one when they've transitionedEnd of the deletion to Begin of the insertionremove password via button

End of the insertion Begin of the deletion a new one

End of the deletion * Begin of the deletion risk: might also lock themselves out if there wasEnd of the deletion only Begin of the insertionif SSO account exists

End of the insertion Begin of the deletion one

End of the deletion * Begin of the insertionIf no passwordEnd of the insertion Begin of the deletion if hijackingEnd of the deletion is Begin of the insertionset

End of the insertion Begin of the deletion allowed, then even if you remove one, it'll be reestablished when I reconnect

End of the deletion * Begin of the insertionshows thatEnd of the insertion Begin of the deletion if hijacking is not allowed,End of the deletion no Begin of the insertionpasswordEnd of the insertion Begin of the deletion SSO accountEnd of the deletion is Begin of the insertionset

* allowsEnd of the insertion Begin of the deletion availableEnd of the deletion to Begin of the insertioncreate a password via button

End of the insertion Begin of the deletion the user (however, the account will still exist)


**Acceptance criteria**

End of the deletion * Begin of the insertiononly if allowed by admin (to be determined where/how)

End of the insertion Begin of the deletion TBD


**Technical notes**

End of the deletion * Begin of the insertion2: SSO accounts

End of the insertion Begin of the deletion Need a matrix/table of cases, considering:

End of the deletion * Begin of the insertionLists all connected SSO accounts

End of the insertion Begin of the deletion different admin settings (hijack on and off)

End of the deletion * Begin of the insertionallows to unlink an SSO account

* only if password or other SSO account exists

* only if allowed by admin (to be determined where/how)


End of the insertion Begin of the deletion different user cases (only 1 SSO, with 2 diff SSOs...)


End of the deletion **Permissions and visibility considerations**

* Begin of the insertionto be determined: What should admins be able to allow/disallow here?

* this potentially requires change of existing instance-level settings


End of the insertion Begin of the deletion <br>


End of the deletion **Translation considerations**

* <br>


**Out of scope**

* Begin of the insertionadmin-level mass-changes, e.g. &quot;remove password from everyone&quot;End of the insertion Begin of the deletion Removal of existing connections.

* This might be better handled at an admin-level. When a provider is removed, all the connections are also removed.

* \[open\] Should the user be notificed somehow? Existing services are marked as &#39;deactivated&#39; or &#39;inactive&#39; when an existing configured external account is no longer possible.End of the deletion