View source for LS2 Authentication & Permission Development

<languages /> <translate>

=General= <!--T:1-->

=Internal Authentication= <!--T:2-->

==Login== <!--T:3-->

<!--T:4-->
On login a user is authenticated against different authentication mechanism - these authententication mechanisms can be set in his profile - the default authenticaction mechanism for a user is the LS internal one (username/password has stored in the users table) but it can also be set for example to only auth against LDAP. If a user manages to authenticate against one of the allowed mechanisms he/she may log in.

<!--T:5-->
If a user athenticates the first time against a non-DB authentication mechanism his user is created automatically in the internal DB.
*A non-DB authentication mechanism should be handled like a plugin and should be stored in the /plugins dir. Authentication mechanism plugin names have to start with the letters 'am' (for example: question types have qt)
*There should be a table where a new authentication mechanism is registered and so made usable to the application
*There should be a table which indicates wich user may use which authentication mechanism on login
*The authentication plugin should have a GUI which is able to be shown in the general settings - as a separate tab for each authentication mechanism - the settings dialogue has to be adjusted to load and show the tabs from the authentication plugins automatically.

=Permission - What areas does a user have access to?= <!--T:6-->

<!--T:7-->
LS2 is using CakePHP ACL to determine who gets access to what part of the application.

<!--T:8-->
Please read up on [http://book.cakephp.org/view/171/Access-Control-Lists CAKE ACL]

<!--T:9-->
ARO:
*Rights can be assigned to groups and users
*Alias naming convention for ARO groups:  <groupname> model:group
*Alias naming convention for ARO users:   user::<User ID> model:user

<!--T:10-->
ACO:
*Naming convention for ACO application function groups (define areas of the application):  a<application area>
*Naming convention for ACO application single function (define a certain function of the application):  s<function name>

=User Security Groups= <!--T:11-->

<!--T:12-->
Restrictions are posed by ACL (see above)
*Security Groups (can) have a single parent

<!--T:13-->
Basic groups defined when installing the application:
*Admins:

<!--T:14-->
+Complete system access using a super-admin right
*Users:

<!--T:15-->
+Can login (if the 'canlogin' field in the users table is set to true), can take assigned surveys.
*Custom groups:

<!--T:16-->
+ACL allows to create new groups with custom rights.

=Permission GUI= <!--T:17-->

<!--T:18-->
There has to be a GUI created to explicetly change permissions of a security group or create/delete these.

=Permission areas= <!--T:19-->

<!--T:20-->
The application has to be logically separated into permission areas, optionally with fine-grained read/write/... permissions.

=Permission & Authentication= <!--T:21-->

<!--T:22-->
Some authenticaction mechanism also provide permission data. In a first step this should not be considered

</translate>