Access control

Libraries

This looks like a library which does a lot of what we need:

http://github.com/DocSavage/rails-authorization-plugin/tree/master

Introduction

Although some of these items do not appear to be directly about access control, they all incrementally lead toward a flexible and powerful set of access rights. Some existing structures such as client-project relationships are actually just a form of simple access control and should be generalised further.

1. Users and clients

Users and clients should exist in one database table. The difference between them should be their access level. This merging allows for a softer line between a client and a user. It may be that they are displayed separately in the GUI, but this should not be dictated by the database, since in other places they should be treated equally. This may simplify a fair amount of code, but require significant effort to refactor.

Use cases

• A customer (client) is be given access to manage their project, by creating tasks, viewing overall project history or completion status
• A contractor is associated with a separate company but is given access to certain project much like a user. However their access needs to be controlled like a client and contact details should be stored (like a client)

2. Companies

Clients should belong to a company. This should be many-many to allow clients to move between companies and still retain history. Even better, the company table should be merged with users and clients. Although at first sight this is unhelpful, some nice things come out of this approach: company→department→person (etc) is simple; access rights can be attached to either the company or the department or the person and flow down to the smaller entities, without

Use cases

• Organising large numbers of users (eg. in the thousands) where they should be grouped, searched or browsed by company
• Associating projects with a company rather than a user.
• Access rights which attach to a company
• Contact details for a company (saves repeating/updating details in each user)

3. Project/client many-many relationship

Currently it is only allowed to associate one client with each project. This relationship should be many to many since it is common to associate multiple clients with a project. This relationship is a form of access control, restricting a client to specific projects.

Use cases

• Commercial software development where more than one customer is using a product
• Wedding planning with caterer, florist, entertainment, venue, etc all contributing to the one project

4. Per object access control

At the moment access control is mostly per entity. That is, a user has the right to edit milestones, but there is no level of control over which milestones they can edit. The one object level control currently in place is control per project. While useful, this means it is not possible to have people included on a project who are able to view some tasks and not others.

Use cases

• Tasks which are security related should not be viewable except by the core development team, rather than everyone on the project
• A project might have several clients (eg. development of CIT), see item 3 above. In this case, it is not always suitable to share the details of each task with all those client, but in some cases it is helpful.
• Messages attached to a single task should be able to be marked as ‘private’. That is, a conversation may be happening with a customer within the task comments, but then the staff working on the issue wish to add comments to the task which are not viewable by the customer. This for us (ish) is absolutely crucial to our workflow. This idea somewhat overlaps with the current ‘send notification emails’ checkbox: that is, if the customer should not be notified perhaps they actually should have that information hidden from them.
• Likewise, certain attachments or specific wiki pages might be made public to all members of the project and hidden from others.

Implementation

Technically the schema is fairly simple: a superclass for all relevant objects which is able to store access control information. Vertical or horizontal inheritance are both possible implementation. (see this for further explanation: http://cayenne.apache.org/doc/inheritance-overview.html).

A more difficult issue is one of user interface. Access control is useless unless the user is able to quickly identify what level of access applies to every object. Otherwise embarrassing mistakes occur.
One option might be to allow setting access groups of users per project (eg. ‘staff’, ‘customer’, ‘public’) and then rights can be assigned with a popup per object (task, message, etc).
A background colour code (eg. yellow for private object, etc) could further enhance usability and give a clear indication of what objects are public and which are restricted.

Implementation

• AccessLevel is no longer per project, but across the entire company. This means that access levels could be a simple sorted integer enumeration.
• when determining access, the AccessLevel table is not needed at all. Simply grab the [AccessLevel]id which is stored in the AccessibleObject superclass. Then determine whether that id is in the list of access rights for the currently logged in user, against the appropriate entity.
• AccessLevel would still be used to colour the background of the accessibleObject to determine access level

The edit view is a quick mockup of the user interface for editing roles. Users can be given multiple roles and the concatenation of the highest level of access is given to them.

In this edit view, the role is given the ability to view tasks up to the level of ‘admin’, and read and edit ‘secret’ forums. This implies all lower level forums are also visible and editable.

!http://new.clockingit.com/sites/default/files/images/access admin.png!

Mockups

Role Editor

This mockup is an example of a role editor form. It shows two access levels – Internal and External. Each access level has a number of permissions for different types of object in ClockingIT. If the box is checked, people with this role will be able to read, edit, comment or delete an object.

This mockup demonstrates how access levels could be used to allow Internal staff to have tasks, comments and even projects that external clients can’t see. For example, this could allow internal staff to have a discussion about a task that isn’t seen by external clients.

Task Editor with Roles

This mockup shows the changes to the task edit screen that would be needed to accomodate roles and access levels.
1. The comment field has an extra option – “Access Level”.
2. The task itself has an extra option too. This is in the Target section for now, but could be moved anywhere.
3. Comments in history are displayed as normal, but with an extra field for their access level. Background colours could also be used to clearly show Internal/External (public/private) comments.

Only access levels that the current user has access to are listed. If only one, then the dropdowns can probably be hidden completely.