Granular permissions

The AcuWeb security system was built from the ground up to allow incredibly granular control.  This is achieved by allowing an infinite set of ‘permissions’ in a hierarchical structure that can then be associated with individual users.

A bit of a mouthful, so let me use an example.  A common permission to give a user is the ability to Edit.

Now the first thing to note is that in many cases we don’t want to give a user the permission to Edit every page, just some pages.  And AcuWeb supports that because permissions can be modified on a per-page basis for each user.

The second thing to note is that we don’t necessarily want to give a User permission to edit everything we only want them to edit some things.

We therefore create a whole group of specific permissions, to let you specify exactly what you can and can’t edit throughout AcuWeb.  The problem with that approach is that you end up having to maintain literally hundreds of permissions per user, which would be a performance bottle neck, and a maintenance nightmare.

We get round that by defaulting a lot of permissions to their most common values.  For example if you have edit permissions on the configuration page, most users will want all the edit permissions.  We then only have to override permissions for specific users that we want to lock down.  The other trick we use is to assign permissions parents.  This creates a tree-like structure, where you have to have your parent’s & ancestor’s permissions before you can make use of specific permissions.

Why does that help?  Well, it means you can quickly switch on or off groups of permissions with one setting.  That makes administering and maintaining permission sets really easy.  These changes are then cached for quick retrieval on every page.

The system is designed to allow our users to add their own users (colleagues for example) as they go, but control who has access to do what.

Unfortunately, the user controls will not be in the initial release, as we plan on controlling users tightly in the first iteration of the system, but it will be a feature we will be adding later in the year if we see enough demand, the good news is that backend system supports it from day one, we’re just hiding the user interface for now.

3rd party integrations

The other big design goal for the AcuWeb security system was it’s ability to integrate securely and safely into 3rd parties.  We want this not only for our users, but for ourselves.  The demo account needed to integrate seamlessly into our DotNetNuke site.

To this end we’ve created a custom DotNetNuke module that can be used on any DNN sites to integrate AcuWeb.  One of the nice features of this is the ability for the DNN site to automatically create user’s in AcuWeb securely, and to synchronise passwords with it.

This means that when we push the go live button in the next day or so, you will log into AcuWeb straight from this site automatically, with your existing username and password.

This really is only an introduction to the security features in AcuWeb, but hopefully it’s enough to whet your appetite.  I know everyone’s growing impatient for the release, but it is literally only hours away now.  We’re just finishing up the DNN integration into our existing website now and will be performing some final end to end testing, then it’ll be time for everyone to start playing!

Don’t forget to comment and let me know what you think.