0



13Jan2011

What is an ACL?

Have you ever wondered what  an ACL in Fatwire really is?

I have seen countless times, when a customer have to create a user,  that he gets lost when he sees the following option:

The common reaction is just  to select everything and move on...

Not a great choice in term of security.

Also, very often customers do not distinguish well ACLs from Roles.... They often think they are the same thing.

So, if you have this problem, read on...

So, what is  an ACL, anyway?

First and before all, an ACL is just a symbolic name describing a set of permissions.

ACL are configured in the SystemACL table.

You can see existing ACLs  looking into the SystemACL table itself.  If you try to edit, for example, the PageEditor ACL, you will see something like this:

PageEditor ACL

PageEditor ACL

Now, think to this set like a set of actions you can execute against a database table.

You can read a specific row, search in it,  create or update a row. Also, as a special permission, you can read the revision tracking (that is basically a log of the modifications) and edit them (removing old revisions).

Ok, they are CRUD permission. What now?

So far an ACL just describes permissions you have on a single database table. But how do you associate a permission to a database table?

The secret is the SystemInfo table: give a look to the following snapshot, taken using ContentServer Explorer:

SystemInfo with ACL

SystemInfo with ACL

As you can see, each table  is protected by  an ACL.  And the ACL describes what you can do with that table,  if the user accessing to the table has that ACL.

So, here how actually ACL works:

First, you are identified:

  1. If you did not use any password, you are the DefaultUser, and have the ACL of the DefaultUser.
  2. Otherwise, you was identified  using an username and password, and you have now the ACL associated to that username.

Second, this is what happens:

  1. Whatever you do, at some point you will try to do an action against a  database table
  2. The system checks if you have one of the ACL associated to the table. If not, access is denied
  3. If yes, the system checks if the ACL  allows you to do the action you require. If not, access is denied.
  4. Otherwise, you will be able to execute the required action as the logged on user.

So basically, ACL protect database tables. They are a very low level feature.

They have nothing to do with Roles, that is a CMS concept (a more elaborated and very different feature).

Hmm, what   already defined ACLs mean?

Here a few random notes taken looking at the standard  SystemInfo configuration:

- a ElementReader can read  the ElementCatalog  while an ElementWriter can modify it. Writing the ElementCatalog is usually required only for developers.

- a PageReader can read the SiteCatalog while a PageWriter can modify it. SiteCatalog configures cache , so accessing it is required mostly to a system administrator (or  to a developer that configures cache and permissions)

- SiteGod is present everywhere allows can do everything, so it is a very dangerous to give this permission. Normally is there only for maintenance reasons.

- xceleditor is required to access to the CMS tables, so any user  in the editorial team requires it.

Posted by admin
13Jan2011