Content
View differences
Updated by Parimal Satyal 12 months ago
**As** a user
**I want to** see which external accounts are connected to my OpenProject account
**Context**
* A user's account can be connected to other IDPs, (eg. Google, Entra...)
* In the past, only the last-used provider would be saved in the DB (?)
* In some cases, when the ID comes from an external IDP, some fields are not editable (first and last name), but some are (eg. email)
* There is a note when this is the case.
* \[Pavel can write a list of places affected by this, with screenshots to illustrate current behaviour\]
* So when using an IDP, there is nevertheless a corresponding account in OpenProject (existing or a new one is created)
* A user _could_ theoretically log into their OP account using _two_ different IDPs.
* All of the different IDPs are now stored in the DB.
* If the same email address is used, a new IDP can take over login for that account.
* Having multiple providers is nevertheless less common.
* Why a user might want to remove a connection:
* remove an existing one when they've transitioned to a new one
* risk: might also lock themselves out if there was only one
* if hijacking is allowed, then even if you remove one, it'll be reestablished when I reconnect
* if hijacking is not allowed, no SSO account is available to the user (however, the account will still exist)
**Acceptance criteria**
* In Account settings, create a new page "Authentication" in the sidebar
* With three tabs:
* Password
* External accounts
* Access tokens
* In Password,
* If using SSO, then inform the user that the password needs to be changed via the IDP, with a link to do this.
* _\[open\] Should the user still be able to change the password, even if they have an SSO enabled? If so, we should tell the user._
* _To do: list all cases, and design them._
* These three pages will be Primerised. <br>
**Technical notes**
* Need a matrix/table of cases, considering:
* different admin settings (hijack on and off)
* different user cases (only 1 SSO, with 2 diff SSOs...)
<br>
**Permissions and visibility considerations**
* <br>
**Translation considerations**
* <br>
**Out of scope**
* 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 'deactivated' or 'inactive' when an existing configured external account is no longer possible. <br>
**I want to** see which external accounts are connected to my OpenProject account
**Context**
* A user's account can be connected to other IDPs, (eg. Google, Entra...)
* In the past, only the last-used provider would be saved in the DB (?)
* In some cases, when the ID comes from an external IDP, some fields are not editable (first and last name), but some are (eg. email)
* There is a note when this is the case.
* \[Pavel can write a list of places affected by this, with screenshots to illustrate current behaviour\]
* So when using an IDP, there is nevertheless a corresponding account in OpenProject (existing or a new one is created)
* A user _could_ theoretically log into their OP account using _two_ different IDPs.
* All of the different IDPs are now stored in the DB.
* If the same email address is used, a new IDP can take over login for that account.
* Having multiple providers is nevertheless less common.
* Why a user might want to remove a connection:
* remove an existing one when they've transitioned to a new one
* risk: might also lock themselves out if there was only one
* if hijacking is allowed, then even if you remove one, it'll be reestablished when I reconnect
* if hijacking is not allowed, no SSO account is available to the user (however, the account will still exist)
**Acceptance criteria**
* In Account settings, create a new page "Authentication" in the sidebar
* With three tabs:
* Password
* External accounts
* Access tokens
* In Password,
* If using SSO, then inform the user that the password needs to be changed via the IDP, with a link to do this.
* _\[open\] Should the user still be able to change the password, even if they have an SSO enabled? If so, we should tell the user._
* _To do: list all cases, and design them._
* These three pages will be Primerised.
**Technical notes**
* Need a matrix/table of cases, considering:
* different admin settings (hijack on and off)
* different user cases (only 1 SSO, with 2 diff SSOs...)
* <br>
**Translation considerations**
* <br>
**Out of scope**
* 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 'deactivated' or 'inactive' when an existing configured external account is no longer possible.