Permissions Framework - Giving you precise control

Implementing permissions on published websites

Implementing permissions on your published websites couldn't be more straightforward. You simply need to update a couple of config settings to enable authentication and the permissions will kick-in. Having the permissions totally integrated within the CMS allows the contributors and managers of different sections to decide which content can surface.

We find that many projects no longer have a separate sense of intranet, extranet and website; they are all the same site. The only thing that separates them is the permissions you assign to different types of user.

We have shown an example page from the European University Institute, who run this model of website. If an article requires permission, the hyperlink or menu simply shows a padlock icon, if you are not logged in, you are sent to the log-on page when you try to access the content. If you are logged on and don't have permissions you will see the access denied page.

In many cases you actually don't want to show users the click through options if the user does not have permission; this is straightforward and is covered in more detail under 'Securing your Menus'.

Securing your Search

Using the Contensis standard or enterprise search, you can simply tick a box to enable permissions. Once you have ticked the box, the user doing the searching will only get the results they have permission to see. It is as simple as that.

If you want the results to be shown, but for the user to be sent to a call to action or access denied screen when they attempt access, just don't tick the enable permissions box.

Many search systems have problems when implementing permissions, especially when the permissions can be completely granular. The Contensis Search gets around this problem, and allows for a totally permission-sensitive search to be carried out.

Securing your Menus

If you want to know more about Menus then visit our section on Navigational controls. In this area we are simply highlighting that if you want to, you can enable permission checking on menus. This means that users logging in with different permissions will see different content in the site menu.

Many of our customers use this on their extranets to show certain information to clients and other information to suppliers. It is another simple method of personalising the experience to the visiting user.

Often you can use this functionality in conjunction with a CRM. If you know that your customer has purchased x level of membership, then give them permission to see all the documentation; whereas if they have a lower level of membership they can perhaps see less content. A simple CRM integration is all that is required to achieve this type of functionality.

Securing General Content

We have looked at hiding items using permissions from the menus and the search. The content side is the final piece of the puzzle. You can configure exactly which users and groups are able to see which content. This functionality relies on permissions being configured and is totally granular.

Enabling a Folder Password

Folder password protection is exactly what it says it is. You simply assign a password to a folder and thereafter anyone attempting access will be prompted to enter a password. This functionality is very useful when you want to give out blanket access to anyone with a password. The accounts will not lock and all you need is the password.

Often this is useful when you wish delegates from an event to be able to access a shared resource, or for a publisher publishing web resources when marketing a book. A simple password is all that should be required.

From the perspective of a content editor, permissions couldn't be more straightforward. Permissions are used to allow access to certain areas of the system, everything from editing to authorisation.

Administrators can choose which sections of the site a user has access to create, edit, authorise and delete new content or folders.

If the administrator decides, you may only see a single folder out of 10,000 in a CMS. The permissions are completely granular.

 

 

 

Page Element-Level Permissions

Even if you want to control permissions for editing element-level parts of a page, this is straightforward.

The most common requirement for this is on a website homepage. Normally we find that most homepages actually contain very little static data, as the homepages are fed from other sections of the site automatically. News and events are probably the most common and they both have full permissions enabled.

If you only want a single box or feature area to be controlled by specific individuals, then the quickest way to implement this is using HTML snippets or sub-templates.

Creating pages in this way ensures that the workflow, versioning and permissions can be controlled even down to a single paragraph.

HTML snippets and sub-templates are covered in more detail separately.

Groups/Roles

Groups, or roles as some people may like to call them, are an integral part of the permissions system. Normally when assigning permissions you will be assigning them against particular groups. These groups may have just been created in Contensis or could be groups that have been synchronised and already exist in your Active Directory .

The management of users in groups is very flexible; it can be managed through AD or through Contensis, sometimes even a combination of the two.

How these groups are managed will generally depend upon the dynamics and set-up of your internal IT infrastructure.

There are currently three different types of group:

Organisational Units

If you use our Who's Who module, organisational units can be used to group and categorise your staff into departmental structure within the organisation.

These groups can form a hierarchy of groups within groups.

We have shown a screenshot of how this hierarchy, created by user assignment, can then be used to power part of the search on our standard Who's Who module.

Security Group

Security groups are there purely for the purpose of permissions assignment; all group types can be used for permissions assignment, but this is the default type of group.

Community Groups

Community groups are there to support our Social Networking module.

Groups of this type indicate that the members are actually part of the group from a community perspective. They may have been invited to join by a group admin, or the group may have been open for anyone to join.

Any social networking user can create their own community groups.

Groups within Groups

Groups can be nested within groups to any level in much the same way as you have come to expect with services such as Active Directory from Microsoft.

Having group within group functionality makes permissions straightforward, flexible and scalable.

Group Integration

As standard, Contensis integrates with Active Directory. When a group is AD integrated it will show up slightly differently all over the system. An example has been demonstrated below.

You can use our API to integrate with any other group membership system. Previously, customers have integrated with CRM or even bespoke internal systems. Integration is straightforward.

In the case of the European University Institute, for whom we showed the Who's Who screenshot, they have integrated with their own internal Oracle database, which holds the data relevant to the departments of all staff.

This integration keeps a single source of the information to reduce duplication and prevent error.

Users

Users are probably one of the most important areas we can look at. Users are going to be at the heart of your content management system, making it come alive and deliver what your organisation requires from it. At the other end of the scale, users of the published solution, which may be an extranet, intranet or website, are all managed through the same user management interface, which gives you a high level of control and a simple approach to user management.

Because we are catering for both system users and end users, there is a lot of functionality available for users. 

• Self-updateable user profiles both through the CMS and website interface.
• Ability to opt-in and out of different system notifications both for traditional CMS purposes as well as activity from social networking and forums, as an example.
• Full user integration with any third party user management system that can be interfaced in some manner through .NET.
• Full native support for Active Directory synchronisation.
• User-level permissions available to assign to any piece of content.
• Personalised dashboards at CMS level, as well as full personalisation options.
• Google integration  for Google Mail, Docs and RSS.
• Who's Who integration to show and provide searchable interactive organisational staff or user directories.

When we are looking at users purely from a permissions perspective, we can assign any permission to an individual user, but more commonly we would assign permissions to groups of which users are a member.

Granularity

Permissions are entirely granular - the options are almost limitless