search

ucphhpc / migrid-sync

MiGrid workspace where master branch is kept strictly in sync with SF upstream svn repo. Any development or experiments should use a branch. You probably want to fork your own clone or work e.g. on the edge branch if you wish to contribute.
GNU General Public License v2.0
3 stars 4 forks source link

Epic: Improve administration of existing external users #130

Open aputtu opened 4 weeks ago

aputtu commented 4 weeks ago

Administrating renewal of external users

When handling renewal requests from external users, we run into issues from time to time. In order to address these, we have a few manual steps, and also up to four parties involved. In worst case requires extra time from (A) external user, (B) peer contact through questions from external user, (C) support, and (D) operator, and say an account renewal can take several business days.

The following describes issues that have been observed in the support and discussed with operators of migrid instance.

Password issues

When external user accounts are about to expire, they get asked to renew through a sign up form. The form allows for entering a new password. There are then a form password and the existing, valid account password in play, which leads to trouble in further handling of the renewal request.

Three password related scenarios using migadmin.py web interface The following is as seen from support side of things:

  1. The request can be processed successfully, if the (A) peer contact has set expire date into the future, (B) form password matches account password, and (C) the request is processed before expire date.
  2. If account date has expired or the processing happens after renewal deadline, the request needs to gets forwarded to peer contact for their acceptance. 2.1. If form password matches account password, the request can be processed further in the support. 2.2. When password does not match, the request cannot be processed in the support. The fact that passwords do not match is first revealed to support after a round-trip to the peer contact for their acceptance.
  3. In 2.2 above, the standard operating procedure is to ask for users to renew their password, so that it matches the one used in the request. However, there are currently issues with matching the hashes, even when password matches. The support then needs to forward the request to operator.

Password renewals involves manual processing in support

Users can request password renewals through migrid instance using the "Forgot Password?" link. The request is processed through the migadmin.py web interface. This could be automated.

Dual account issues

Users can access a semi-automatically filled form, where name, organization, ... are filled out. They access the form through a link mailed to them. Users are instructed on not to change the information. However, if they have changed their legal name, organization, or similar and edits the fields, the account gets interpreted as a new account request.

Root causes

  1. Reuse of the open form for existing users allows for both password mismatch, and dual accounts.
  2. Opposite order of checking requests are (1) Has peer contact set expire in future? (2) Does form/account passwords match?

Suggestions for addressing the issues

The suggestions are partly mutually complimentary and partly mutually exclusive. Either suggestion 0 or 3+7 together are deemed to be two principled and more fool-proof solutions, but based on limited knowledge of the internal workings of the migrid instance. Suggestions 1-6 taken together can be seen as patching up the framework, but perhaps also points to unnecessary complexity in current setup.

  1. Ideally: We delegate handling of external users to the same framework as internal users (or perhaps a separate user authentication framework).
  2. Small: Add support documentation Part of the issues that occur, is that the process is manual and support needs to explain the procedure, create tickets, and walk users through the process. Support can add documentation and point to this.
  3. Small: Add info on sign-up form We could add more info targeted existing users on sign-up form, and we could also have it point added support documentation.
  4. Medium: Automated Password resets: Skip the manual password renewal handling in migadmin.py. The user currently receive email with a password reset link through the reset token generation, which ensures they accessed it through their email account. Once changes, the password update should be automatically accepted and user receive email confirmation.
  5. Unknown difficulty: Fixing password issue in point 2.2 in the above scenarios: When user renew account password so that it matches the form password, there is a hash mismatch which blocks support from doing further processing.
  6. Unknown difficultly: Have migadmin.py provide more information: Provide information on password mismatch, and lookup if same email is used in requests.
  7. Large: Switch checking order Adjust the checking order in request, so that password mismatch are detected first. We don't want to send a request to peer contact with a password mismatch. This should be reflected in the migadmin.py interface.
  8. Large: Having a User area before renewal requests: To avoid manual input in renewal/user information update process, we could add User accounts before having migrid accounts. Existing email addresses should be denied in sign-up for new accounts, and instead lead to sign in on a limited user area. If they can't remember password, they can renew. Once logged into user area, they can request either (A) a account renewal or (B) update of user information. The form input will then match existing values, and we avoid further issues.
jonasbardino commented 3 weeks ago

Thanks for summarizing the issues. There are some subtle details not entirely accurate or fully covered but the points stand.

We could additionally consider one or more of the following for external user accounts:

  1. integrate expire warning on Home or notification area of user pages
  2. integrate renew account access on user pages in order to make the authenticated request from there, which is recorded in the request and in turn leads to always accepting password changes when it's accepted.
  3. integrate password reset on user pages

We may still want to involve email with links (like password reset) or prompt for the existing password in 11+12 to help prove that it's really the owner sitting at the computer. The link to authenticated renew is already included in the expire warning email, so if users renew with that link before the account access expires, they are allowed to change password in the process. We might also want to trigger an email to the account owner when password was changed to at least warn about any hijacking, e.g. if the computer was left unlocked in public places.