LS2 Authentication & Permission Development: Difference between revisions
From LimeSurvey Manual
No edit summary |
(Marked this version for translation) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
<languages /> <translate> | |||
=General= | =General= <!--T:1--> | ||
=Internal Authentication= | =Internal Authentication= <!--T:2--> | ||
==Login== | ==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. | 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. | 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) | *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) | ||
| Line 14: | Line 17: | ||
*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. | *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?= | =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. | 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] | Please read up on [http://book.cakephp.org/view/171/Access-Control-Lists CAKE ACL] | ||
<!--T:9--> | |||
ARO: | ARO: | ||
*Rights can be assigned to groups and users | *Rights can be assigned to groups and users | ||
| Line 25: | Line 31: | ||
*Alias naming convention for ARO users: user::<User ID> model:user | *Alias naming convention for ARO users: user::<User ID> model:user | ||
<!--T:10--> | |||
ACO: | ACO: | ||
*Naming convention for ACO application function groups (define areas of the application): a<application area> | *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> | *Naming convention for ACO application single function (define a certain function of the application): s<function name> | ||
=User Security Groups= | =User Security Groups= <!--T:11--> | ||
<!--T:12--> | |||
Restrictions are posed by ACL (see above) | Restrictions are posed by ACL (see above) | ||
*Security Groups (can) have a single parent | *Security Groups (can) have a single parent | ||
<!--T:13--> | |||
Basic groups defined when installing the application: | Basic groups defined when installing the application: | ||
*Admins: | *Admins: | ||
<!--T:14--> | |||
+Complete system access using a super-admin right | +Complete system access using a super-admin right | ||
*Users: | *Users: | ||
<!--T:15--> | |||
+Can login (if the 'canlogin' field in the users table is set to true), can take assigned surveys. | +Can login (if the 'canlogin' field in the users table is set to true), can take assigned surveys. | ||
*Custom groups: | *Custom groups: | ||
<!--T:16--> | |||
+ACL allows to create new groups with custom rights. | +ACL allows to create new groups with custom rights. | ||
=Permission GUI= | =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. | There has to be a GUI created to explicetly change permissions of a security group or create/delete these. | ||
=Permission areas= | =Permission areas= <!--T:19--> | ||
<!--T:20--> | |||
The application has to be logically separated into permission areas, optionally with fine-grained read/write/... permissions. | The application has to be logically separated into permission areas, optionally with fine-grained read/write/... permissions. | ||
=Permission & Authentication= | =Permission & Authentication= <!--T:21--> | ||
<!--T:22--> | |||
Some authenticaction mechanism also provide permission data. In a first step this should not be considered | Some authenticaction mechanism also provide permission data. In a first step this should not be considered | ||
</translate> | |||
Latest revision as of 00:51, 9 April 2013
General
Internal Authentication
Login
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.
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?
LS2 is using CakePHP ACL to determine who gets access to what part of the application.
Please read up on CAKE ACL
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
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
Restrictions are posed by ACL (see above)
- Security Groups (can) have a single parent
Basic groups defined when installing the application:
- Admins:
+Complete system access using a super-admin right
- Users:
+Can login (if the 'canlogin' field in the users table is set to true), can take assigned surveys.
- Custom groups:
+ACL allows to create new groups with custom rights.
Permission GUI
There has to be a GUI created to explicetly change permissions of a security group or create/delete these.
Permission areas
The application has to be logically separated into permission areas, optionally with fine-grained read/write/... permissions.
Permission & Authentication
Some authenticaction mechanism also provide permission data. In a first step this should not be considered