Permissions are King, or Queen if you prefer...
Permissions govern the FirstClass universe. FirstClass is a Collaborative Communications Suite, and authentication and permissions govern access to all components of the system. Access is everything.
There are several types of permissions, but we are going to focus on two specific types: user and object. There are also group permissions which allow you to set permissions for a range of users and objects. In certain circumstances, you will encounter the words, "preferences" or "priveledges" with what amount to a few permissions buried in a mix of status labels and access limits. We won't cover every permission (especially for the user), but our hope is to show you how the permissions structure works and enable you to deal with them as you find them.
This article references the following forms:
First of all, let's talk about Access Control:
"Access Control" is computer security-speak for defined permissions. Basically, it combines a user, an object, and an action, and then determines whether or not the user can perform the identified action on that object. Regardless of the action chosen, the end result is a binary, yes/no decision. You can either view the object or you cannot. You can either delete the object or you cannot. There is no maybe.
This concept is then abstracted to groups. Instead of referencing a single user, you reference a group to which users can belong. Once a user is added to the group, that user "inherits" the permissions that have been assigned to that group. This is a management trick -- it's far less time consuming to make global changes in a single location than it is to change every single user one at a time. This structure is not simply restricted to objects; you can define permissions for access, storage limits, protocols, self-management, etc.
The complications set in when we consider the various ways to implement Access Control. One of the first hurdles is to determine whether we are dealing with Most Restrictive or Least Restrictive structures. Those two terms have very specific meanings in the computer security world, but we are using them here to highlight two very distinct methods of assigning permissions.
Consider the following example:
You are a generic user logged into a generic system, and you want to open an object. Based upon your user permissions, let's assume that you have been given permissions to open that object. No problems so far. Now let's assume that you have been made a member of a group that has its own assigned permissions, and one of them is that you are restricted from opening that object. We are now in a situation where you have two sets of permissions defined by that system's Access Control, and they are in conflict. One says you can, the other says you can't. What does the system do?
With Most Restrictive permissions, the system will choose the "can't" over the "can." You will be denied access to that object, even if you have six groups allowing you access and only one restricting you. With Least Restrictive permissions, the system will choose "can" over "can't." You will be granted access to that object, even if you have six groups restricting your access and only one allowing you. Most "public" systems (those intended for open communication) follow the Least Restrictive model, which makes sense. New abilities can be added, but old abilities are rarely taken away.
FirstClass is also Least Restrictive... sort of.
What do you mean, "sort of?"
The best way to describe FirstClass permissions is Least Restrictive Contextual, which means that FirstClass follows the Least Restrictive method most of the time and for most limits and actions, depending upon context. The context to which we refer is where those permissions are actually set, and in some cases in which order they are set.
User permissions in FirstClass are primarily concerned with access and scope rather than a specific action on a specific object; they deal in generalities. When specified at the user group level, these permissions are universally Least Restrictive. In the event of a conflict, feature access will always translate to feature enabled, access and connection limits will choose the higher value, directory views will be most inclusive, and storage space will be the maximum set number. When permissions are specified for the user, however, the explicit values on the User Detail form trump all. No matter what the group association, FirstClass will always follow any explicitly set User Detail form values over all else.
User permissions are fairly straightforward in this respect, and the only real issue is understanding what kind of access and limits you want for your users. It gets a bit complicated once you start dealing with Subadministrators, but the simple rule of thumb is that a Subadministrator can do whatever they want, so assign that role wisely. Also, be careful not to confuse permissions with preferences. The time zone preference, for example, is not a permission, nor is the preference of whether or not to broadcast your login state to the directory. Whether or not you can change your password is a permission (specifically an access permission), even though it appears under the header "preferences."
Object permissions, such as conference and calendar permissions, behave in much the same way. Just as with user permissions, object permissions can be set in a permissions group or explicitly for individual conferences and calendars, and at the lowest level you can override group-defined values. Object permissions are considered Most Restrictive, however, because you cannot pass inherited values along once you set explicit permissions. Whereas explicitly stated user permissions can modify only a single permission and leave the rest untouched, explicitly stated object permissions modify all object permissions for a given object.
Now, let's get to the odd bit:
There are two very important things to remember when dealing with explicit object permissions. Firstly, and permissions explicitly set on the object will override any and all pre-existing object permissions for the scope of the container and its contents. Secondly, and even more importantly, the order of entry is essential. We've touched upon the first issue earlier in this article, but the second one requires more explanation.
When you set conference permissions, the users and groups with the most permissions must be listed first. This goes for explicit conference permissions and object permissions set in permission groups. Controllers must be listed prior to Creators, Contributors before Readers, and Disallowed needs to be right down at the bottom. If you fail to do this, you will run into unpredictable conference behavior. If at a later date you need to add somebody to the middle, you can add them at the bottom (which is your only choice), set their permissions, and then click-and-drag that entry up the list to its proper place.
|