Access Control for anyMeta

What is access control?

With access control we define who can do what with which content. For example, when you requested this page the access control system checked if you were allowed to view the article. It also checked if you are allowed to change it, and if you are allowed to react to this article. When you were not allowed to react, then you wouldn't see the react form underneath this article.

Every access control list entry consists of three parts:

• who is requesting access (a guest, an editor, etc.)
• what the requestor wants to do (view, edit, delete, etc.)
• on what the requester wants to it (an article, photo, etc.)

In short, using the terms we use internally:

• the requestor (aro - access requestor object)
• the action (aco - access control object)
• the subject (axo - access extensible object)

Access control for a semantic network

A semantic network (and with that anyMeta) is in essence a directed graph, consisting of nodes and the connections between them. The nodes are articles, keywords, people, images etc. The connections give meaning, like identifying an author, a figure for an article etc.

When you want to change the text of a node, say the title of this article, then you need edit access. For deleting you need delete access.

The basic actions on a node are:

• view
• create
• edit
• publish
• delete

To add a connection between two nodes you need:

• link access on the subject
• linkto access on the object

The link and linkto access is differentiated per predicate. So it might be possible that you are allowed to add a figure to a document, but are not allowed to add the same document to a blog as a blogposting.

In anyMeta we call a node a thing. As in “everything is a thing.”

Content groups (nodes/things)

Every node is associated with a content group, also named axo. The basic content groups we define during installation are:

• public for content that everybody can see. This is also the content group of most content made by members of a site.
• protected for content that is only visible for authenticated users (think of an intranet)
• metadata here we place all keywords, predicates and types. Readable by everybody but editable by a chosen view.
• templates here we place all templates, css and javascript files. Readable by everybody but editable by, for example, the webmaster and the designer.

Requestors (users)

To prevent that we have to make seperate access control entries for every single user we assign per user one of the limited list of requestor objects.

The requestor objects are placed in groups and for those groups we define the access control rules. The most important requestor objects we install are:

• guest
• member
• editor
• sysadmin

Trust permissions - “my friends may do more with my stuff”

People work together, in their workplace, hobby, and nowadays also on websites. On those sites you have friends, colleagues and people you have never heard about. In anyMeta you can define who you know and who is your friend by linking to them from your person record. For the link you can use the predicates friend or knows.

In general I trust that the people I know will be careful with my belongings. From this general understanding of people knowing each other and because of that also trusting each other we derived the concept of trust permissions.

For every thing you own you can define if your friends can also edit it. Or can add links, or comments. Even if only your friends can see it.

You can give rights to more people than just your friends:

• everybody (even anonymous visitors)
• members of the site (that is everyone who is able to log on)
• people you know
• your friends (at least the people you call your friend in the website)
• you

For security reasons it is not possible to give edit or link rights to anonymous visitors. You can only give react and view rights to visitors. Besides that you can not borrow rights to someone when you don't have the right yourself.

There is something funny with giving rights to others, especially when you consider the implications for the underlying access control mechanism. For example, it should be possible for an administrator to edit everything, regardless of the trust permissions.

When you look careful at the implementation of the trust permissions than you will see that (for performance reasons):

• the trust permission view removes view permission from others as given by the ACL
• the trust permissions edit, link and react gives permission to others above the ACL

So when the ACL gives me edit permission, then you are not able to remove it from me using your trust permissions. On the other hand, when the ACL gives me view permission then you can hide it from me by using your trust permissions. To prevent editorial disasters we also know the super view right enabling the administrators to see everything from everyone.