Authentication and Roles

Authentication

Password hashing, salts and authkeys

/config/auth.cfm generated by the installer contains a simple UUID which is used to encrypt the salts which are stored next to hashed passwords in the database. The idea being that each installation will have it's own auth key, and that you can invalidate all the passwords in the database by deleting and recreating this key.

Additionally, this hypothetically means an attacker would need to compromise both the database and the filesystem in order have a chance to do a brute force attack on the hashed password. You may want to store a copy of it somewhere just in case of accidental deletion. Passwords are hashed using SHA-512, and the (decrypted) salt.

Roles

Default Roles

There are four default roles, admin, editor, user, guest.

Each role can have various permission levels set depending on how you want your system to work. You could for instance, only allow view access to registered users, and creation permissions to editors, or force everyone to go through the approval process when creating bookings. How you want it to work is up to you. Some sensible defaults are included to start your off (essentially admins can do everything, editors most things except muck around with users and permissions, etc).

The Admin Role

You should really only have one, or at least a small number of admin users; as they can create and destroy accounts, keeping a tight leash on these accounts is recommended.

Editors and Users

Most of your users will be editors or users. Editors can approve bookings, so you'll probably want staff members / internal people to be editors; users might be external people or internal staff who are just interested in booking a room.

The Guest Role

The 'guest' role represents anonymous users; so denying access to the application to this role will essentially lock down everything to authenticated users only. Take care about opening all parts of the application up to the guest role. There's no spam protection on booking forms (for instance) and the application has not been penetration tested with that in mind. So perhaps limit Guest access to the read only parts (if appropriate).

Creating Additional Roles

You can add additional roles if required by simply creating a new column in the permissions table with the name of the role; the application should pickup the new role after a reload. However, you should be careful who you give permissions like 'assume user' to, as that could have security implications. Only an admin should have this. Make sure your new column is not the last or the first column to, as they will get skipped.