Access Control and Security
Access Control Lists (ACLs) allow server and project administrators to easily manage access to the server and manage permissions in each space.
Groups can be created at the Server and the Project level to make permission management simple. It is also possible to refer to Groups defined in your Active Directory or LDAP server.
Users may belong to groups, and groups may belong to groups. Any given user inherits the sum of his or her "allow" permissions, minus any "deny" permissions.
The Server ACL Editor
In the server level ACL editor, you can assign server level permissions to individual users and to groups. Besides the typical permissions such as ability to Login and ability to access Server Setup as an admin, there are also permissions including whether a user can Access Address Book / User Profile information of other users, Edit Stylesheets (for customizations), Email content out of the server, or Export content from the server to PDF or WordML formats.
From this ACL Editor, you can easily access Project ACLs or see further detail regarding a given group's membership and their permissions.
The Space ACL Editor
Space permissions include whether an individual can read articles (or only read their own), comment, author, author via email, edit (or only edit their own), change labels once content is posted, create new labels, erase (or only erase their own) and manage the space. Space ACLs also include permissions for Moderation (Read Draft, Read History, Edit Locked, Lock, Publish, Publish Own)
The permissions are interesting (and exceptionally useful in enterprise contexts) when taken in combination. For example, I may only allow a group to read, comment and edit own articles. This group of users can then comment and edit only their own comments.
Here is the ACL List for the SalesDemo group in a space called HR. Most permissions are allowed to the group, but more sensitive permissions like Erase, Space Setup and Lock are held back. You can see that a group called Everyone (which is a system group consisting of all Named Accounts and Visitors) as well as three users (admin, jfrank and Einstein) may have different permissions.
Cross-Tagging to Extend Permission
You can use labels for many purposes in Traction (see Tags for categorization and social tagging). Relative to permissions, when you apply a tag from one space to an article in another space it extend visibility of the article to a wider audience.
In this case, the Engineering space's FYI tag is applied to an article in the Executive space.
As a result of the cross-tagging, the Executive space article is visible to the audience who can Read the Engineering space. It's like adding a tag to a piece of paper for someone's attention, or forwarding an e-mail. The Visibility dialogue here shows that user's Admin and Bob can see the article as a result of their membership in Executive and Engineering spaces. User Visitor (a system "user" representing anyone who has not logged with their own Named Account) can see the article as a result of at least having Access and Read permission to the Engineering space AND Access permission to the Executive space.
Access Permission as a Space Firewall
The Access Permission is used to enable or disable a user or group's ability to find out about a space's existence. If a user does not have Access permission to a space, then the space will not show in any lists and cross-labeling (as in the example above) will have no effect for that user.
In the example above, it was not sufficient for Visitor to have Read access to the Engineering space, Visitor also had to have Access permission to the Executive space. If Visitor were Denied or not Allowed the Access permission to the Executive space, then cross-tagging would have had no effect - the Executive article (and the Engineering FYI label on it) would be invisible to the Visitor.