Users, Groups, Roles & Permissions

Overview

FarCry has its own in built security model and optional user directory. Users are assigned to Policy Groups or Roles. Each Role has a set of permissions. Permissions are additive.

User Directories

FarCry security model is designed to hook up to any user directory including FarCry's own internal directory, LDAP, Active Directory, OpenID and more. The user directory is solely responsible for authenticating the user's credentials (for example, username and password) and providing the list of groups the user belongs to.

Groups Map to Roles

When a user directory is configured for use with the FarCry framework, individual user groups are mapped to roles within FarCry. A particular group can map to multiple roles.

FarCry User Directory

FarCry framework has a user directory model combining users and associated groups. Unless you have an existing external user directory you need to hook up, the FarCry user directory should be ideal for the majority of requirements.

Role Based Security Model

FarCry Security is based on a roles model. When a user logs in the system determines what roles have been assigned for that user and from their determines the permissions available to that role. A user can ultimately belong to any number of roles and the permissions they have in the system are additive. That is, they have access to the aggregate of permissions encompassed by the roles they belong to.

Roles and permissions may be combined in any number of ways. Users can be assigned to any number of roles. Essentially when a user is authenticated the system determines all the roles a user has been assigned, and then allows access to any of the underlying permissions.

An important distinction to other security models is that roles based security is not solely hierarchical. In other words, Roles are not based on a series of access levels where the higher the level the more permissions in that domain. Of course, the roles could be designed to behave in that way, such as contributor -> publisher -> admin in the diagram. The approver role has some of the permissions of admin and publisher and none of those covered by contributor.

Default Roles

FarCry core ships out of the box with a pre-defined set of Roles and Permissions. These enable basic access to the webtop and other services such as defaults for the FarCry CMS plugin. These roles and permissions can be modified, deleted and added to as required.

• Default Security Roles

Permission types

Four permission types are available in FarCry. There is some overlap between them, but this section should clear them up.

General permissions

A 'general permission' is a simple grant/deny permission that is applied to a particular role. A fundamental 'general permission' is Admin. Roles that are allowed access to the webtop (e.g. SysAdmin) have it, roles that do not (e.g. anonymous) do not.

Permission set permissions

These are sets of general permissions that control how a role can interact with a content type. e.g. the news permission set is the set of permissions that control who can edit or delete news content.

The permissions in a permission set are Approve, CanApproveOwnContent, Create, Edit, Delete, and RequestApproval, and are named in the form #typename##permission#.

If a permission set has not been created for a content item, it is governed by the 'Generic' permission set.

Webskin permissions

Access to webskins is restricted by adding or removing webskin filters from roles. If a user is not granted access to a webskin, whether full page or page fragment, the deniedaccess webskin will be served instead.

This webskin can be overridden for all types, or for a specific type, the same way as a normal webskin. e.g. by adding a deniedaccess.cfm file to the dmNews webskin directory in your project, I can change what a user sees when viewing a restricted news item.

Object permissions

These permissions restrict access to specific content items. At present object permissions are only available on navigation nodes, and can be used to create member only sections of a website, or to restrict edit access to a particular department.