"Fossies" - the Fresh Open Source Software Archive

Member "absence-v2.1/README-AUTH.txt" (10 Jun 2012, 7492 Bytes) of package /linux/www/web-absence-2.1.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 
    2 
    3 ========================================
    4 Absence Authentication and Authorization
    5 ========================================
    6 
    7 Authentication
    8 --------------
    9 
   10 Authentication (and authorization) was added in version 1.7.  These are
   11 controlled by a number of configuration parameters.  The install script
   12 should properly set up authentication, unless you want something exotic,
   13 in which case you will need to do some hacking.
   14 
   15 Two authentication methods are supported in v2.0:
   16 
   17 1. "simple" -- user/password is provided in a CGI form and
   18     the password is sent in cleartext over the net
   19 
   20 2. "http" -- standard http authentication.  You can use whatever
   21     style your web server supports.  I have tested with "Basic".
   22     Beware: "Basic" http authentication also sends cleartext passwords
   23     over the net!
   24 
   25 Please note: JavaScript is not required for an absence user, but it is
   26 nicer.  However, if using authentication, an absence administrator *must*
   27 have JavaScript enabled.  Otherwise the ACLs (access control lists)
   28 cannot be changed.
   29 
   30 
   31 Simple authentication
   32 ---------------------
   33 
   34 If you don't care much about cleartext passwords being sent over the
   35 network, this is probably the best for you.  It is also the default.
   36 To use simple authentication set the following configuration parameter
   37 (the install script will do this for you):
   38 
   39 	authentication  => 'yes',
   40 	auth_type       => 'simple',
   41 	secret          => 'something-secret',
   42 	credential_src  => 'absence',
   43 	session_timeout => '6h',
   44 	manage_password => 'yes',
   45 	pw_hash_format  => 'md5',
   46 
   47 
   48 http authentication
   49 -------------------
   50 
   51 BEWARE: I have not tested http authentication in v2.0.  The text below
   52 is taken verbatim from the v1.8 README.
   53 
   54 Use this if you want to use the built-in authentication in http.  The rest
   55 is up to you.  If you are using Apache (and perhaps others), keep in
   56 mind that you must place the cgi-scripts in the hierarchy for which you
   57 have configured http authentication.  This means you will probably want
   58 to create a cgi-directory underneath the absence data-directory.  For
   59 example, if you are using 
   60 
   61 	/home/apache/cgi-bin
   62 
   63 for other cgi-scripts and you want to have absence under
   64 
   65 	/home/apache/absence
   66 
   67 You will probably have to create
   68 
   69 	/home/apache/absence/cgi-bin
   70 
   71 and configure a virtual path in apache that allows execution of
   72 scripts that reside in this directory.
   73 
   74 To use http authentication set the following configuration parameter:
   75 
   76 	authentication  => 'yes',
   77 	auth_type       => 'http',
   78 	secret          => 'something-secret',
   79 	credential_src  => 'absence',
   80 
   81 If you want to use absence to manage your passwords, also set
   82 
   83 	manage_password => 'yes',
   84 
   85 Keep in mind that this means passwords will be sent in cleartext
   86 when you manage then from absence.  Thus it makes no sense to
   87 use http "Digest" authentication and then manage your paswords
   88 with absence.  If you're worried about such things, consider
   89 using SSL, or not using absence to manage passwords.  If you
   90 choose not to manage passwords in absence, you will have to
   91 perform administration in two places, in absence, and wherever
   92 you keep your credentials (passwords).  This may be ok.
   93 
   94 
   95 Authorization
   96 -------------
   97 
   98 The objects that absence can manage are called "people", but they
   99 are not necessarily people.  They could be computers, trucks, or
  100 anything else that needs to be scheduled.
  101 
  102 If the objects are in fact people, absence deals with them a bit
  103 differently than if they are not.  In particular, objects that are
  104 people need passwords and ACLs associated with them.  The configuration
  105 parameter
  106 
  107 	objects_are_people
  108 
  109 allows you to control absences behaviour in this regard.  If you set it
  110 to "yes", and authentication is enabled, an associated "user" object
  111 is created and linked to the "person" object.
  112 
  113 You may also want pure "users", (i.e., not associated with managed
  114 objects) who can authenticate themselves, view absence information,
  115 possibly modify absences, or administer the whole system.  These are
  116 called "users".
  117 
  118 It is possible to start using absence without authentication, and enable
  119 it later.  The data-format is backwards compatible.
  120 
  121 ACLs
  122 ----
  123 
  124 In the following "user" means any "user" or "person", i.e., anyone
  125 who can authenticate herself to the system.
  126 
  127 The basic unit of display is a "group".  Thus a "user" can have "read",
  128 "write", or "admin" permission for a group.  "read" allows viewing
  129 of absence data.  "write" allows creation, modification, and deletion
  130 of absences. "write" implies "read". "admin" allows creation, modification,
  131 and deletion of users, people, and groups, (subject to some restrictions)
  132 as well as everything that "write" allows. It is possible for a
  133 "user" to have "write" permission for an individual "person" (managed
  134 object), but this only makes sense if the "user" in question has a
  135 least "read" permission for the group in which the "person" resides.
  136 
  137 A person in a group always has "read" permission for that group. This
  138 applies to any groups to which the user belongs.
  139 
  140 The following ACLs can be used for managing access:
  141 
  142 group ACLs:
  143 
  144 	Read:<group>	- read access to <group>
  145 	Write:<group>	- write access to <group>
  146 	Admin:<group>	- admin access to <group>
  147 
  148 person ACL:
  149 
  150 	Write:<person>	- write access to <person>
  151 
  152 additionally there are some "magical" groups and people.
  153 For groups there are "all" and "self".  "all" means all groups,
  154 and "self" means all groups to which a person belongs ("self" is
  155 not available for "users", because they are not managed objects).
  156 Thus if a person "george" belongs to the groups "sales" and "mgmt",
  157 the group ACL rule "Write:self" would mean the george has write permission
  158 for "sales" and "mgmt".  For people there is only one "magical"
  159 person, "self", which, oddly enough, refers to ones own object.
  160 Thus a person could have only the person ACL "Write:self", which would
  161 mean the person would only be allowed to modify her own object.
  162 
  163 The rule "Admin:all" denotes a sort-of superuser, i.e., someone allowed
  164 to do anything.
  165 
  166 Users that have admin permission only for specific groups have
  167 restricted admin capabilities for the members of those groups.
  168 They can add members, and change existing members group membership
  169 for groups they control, and change group ACLs for the groups
  170 they control.  They can also delete members, as long as a member
  171 in question does not belong to another group not under their
  172 control.
  173 
  174 Default Permissions
  175 -------------------
  176 
  177 There are two configuration parameters for specifying what
  178 default ACLs a user or person should receive upon creation.
  179 These are (with reasonable defaults):
  180 
  181 	pacl_default   => '',
  182 	gacl_default   => 'write:self',
  183 
  184 The access-levels here can be abbreviated to the first letters, 'w', or 'r'.
  185 No defauilt for Admin is allowed.
  186 
  187 This allows any user in a group to change any user in a group to which
  188 s/he belongs.
  189 
  190 Only one default can be specified.  There are not many configurations
  191 that make sense.  If you want a restrictive policy where users can
  192 only modify their own objects, you would want to set:
  193 
  194 	pacl_default   => 'write:self',
  195 	gacl_default   => '',
  196 
  197 Which means users by default get write access to their objects, and
  198 no special access to groups to which they belong, which means they can
  199 only read (see) the other people in groups.
  200 
  201 The installation script provides for the creation of one or more
  202 users or people with administration permission.
  203 
  204 ---------------------------------------------------------------------
  205 Robert Urban <urban@unix-beratung.de>
  206 July, 2009