On a Chorus system has been configured to use SSO, an external authentication system known as an Identity Provider (IdP) will have taken over the task of authenticating user accounts. Changes or mis-configurations on the external IdP system can trigger the creation of duplicate user accounts.
Chorus receives details such as username, email address from that system but the most important piece of information received is known as the Persistent format NameID attribute. Think of this as the user's account number. It must never change.
Chorus uses the NameID/account number value to determine if a user has logged in before. If Chorus receives an unknown NameID/account number from the IdP, Chorus will assume that a new user account is to be created.
Duplicate accounts can be recognised by a number on the end of the username. They are typically created in one of three scenarios:
Scenario 1) The IdP has not been configured to send a persistent (unchanging) identification attribute (the account number in our metaphor).
Scenario 2) You have changed from one IdP to another and your new IdP is sending a new identification attribute for users.
Chorus uses the NameID attribute sent to it by the IdP to link a user account on your IdP to a user account in Chorus. If this value changes, Chorus will not be able to determine if the user currently trying to login has done so before. A new Chorus user account will be created in such a situation potentially leading to duplicates.
Please ensure that your IT team are aware of the above ideally before migrating and see the 'Recovering from Scenario 2' section below.
Scenario 3) You previously used internal Chorus authentication for user accounts before adding support for SSO logins. Your users initially had an internally authenticated account but when they login through SSO for the first time they receive a second account. This is because Chorus allows both. If you want a user to only use one method of authentication, their original account must have its authentication type changed to external authentication before they login through SSO. Chorus will then look at the email address being presented on new SSO logins, if it finds an existing account matching that email address, it will use the existing account rather than creating a separate one.
Recovering from Scenarios 1 and 2
Chorus keeps a record of the persistent identifier attribute for each user sent to it by the IdP. If you are about to change IdP vendors and believe that these values will change (i.e. no longer be persistent), you can blank the 'account number' record for the user in Chorus.
a) Navigate to Admin > Users > Edit User
b) Temporarily Change the Authentication Mode from External Authentication to e.g. External API driven authentication or one of the other options external options that you are not currently using and Save. This will blank the record. Be careful about using the the 'Internal Chorus Password' option as that would trigger an email to users.
c) Immediately change the Authentication Mode back to External Authentication and Save.
d) When the user account next logs in, the absence of an account number in the Chorus records will mean that Chorus falls back to attempting to discover if the user has logged in before via the email address of the account logging in. Email addresses are nor persistent or unique (they might change after a company takeover or a user may have more than one account on Chorus) but this fall back technique may be enough for most cases.
e) You can also use the bulk-edit operations to change more than one account at once but it is prudent to test the process on a single account first.
e.g. Admin > Users > Shift click on multiple users > Edit User
Recovering from Scenario 3
Before your tell your users to use the SSO login button instead of the internal one, perform the following steps:
a) Navigate to Admin > Users > Edit User
b) Select the users with internally authenticated user accounts. Use shift-click to select multiple accounts and then click the edit icon towards the top right.
c) Change Authentication Mode from Internal Chorus Password to e.g. External AD FS / SAML2 authentication
d) You may now inform your users that they can login via SSO.
