Access control

DRG CMS has integrated a policy-based, two-level, role-based access control system. On the application level, the administrator defines roles that can view page elements and roles that are allowed to edit page elements. Users with roles allowed to edit are presented with a CMS menu at the top left of the browser window.

DRG CMS can handle multiple websites on a single Ruby on Rails instance. The administrator defines the default policy for each website. Default policy defines which roles (from defined user roles) are active on the website. Roles that are not defined in the website default policy document are ignored and treated as guests.

Database level (collection-level permissions) defines roles permissions on each collection. Similar to website policies, default collection permission must be specified (it usually defines that administrator can admin) and then specific permissions may be defined for each collection.

How do website level policies work?

Web site policies define user roles with:

• NO_ACCESS: Data will not be presented to user. Instead of data, the user may be presented with error text.
• CAN_VIEW: User has rights to view data.
• CAN_EDIT (or higher): User will be presented with a CMS menu on top of browser and will thus be allowed to edit data.

Web site policies are defined in the DcSite document. As a user with admin rights, go to the main CMS menu, choose User roles and click the new button. Then decide on a name for the new role. The name will be shown on the role selection fields. Every role also has a system name. 
System name defines an alias name for the role and can be used by your application consistently. In your application, you may define that only users with a specific role can perform some operation. But suppose you sell the application to a foreign country. Application administrators in that country may define a different name for the same role. By specifying the system name, you introduce a consistent name for the role.
One of the first roles that must be created as super admin is the guest role. You name role at your wish but write guest into the system name field.

After the roles are created, you must define their permissions on the website level. Since DRG CMS can handle multiple sites in a single Ruby on Rails instance, all roles that are valid for the site must be defined in the default site access policy. All other policies defined on the website will inherit from that policy.

Choose Sites in CMS menu and go to permissions tab. Create a new policy and name it ''Default policy''. Name it as you wish, but the set is as the default policy for the website, by selecting the ''is default'' field. You must also specify an error message that will be returned when a user is not allowed to access data (example ''Access not allowed!''). After saving the document, you can define policy rules for the policy. In policy rules, you define roles and permissions for the roles on the policy. For example: On default policy you define, that role "Editor" has EDIT permission for the site, ''Registered user'' has VIEW access, and ''Unregistered users (guest)'' role also has VIEW permission for the site.

When you want some pages or parts of the site to be visible only to registered users, first define a new policy for the site. Name it "Registered users only" and create a new policy rule where you will state that the "Unregistered users (guest)" role has NO_ACCESS. All other rules will be inherited from the default policy. Put "Only registered user can view data!'' in the error message field. Then, when editing page data, simply select the ''Registered users only'' access policy on the (page or part or menu) document.

All the programmer needs to do in the renderer method is something similar to this code:

Where @parent object points to Rails controller object and is sent as a parameter when renderer is instantiated.   (you get access to session and all form helpers) and @page represent page (or part) document.

Does all this sound complicated? Yes, it does. Because data access policies are always complicated. But they offload complications from users, who mostly don't know anything about data access policies, to website administrators and programmers who should know something about data access policies. There are CMS-es where users are forced to define ten different states (read, write, delete, .....) for every document. Multiply this by a number of roles and then multiply by the number of editors who enter data, and imagine how many errors can such a system produce.

How do collection level policies work?

Collection level permissions define granular access permissions for collections (tables) and are normally defined only for the roles (users) with CAN_EDIT permission on the site level. These permissions can be set to:

• NO_ACCESS: User has no access to documents in collection.
• CAN_VIEW: User can view documents but is not allowed to save any changes.
• CAN_CREATE: User can create new documents in collection
• CAN_EDIT: User can edit owned documents. User owns document if created_by field is present on a document and has the same value as user_id of the current logged user.
• CAN_EDIT_ALL: User can edit all documents in collection. This is also valid for a user with CAN_EDIT permission on a collection with no created_by field on a document.
• CAN_DELETE: User can delete owned documents.
• CAN_DELETE_ALL: User can delete all documents in collection.
• ADMIN, SUPERADMIN: At the moment there is no difference between these two permissions. They both allow the user to perform all operations on documents in collection.

When the user is presented with a data entry dialog through the cmsedit controller, the second level of rights comes into effect. These rights define granular, which operation can a user perform on a specified collection. Rights are defined in "Collection permissions" of CMS menu (dc_permissions collection). Like website policies, you have default permission, which must be set at the website initialization. Default policy defines that super admin user has SUPERADMIN rights to data. Without this, nobody (not even super admin) can enter any data through the cmsedit controller.

Each collection permission contains name of collection in lower case (''dc_site'' for DcSite model or dc_simple_menu for DcSimpleMenu model) and set of access policy rules, which define user roles and their permissions on collection. Permission can also be set for documents embedded in collections. For example, "dc_user;dc_user_role" can be used to define permissions to edit user roles documents embedded in dc_user collection.