Authentication

[AlyceBrady]

Complete the authentication module, which is currently a stub.

[AlyceBrady]

Local authentication is partially implemented, although local passwords are not yet encrypted. External authentication (e.g., LDAP, Active Directory) is not yet supported. Once it is, will need to configure application.ini to specify whether using a local user file or Active Directory, and update installation instructions accordingly.

Note that ramp_auth_users may be used in different ways, and part of the difference will be whether the application is using internal or external authentication. If the former, ramp_auth_users must include passwords, whereas no local passwords are needed if the application is using external authentication. In either case, ramp_auth_users provides the association between usernames and roles needed for authorization. [ramp_auth_users may also be providing basic identifying or contact information, such as name, email address, etc, unless the application has another table used for that purpose, such as the Person table in Smart.]

Ideas concerning Password Management & Initial DBA Password if Salting

• Possible Idea: Ship Guest with DBA role, use to create DBA user account(s), DBA then immediately changes Guest role to guest
• OR Ship DBA with blank password; DBA sets email address from mysql prompt as part of initialization?; Blank passwords always serve as temporary passwords that just get one to the change-password password page
• Forgot password? If solution to that is emailing a new password to an email address then if someone hacks someone else's email then they can change the password on their university account. If solution is that DBA sets password to null or empty string, then what validation is required (in-person, over-the-phone)?
  Self-serve recovery from forgotten password is always nice; what are best practices?

More thoughts:

• If ramp_dba users (users assigned to ramp_dba role) can view and modify ramp_auth_users and ramp_auth_auths from within Ramp, then the single Ramp MySQL user account must have all permissions on all tables, including those two. Ramp ACL's would have to be set up to make sure that only users in the ramp_dba role can view or modify those tables. (Currently the table settings are set up so that the dba cannot modify the password through Ramp, although the ACL's would allow it.) Another design decision would be to not allow modification of those tables from within Ramp; the Ramp MySQL user account would not have those permissions but another MySQL user account (not used by Ramp) would have those permissions.

[AlyceBrady]

Internal authentication is now complete, but Ramp still does not support external authentication (e.g., LDAP authentication).

Design decisions:

• New users (including DBAs when accounts first created) are given a default password. This causes RAMP to redirect the user to a Set Password screen the first time they try to log in. There is now an Active? field in the Users table, so new users can be created as Inactive to reduce the chance that a malicious user will come in and set the password before the new user has a chance to do so. The new user should be set to Active just before they are expected to use the system for the first time.
• For now, users who forget their passwords will have to contact their DBA who can validate that it is the right person and then reset the password to the default password (necessitating the user to immediately set a new password). Ramp is not currently providing self-serve password recovery, and it might not even be possible since the unencrypted password is not being stored anywhere.
• The Table controller is now prohibiting the adding or editing of passwords in the Users file via standard Ramp actions. Instead, users are added without a password (causing the default password to be added), and they must change their password via an explicit Change Password action. This is built into the Table Controller and so is not dependent on well-behaved table settings.