The content security model has undergone considerable change for Falcon. The new model allows access to be managed at item level, rather than at folder level, and also allows individual users to be granted access beyond what their group allows them. Different types of access can be defined and applied with specific levels. This gives a site builder expansive possibilities in managing access to a site.

Without further ado, here is the diagram for the new model:

The changes can be made by running the SIX Sexurity.sql script that comes with the Site Utilities.

Backward compatibility

Because the cms server is based on Smartsite COM technology, the new security system is kept compatible with the existing browse/manager access tools. This means that manager access is as yet handled only at folder/usergroup level. Browse access can be set at will according to the new system, but this may require manual database updates/inserts. No visual basic code was updated to enable the changes to the security model.

The technical implementation of backward compatibility is through an updatable view UserGroupAccessFolder. This view returns all entries from UserGroupContentAccess with AccessType "CMSBackCompat". Associated levels are the same as for Smartsite 5.2 (0=Browse, 1=List, 2=Add, 3=Edit). When items are deleted from or inserted into the view CMSBackCompat entries are removed or inserted in UserGroupContentAccess and Browse entries are set for the folder and its children.

Restricted

The new system requires user to have explicit permission to access content, this means that the restricted flag is no longer needed; everything is restricted by default. Items that were not restricted in the old situation get linked to all groups in UserGroupContentAccess. A trigger on the contents table ensures that Browse access is added for all groups when the resticted flag is dropped for an item.

Checking access

The vwContentAccess view combines all permissions from UserGroupContentAccess and UserContentAccess. This will be an enormous amount of data in any real world situation. This view should only be queried with bounds on the user and role(s), content items and access type.

As a user can be member of different groups, a user may be granted different levels of access to an item. The highest returned value should be considered leading, as the system grants access, it can't deny it.