Identity linking has a 'magic number' that limits account linking / recovery

[gregcorbett]

See: https://github.com/GOCDB/gocdb/blob/5.9.0/htdocs/web_portal/controllers/user/link_identity.php#L52

1 is a bit of a magic number here, I believe it limits the number of identities one can associate with an account. I.e. if a user user has both an EGI Check In identifier and a X.509 identifier associated, they wouldn't be able to associate an IRIS IAM account as well - because they'd trigger this if statement and get shown the user/link_identity_rejected.php page.

This check might be best reworked as a comparison to the length of $authTypes (on the assumption that a user can't have multiple identifiers of the same type - which I don't believe they can, and certainly the intention is they shouldn't be able to.) Or it might not be needed.

This may be best fixed as a hot fix so it can be pushed out quickly, or as part of 5.9.0 itself.

For testing, one would need a user with two identifiers associated with them and the ability to associate a third (i.e. using the preprod DB on an instance integrated with IRIS IAM)

[gregcorbett]

This magic number also prevents recovery of an account if you have maxed out your number of allowed identifiers. Given this, maybe we don't need the check.

[gregcorbett]

This magic number also prevents recovery of an account if you have maxed out your number of allowed identifiers. Given this, maybe we don't need the check.

i.e. If I have an X.509 cert and EGI CheckIn identifier associated with my account, I can't recover my account if my DN changes.

[gregcorbett]

It seems one can get around this magic number.

I imagine this may be be possible if

• You have two accounts, one with one (or at least less than the magic number of) identifier and one with the magic number (or more) of identifiers.
• Launch the identity linking process from the account with one identifier.

[gregcorbett]

This check does have the benefit of stopping account lining between two accounts with multiple identifiers.

I.e.:

• Account 1

  • X.509: old DN
  • EGI Proxy IdP: string1

• Account 2

  • X.509: new DN
  • EGI Proxy IdP: string2

If the user was logged into one of these accounts with their X.509 cert (seeking account recovery), then the two accounts in practice cannot be merged. This seems sensible, as it avoids the question of how the EGI Proxy IdP identifiers should be handled - an account can (/ should, I don't think there is anything in the database layer to stop it) have only one identifier of each type.

That logic feels like it extends to the general case, where a user could have identifiers of N different types. To ensure a safe link, we'd have to ensure the two accounts involved don't share an authentication type (and/or maybe come up with a sensible way to handle that case). We could implement something along those lines if the need arises , but it hasn't so far... so maybe a better comment is all that is needed here.