======================================== Absence Authentication and Authorization ======================================== Authentication -------------- Authentication (and authorization) was added in version 1.7. These are controlled by a number of configuration parameters. The install script should properly set up authentication, unless you want something exotic, in which case you will need to do some hacking. Two authentication methods are supported in v2.0: 1. "simple" -- user/password is provided in a CGI form and the password is sent in cleartext over the net 2. "http" -- standard http authentication. You can use whatever style your web server supports. I have tested with "Basic". Beware: "Basic" http authentication also sends cleartext passwords over the net! Please note: JavaScript is not required for an absence user, but it is nicer. However, if using authentication, an absence administrator *must* have JavaScript enabled. Otherwise the ACLs (access control lists) cannot be changed. Simple authentication --------------------- If you don't care much about cleartext passwords being sent over the network, this is probably the best for you. It is also the default. To use simple authentication set the following configuration parameter (the install script will do this for you): authentication => 'yes', auth_type => 'simple', secret => 'something-secret', credential_src => 'absence', session_timeout => '6h', manage_password => 'yes', pw_hash_format => 'md5', http authentication ------------------- BEWARE: I have not tested http authentication in v2.0. The text below is taken verbatim from the v1.8 README. Use this if you want to use the built-in authentication in http. The rest is up to you. If you are using Apache (and perhaps others), keep in mind that you must place the cgi-scripts in the hierarchy for which you have configured http authentication. This means you will probably want to create a cgi-directory underneath the absence data-directory. For example, if you are using /home/apache/cgi-bin for other cgi-scripts and you want to have absence under /home/apache/absence You will probably have to create /home/apache/absence/cgi-bin and configure a virtual path in apache that allows execution of scripts that reside in this directory. To use http authentication set the following configuration parameter: authentication => 'yes', auth_type => 'http', secret => 'something-secret', credential_src => 'absence', If you want to use absence to manage your passwords, also set manage_password => 'yes', Keep in mind that this means passwords will be sent in cleartext when you manage then from absence. Thus it makes no sense to use http "Digest" authentication and then manage your paswords with absence. If you're worried about such things, consider using SSL, or not using absence to manage passwords. If you choose not to manage passwords in absence, you will have to perform administration in two places, in absence, and wherever you keep your credentials (passwords). This may be ok. Authorization ------------- The objects that absence can manage are called "people", but they are not necessarily people. They could be computers, trucks, or anything else that needs to be scheduled. If the objects are in fact people, absence deals with them a bit differently than if they are not. In particular, objects that are people need passwords and ACLs associated with them. The configuration parameter objects_are_people allows you to control absences behaviour in this regard. If you set it to "yes", and authentication is enabled, an associated "user" object is created and linked to the "person" object. You may also want pure "users", (i.e., not associated with managed objects) who can authenticate themselves, view absence information, possibly modify absences, or administer the whole system. These are called "users". It is possible to start using absence without authentication, and enable it later. The data-format is backwards compatible. ACLs ---- In the following "user" means any "user" or "person", i.e., anyone who can authenticate herself to the system. The basic unit of display is a "group". Thus a "user" can have "read", "write", or "admin" permission for a group. "read" allows viewing of absence data. "write" allows creation, modification, and deletion of absences. "write" implies "read". "admin" allows creation, modification, and deletion of users, people, and groups, (subject to some restrictions) as well as everything that "write" allows. It is possible for a "user" to have "write" permission for an individual "person" (managed object), but this only makes sense if the "user" in question has a least "read" permission for the group in which the "person" resides. A person in a group always has "read" permission for that group. This applies to any groups to which the user belongs. The following ACLs can be used for managing access: group ACLs: Read: - read access to Write: - write access to Admin: - admin access to person ACL: Write: - write access to additionally there are some "magical" groups and people. For groups there are "all" and "self". "all" means all groups, and "self" means all groups to which a person belongs ("self" is not available for "users", because they are not managed objects). Thus if a person "george" belongs to the groups "sales" and "mgmt", the group ACL rule "Write:self" would mean the george has write permission for "sales" and "mgmt". For people there is only one "magical" person, "self", which, oddly enough, refers to ones own object. Thus a person could have only the person ACL "Write:self", which would mean the person would only be allowed to modify her own object. The rule "Admin:all" denotes a sort-of superuser, i.e., someone allowed to do anything. Users that have admin permission only for specific groups have restricted admin capabilities for the members of those groups. They can add members, and change existing members group membership for groups they control, and change group ACLs for the groups they control. They can also delete members, as long as a member in question does not belong to another group not under their control. Default Permissions ------------------- There are two configuration parameters for specifying what default ACLs a user or person should receive upon creation. These are (with reasonable defaults): pacl_default => '', gacl_default => 'write:self', The access-levels here can be abbreviated to the first letters, 'w', or 'r'. No defauilt for Admin is allowed. This allows any user in a group to change any user in a group to which s/he belongs. Only one default can be specified. There are not many configurations that make sense. If you want a restrictive policy where users can only modify their own objects, you would want to set: pacl_default => 'write:self', gacl_default => '', Which means users by default get write access to their objects, and no special access to groups to which they belong, which means they can only read (see) the other people in groups. The installation script provides for the creation of one or more users or people with administration permission. --------------------------------------------------------------------- Robert Urban July, 2009