Bric::Security - Bricolage Security Guide.
$Revision: 1.1.1.1.2.2 $
$Date: 2001/12/04 00:37:34 $
This guide describes the security features of Bricolage. These features comprise three parts: authentication, encryption, and authorization. Authentication is the process that allows users to login to Bricolage. Authorization is the processt that checks the permissions on individual objects before allowing users to access them. And encryption allows users to securly connect to Bricolage.
Bricolage's authentication procedure is designed to be simple yet flexible. To login to Bricolage, simply hit any URL on the server. If you have not already logged in and cached a session, you will be prompted to login. Bricolage remembers your URL, so that when you successfully login, it will redirect you to the URL you'd originally attempted to hit. To login, simply enter your Username and password, and then click "Login". Note that the Username is case-insensitive, while the password is case-sensitive. If your enter the wrong username and/or password, you'll be prompted to login again. Once you have successfully logged in, you may begin using Bricolage.
When you are done using Bricolage, you should always log out. While your session will eventually expire, it's always best to logout and quit your browser to prevent others from accessing Bricolage in your name. To logout, simply click the "Logout" button that's available at the top of every Bricolage screen. Once you've logged out, you'll be presented with the login screen again so that you can relogin if you need to. But to prevent others from using the back button and other clever (and not-so-clever) tricks to view your data.
There are a couple of system configuration directives that affect user authentication. All System directives are documented in Bric::Admin; however, we'll discuss a few that are relevant to authentication here.
First, the directives LOGIN_LENGTH and PASSWD_LENGTH affect the minimum lengths of usernames and passwords, respectively. These lengths are then enforced in the application UI. The more important of these is PASSWD_LENGTH, since the longer the password, the more difficult it is to crack. Be sure to set this directive to as high as users will bear -- preferably 8 or higher (the default is 6).
Note that there is no maximum password length. Passwords can be any length and contain any characters. This is because Bric passwords are stored in MD5 hashes, rather than the simple crypt format used by other applications. Users are thus encouraged to use passphrases rather than simple passwords. Again, you can enforce this to some degree using the PASSWD_LENGTH configuration directive. We have set an arbitrary limit of 1024 characters on the password length in the UI, on the simple assumption that no one is going to use an essay for a password. There is no such actual limitation in the API.
The maximum login length, on the other hand, is 128 characters. We made it this long to accommodate those environments where email addresses (which are potentially quite long) must serve as logins. We expect that most users would never user more than ten characters.
The other two authentication directives, AUTH_TTL and AUTH_SECRET, affect how a user's login session is maintained. AUTH_TTL the length of time, expressed in seconds, that an idle user remain logged in to Bricolage. That is, if a user is logged in, but is idle for longer than the time allowed by AUTH_TTL, when next the user tries to use Bric, he/she will be forced to reauthenticate. This feature helps prevent unauthorized access by people using a computer when a user has neglected to logout. We recommend you set it for some reasonably low period of time -- two hours or less. The default is 8 hours.
AUTH_SECRET is a random string of characters that is used to encrypt a user's login session in a login cookie. The login session is encrypted to prevent malicious people from figuring out from cookie data how to login to a system. If such a person were to discover the the value of the data stored in AUTH_SECRET, that precaution would be compromized. We therefore recommend that you change this value periodically -- say every couple of days or once a week.
Bricolage can use the industry-standard Secure Socket Layer (SSL) for connection encryption. See Bric::Admin for information about enabling SSL in Bricolage. With SSL enabled, Bricolage automatically uses SSL for all logins and for all user profiles. By doing so, Bricolage assures that users' passwords are never sent over the Internet in the clear. When users login to Bricolage, their passwords are encrypted, and when users and administrators edit User profiles within the application itself, the profiles are edited via SSL so as to ensure that any password changes are also sent via encrypted channels.
All other parts of Bricolage use simple HTTP rather than SSL (HTTPS) for sending data to and from the browser. SSL is not preferred in the application in genereral because encryption encurs a significant performance overhead. A lot of processor time has to go into encryping and decrypting all data sent to and from the browser when using SSL; and in some Bricolage profiles, that can be a lot of data!
There may be times, however, when you wish to use SSL everywhere in Bricolage. Perhaps someone is working on a sensitive story via the Internet, rather than on a LAN, and the story data needs to be encrypted, Or perhaps company policy dictates an emphasis on high-levels of security (such as may be the case with patient data in health care), and therefor preventing data from ever being sent in the clear over the Internet. Bricolage makes it a simple proces to use SSL for connecting to and using Bricolage at all times.
The simplest way to enable an encrypted connection is to check the "Use SSL" checkbox on the login screen. Checking this button causes Bricolage to maintain an SSL connection to the browser even after login. But it's not necessary to use this checkbox. If at any given time you wish to establish an encrypted connection to Bricolage, simply change the address in you browser from "http://" to "https://". That's all you need to do to turn on encryption. Note, however, that if you use this approach and then you edit a user profile, once you have saved the changes to the user profile, Bricolage will return you to a normal, unencypted connection. This is because Bric checks the status of the "Use SSL" checkbox to determine whether or not a user has been using SSL before editing the user profile. Thus the preferred way to establish a secure connection is to check the "Use SSL" checkbox. To return to a normal, unencrypted connection, logout, and then log back in with the "User SSL" checbox unchecked.
The authorization features of Bricolage comprise two parts: authorization itself and permissions management. The Bricolage authorization system is designed to be relatively simple to use and understand, although its emphasis on groups of objects rather than objects themselves can cause a little consternation until the idea clicks. Here we discuss the philosophy and functionality of aturhorization in detail, so that you can always return to this document if you're having trouble.
In order to keep implementation as straight-forward as possible -- and therefore to also save processing time during uthorization checking, we designed Bricolage to have only one kind of permission. That permission is best expressed by this sentence:
"Grant permission to the members of a group of users to access the members of a group of objects."
The advantage of this approach is that all permissions are stored in one place, and therefore can be quickly looked up, thus saving processor time when checking for authorizations. The disadvantage is that one cannot simply grant permission to an individual user to an individual object or group. One can, however, create a user group with one member, and an object group with one member, and then grant the permission to the single user group to access the single object group. So the granularity can still be acheived, but without violating the elegance of the model.
[Implementation Note: For those who want object-level permissions granularity without going to the trouble of creating groups manually, in a future version we may wish to consider implementing such a thing, but using the same group interface. That is, whenever someone wanted to set an individual permission or two an object, the API would automatically create a group for that object and make it the only member. The drawback to this approach, however, is that we could end up with a lot of groups. But it's worth thinking about if this functionality is really in demand.]
Bricolage supports four permission levels: READ, EDIT, CREATE, and DENY. READ permission allows users to view the contents of objects, but not edit them. EDIT permission allows uesrs to both view and edit the contents of objects and to delete objects, but not create them. CREATE permission allows users to view, edit, delete, and create objects. Note that the CREATE permission can only be granted for objects in the "All *" series of groupes, as an object are automatically members of its respective "All" group, but can't be addded to any other group until they've alreay been created. And finally DENY permission prevents users from accessing objects at all.
As you can see, the permissions cascade. EDIT assumes READ, CREATE assumes EDIT and READ, and DENY overrides all the rest.
Naturally, users may have more than one permission granted an object due to their membership in multiple groups. Likewise, a particular object may be in more than one object group to which a user group has been granted permission, and there may be different permissions assigned to the different groups. This crossing of permissions requires permission reconcilliation. The way multiple permissions are reconciled basically follows the cascading nature of the permissions themselves: the most permissive permission wins. Thus if a user has both READ and EDIT permission to an object, the user will have EDIT access to the object. Likewise, if a user is granted CREATE and EDIT permission, she will have CREATE access to the object. And of course, the user with no permissions at all will have no access to the object at all.
The one exception to the "most permissive wins" rule is the DENY permission. Bricolage assumes that if the members of a group have been assigned the DENY permission, then they really should have no access at all, regardless of what other permissions they may have by nature of their memberships in other groups with other permissions. So remember, while in general the most permissive permission wins out, the DENY permission trumps all. The lesson is: use this permission with care.
So lets look at a few examples. Let us assume that we're working with a system with 3 users, 3 user groups, 2 story groups, and 3 stories. Here's how they're organized:
Users All Users Story Admins Evildoers
----------------------------------------------------
Theory x x
Mcnibblet x
DrEvil x x x
Story All Stories Good Stories
------------------------------------------------------
Dubbya Celebrates Birthday x
Second Matrix Movie Debuts x x
Black Hole Destroys Earth x xNow, let us assign permissions:
All Stories Good Stories
---------------------------------------------
All Users READ EDIT
---------------------------------------------
Story Admins CREATE
---------------------------------------------
Evildoers DENY
---------------------------------------------The way Bricolage works with these permissions is that, when a user tries to access a particular object (here a story object), Bricolage finds out what groups the object is in, what user groups have been granted permissions on those groups, and which user groups the user in question is a member of. Then, once it has aggregated all of the permissions that trickle down to the user in questionk, it decides which one wins, following the criteria outlined above.
So let's say that user "Theory" wants to create a new story. Bricolage sees that the new story is in the "All Stories" group, and that the user groups "All Users," "Story Admins," and "Evildoers" have been granted permissions to that group. It turns out that Theory is a member of the "All Users" and "Story Admins" user groups. The permissions granted to these groups to access members of the "All Stories" group are "READ" and "CREATE," respectively. Bricolage determines that CREATE is the highest-value permission, and so user Theory has that permission, and therefore the ability to create a new story.
Another expamle. Let's say that user "Mcnibblet" wishes to edit the "Dubbya Celebrates Birthday" story. Bricolage detemines that this story is a member in only one story group, "All Stories," to which the user groups "All Users," "Story Admins," and "Evildoers" have been granted permissions. Mcnibblet, being the member of only one of these groups, "All Users", leaves just the one permission: READ. Thus, Mcnibblet has READ permission to the "Dubbya Celebrates Birthday" story, and no other permission. Since Mcnibblet wishes to edit the story, and he does not have EDIT or CREATE permission, he is prevented from editing the story. Should he choose to view it, however, he'd be able to do so.
Now let's look at "DrEvil." This fine user wishes to view th story "Black Hole Destroys Earth," it being that it appeals to his aesthetic tastes. Bricolage determines that this story is a member of the "All Stories" and "Good Stories" story groups, and that all three user groups have been granted permissions to "All Stories," and "All Users" has been granted permission to "Good Stories". DrEvil, in turn, is a member of all three groups. Thus, the permissions for DrEvil to access the "Black Hole Destroys Earth" story are READ, CREATE, EDITY, and DENY. Comparing these permissions, Bricolage would normally award the most permissive permission, CREATE (which encompasses READ and EDIT permissions, as well). However the DENY permission trumps all others. Thus, regardless of DrEvil's membership in the "Story Admins" group, with its CREATE permission to access the story, his membership in the "Evildoers" group denies him permission to access the story at all!
Here's a breakdown of how all the permissions will manifest for each user trying to access each story. Compare this table with the tables above to figure out how the permissions were deterimined.
Story Theory Mcnibblet DrEvil
------------------------------------------------------
Dubbya Celebrates Birthday CREATE READ CREATE
Second Matrix Movie Debuts CREATE EDIT DENY
Black Hole Destroys Earth CREATE EDIT DENYFinally, we should discuss one special user group in the System: Global Administrators. Members of this group automatically have CREATE rights to every object in Bricolage, regardless of other group memberships and permissions -- including DENY! In fact, permissions aren't even checked for members of this group - CREATE permission is simply always assumed and granted. The name and permissions of the Global Administrators group cannot be edited, either - only the membership. Thus memberhip in this group should be limited to just those users who are responsible for administering the whole of the Bricolage application. Use the other Administrator groups to parcel out the rights to Administer particular parts of the application.
Now that we've explained how the permissions system works, let's examine the interface, and how to use it to configure permissions for your users.
All permissions management takes place within group profiles. As you can tell from the above dicussion, there are two slightly different kinds of groups, at least as far as permissions management is concerned. The two types are User Groups and Object Groups. All groups in the system are object groups. These are the groups to which user groups are granted permissions. Thus even user groups are object groups, since there need to be permissions granted to manage users, too.
So let's browse the interface. In the side navigation bar, select ADMIN -> SYSTEM -> Groups. You will be presented with a list of all the groups in the system. Bricolage ships with only User groups, but if you look at the "Or Pick a Type" select list, you can see that it supports all kinds of object groups. (Note that the special "All *" groups are not editable.) Click "Edit" to edit one of the user groups, say "Alert Type Managers" (note that you must have permission to edit groups to do this!). The interface provides fields to edit the name and descriptio of the group, plus a double list manager that allows you to move objects (in this case users) in and out of the group. The doble list manager allows you to assign members to the group.
Since we're most interested in permissions management, however, click the 'Permissions" button. This interface allows you to edit all of the permissions granted to the the members of the group, plus the permisisons granted to other gruops to access the members of this group. If you're looking at the "Alert Type Managers" group, you'll be presented with four separate sections of permissions.
Take a look at Number four, "User Group Permissions," first. These are the permissions granted to the members of user groups to access the members of the Alert Type Managers group. By default, none are granted, but if you were to click the "READ" radio button for the "Media Procucers" row and then click "Save," for example, then all users who are members of the "Media Producers" user group will then have READ access to the users who are members of the Alert Type Managers group. (This is probably not something you want to do!)
A note on the interface. By default, Bricolage uses radio buttons to display the permissions. Some may not care for this interface, however (some think it too cluttered), so Bricolage offers an alternative. There is a preference, "Permissions Widget," that can be changed from its default value "Radio Buttons" to the alternative, "Select List." This setting will cause Bric to offer select lists for each row of the Permissions page, rather than radio buttons. To change the preferene, simply edit the "Permissions Widget" profile in the Preferences Manager. Be sure you have permission to edit preferences, and remember that they are global and will affect how all users see the Permissions interface!
Now, scroll back up to the top of the Alert Type Managers Permissions page. The first section "Object Group Permissions," allows you to grant permission to the members of the Alert Type Manager group to access the members of other groups. Here you'll see all of the "All *" groups listed (the only groups for which you can grant CREATE access, incidentally) as well as all the other gruops in the system. You can use the radio buttons or the select list interface to grant the permissions. Note that by default, the Alert Type Administrators have been granted permission only to CREATE All Alert Types.
The second section, "Workflow Permissions," allows you to grant permissions to the members of the current group (Alert Type Administrators) to access the assets within particular workflows. This feature is useful to allow certain groups of users to access assets only in certain workflows.
The third section, "Desk Permissions," allows you to grant permissions to the members of the current group (Alert Type Administrators) to access the assets on particular desks. This feature is useful to allow certain groups of users to access assets only on certain desks.
These first three sectcions of permissions will likely be your most used, but they appear only when editing the permissions of user groups. The fourth section, "User Group Permissions," is the only section that appears in the permissions management screen for all group profiles. We belive that this section will be most useful when creating a new group, when it makes more sense to associated the group with user groups all at once, rather than edit the user group profiles invidividually to grant permissions on your new group.
Once you click "Save," and return to the group profile, the new permissions setting will have been saved. Click "Save" again to keep any changes made to the group profile name, description, or membership. From this point on, the permissions will be set and all users will be updated. They do not have to login again in order to gain new permissions.
David Wheeler <david@wheeler.net>
perl(1), Bric (2).