Security in Casbah is loosely based on the Unix security model, as well as the ACL model of the Andrew File System (AFS). Users exist in realms: "user-name@realm". Realms are useful for creating multiple, distinct user databases or to allow disparate authentication systems which might not be maintained by the Cairo server administrator.
The string "user-name@realm" must be unique on a server, that is to say that realms must be unique, and users must be unique withen realms.
Users must be able to belong to an infinite number of groups. Groups must be able to contain an infinite number of users. [1]
Cairo itself never trusts a realm. Objects trust realms through their Access Control Lists. Realms have no special privlages as objects, and therefore are not a security hole.
Each object in the Casbah Virtual Namespace has its own Access Control List (ACL). The ACLs can be inherited through aquisition. They are stored in the object under the name "__cb_acl__". Any child object will inherit the permissions of its parent (and its parents, and so on) until it is explicitly overridden.[2]
Each realm is an instance of the class CasbahSecurityRealm, and the realm name must be the name of the object instance. Realm names may be either an absolute address in the Casbah Virtual Namespace or a name containing no "/" characters. An example of an absolute address is "/site/config/security/realms/editors". The first character of an absolute address must be "/". Realms that do not begin with "/" must have "/site/config/security/realms/" prepended to it prior to processing. This allows a "shorthand" notation for system-administrator controlled realms.
Each realm is responsible for its users and groups. A realm may use any authentication schemes, from the simple [3] to the complex [4] Realms should utilize Shariff object instances to perform authentication. Shariff objects are similiar to PAM (Pluggable Authentication Modules) modules. Shariff object instances can be likened to lines in a PAM config file naming the PAM module and its arguments.
When Cairo receives a request to authenticate a user into a realm, it will start a conversation with the appropiate realm. This conversation object will hold all of the state information required by the realm itself and the Shariff objects contained in it. Each converstion object must be placed in "/tmp/security/conversation" id. Each conversation object must have the following ACL.
Table 1. Table Needs a Name
User | Real | Access Mode |
|---|---|---|
n/a | n/a | 0 |
--realm-auth-user | realm-name | 127 |
This ACL defines two entries. The first one states that all users not named in this ACL are denied access. It does this by using an empty string for both the user and the realm names. [5] The access mode is 0, which denies all access. The second entry grants access to the realm itself. Every realm should reserve the user "--realm-auth-user--" for the realm to use. The realm should place its realm name in the realm slot, rather than the string "realm-name". It should also grant itself full access by setting the access mode to 127.
| [1] | Despite practical considerations, these values must not be arbitrarily bounded. |
| [2] | Credit for acquisition goes to? python guy? newtontalk? |
| [3] | For example, checking that the username is nonzero |
| [4] | For example, checking a password, the ip address, that the username is on an "approved" list to login, and that the user's brainwaves match those of the brainwave scan taken at an earlier point in time. |
| [5] | An empty string in an ACL matches everything. |