Changes between Version 2 and Version 3 of doc/developer/UserRolesArchitecture

Show
Ignore:
Timestamp:
12/05/06 23:00:49 (14 years ago)
Author:
benoitg
Comment:

Update and clarify

Legend:

Unmodified
Added
Removed
Modified
  • doc/developer/UserRolesArchitecture

    v2 v3  
    11[[PageOutline]] 
    2 Original author: Benoit Grégoire, last modified: [[Timestamp]] 
     2Original author: Benoit Grégoire, last modified: 2006-12-05 
    33= New user permission architecture, General model = 
    44== Why our own rights and permissions framework == 
    5 Couldn't find one that allowed tying rights to instances of objects.  Otherwise, [http://www.gvngroup.be/doc/LiveUser/index.php LiveUser] would have almost done the trick. 
     5We couldn't find one that allowed tying rights to objects instances (and not classes).  Otherwise, [http://www.gvngroup.be/doc/LiveUser/index.php LiveUser] would have almost done the trick. 
    66 
    77== Stakeholders (Role and permission types) == 
    8 Each role and permissions (rights) are relevent to one of the following object type or static object: 
     8Each role and permissions (rights) are relevant to one of the following object type or static object: 
    99 * Node 
    1010 * Network 
     
    1717== Permissions == 
    1818Permissions are defined in the code, all in a big PHP lookup table to allow easy translations. 
     19{{{ 
    1920$PERMISSIONS['PERMISSION_ID'] = array(_("permission description"), STAKEHOLDER_TYPE); 
     21}}} 
    2022 
    21 These roles id's must also be listed in a database table for relationships.  The database table will be generated by a synchronization script to keep it in sync.  An elegant way to run it is probably to put unside te catch block of an exception when there is a mismatch, easing the maintenance burden (only code needs to be modified when a permission type is added or deleted) 
     23These roles id's must also be listed in a database table for relationships.  The database table will be generated by a synchronization script to keep it in sync.  An elegant to make sure it stays in sync is to run the script inside the catch block of an exception thrown when there is a mismatch, easing the maintenance burden (only code needs to be modified when a permission type is added or deleted) at no performance cost. 
    2224 
    23 En example of permission would be NODE_PERM_EDIT_METADATA.  Being a Node stakeholder type, the user who get's this permission gets to be allowed to edit the metadata of the specific node that this permission applies to. 
     25An example of permission would be NODE_PERM_EDIT_METADATA.  Being a Node permission type, the user who get's this permission (a node stakeholder) gets to be allowed to edit the metadata of the specific node instance that this permission applies to. 
    2426 
    2527== Roles == 
    26 Roles are administrator-definable group of permissions of the same type as the role (Node, Network, etc.).  For example, if we define the "Tech support" Node role, we can assign various Node permissions to this role, but only node permissions. 
     28Roles are administrator-definrd group of permissions of the same type as the role (Node, Network, etc.).  For example, if we define the "Tech support" Node role, we can assign various Node permissions to this role (but only node permissions). 
    2729 
    28 If we then assign some user "Tech support" role for a specific node, that user is a "Tech support" stakeholder for that node. 
     30If we then assign a user the "Tech support" role for a specific node, that user becomes a "Tech support stakeholder" for that node. 
    2931 
    3032=== User types (system roles) === 
    31 Wile administrators can define new roles, there is a need for a few SYSTEM defined roles that are always present.   
    32  * Anyone (annonymous)  
     33While administrators can define new roles, there is a need for a few SYSTEM defined roles that are always present.   
     34 * Anyone (anonymous)  
    3335  * maybe just special-case an ID, like SPLASH_ONLY_USER? 
    3436  * Exists for server, network, node, etc. 
     
    3739 * Users in validation 
    3840 
    39 User validity levels (Allowed, Validation, etc.) map to system roles 
    40  
    41 == Data model == 
    42 The different stakeholder tables list user-role pairs 
    43 Node (ex: curator) 
    44 Network (ex: login multiple times, edit other people content, access to Reusable content library, etc.) 
    45 Server 
    46 Content 
     41User validity levels (Allowed, Validation, etc.) will map to system roles, and may eventually be deprecated. 
    4742 
    4843== Groups == 
    49 To keep things simple, there is no concept of groups in the classic sense.  Roles allow doing much the same thing, and are simpler. 
     44To keep things simple, there is no concept of groups in the classic sense.  Roles allow doing much the same thing, and are simpler to implement. 
    5045         
    5146== Implicit permissions == 
    52 To keep things simple, defining implicit permissions (such as making NETWORK_EDIT_ANY_NODE imply NODE_PERM_EDIT_METADATA for each node) will not be supported.  While this is a desireable feature, implementing a simple UI for this is not easy, and since most permissions apply to specific objects, the code to check them would be complex and have low performance. 
     47To keep things simple, defining implicit permissions (such as making NETWORK_EDIT_ANY_NODE imply NODE_PERM_EDIT_METADATA for each node) will not be supported.  While this is a desirable feature, implementing a simple UI for this is not easy, and since most permissions apply to specific objects, the code to check them would be complex and have low performance. 
    5348 
    5449This means that when using permissions in the code, BOTH will have to be specified as allowed.  The API will be written to make this easy. 
    5550 
    56 Note that once again, properly defined roles do much the same thing.  (For example, a node owner can have a certain number of implicit permissions). 
     51Note that once again, properly defined roles do much the same thing.  (For example, a node owner can have a certain number of implicit node permissions). 
    5752 
    5853== Sudo support == 
    59 It would be extremely usefull to allow an administrator to masquerade as another user for testing pusposes.  Logging out would then get him back as the original user. 
     54It would be extremely useful to allow an administrator to masquerade as another user for testing and tech support purposes.  Logging out would then get him back to his original user.  As user handling is centralized, this should be reasonably easy to implement. 
    6055 
    6156= Handling insufficient permission = 
    62 In the comon case, missing permissions should be handled through exceptions, Caught in MainUI.  This will solve two annoying problems, while getting rid of just about all current permission error handling code: 
     57In the common case, missing permissions should be handled through exceptions, Caught in MainUI.  This will solve two annoying problems, while getting rid of just about all current permission error handling code: 
    6358        -If the user is not logged in (because of a timeout, or never logged-in), allow him to login. 
    64         -If the user doesnt have the necessary permission(s), inform him (telling which permission is missing) and allow to login as another user. 
     59        -If the user doesn't have the necessary permission(s), inform him (telling which permission is missing) and allow to login as another user. 
    6560In both cases, if the user successfully logs-in (with the rights permission), the get and post parameters are regenerated and the original operation is attempted again. 
    6661 
     
    6964 * where do we throw them 
    7065 * corner cases 
    71  * how doe we define the exceptions (One exception sub-object per type?) 
     66 * how do we define the exceptions (One exception sub-object per type?) 
    7267 
    7368= API = 
    74 Security ou User???::hasPermission($permission, $object_id) (object may be a singleton) 
    75 /** Allows the user to login if if not logged--in, or re-login if insufficient permission */ 
    76  
    77 Security::getUsersWithPermission($permission, $target_object); //Return list of users with this permission 
    78 Security::getUsersWithRole($role, $object_id); //Return an array of users with the given role.  If objects_id is null, all users with the specific role are returned, along with an array of objects for which they have this role.  Maybe this function won'T actually be implemented, as it's there mostly for reporting and sending notification of hotspots going down. 
    79 Security::getPermissions($user);  //returns array of PERMISSION constants for this user. 
    80  
    81 Security::hasPermission($permission, $target_object, $user);  //user is optionnal, if unspecified, the current user is used.  User can also be null, meaning that there is no user currently logged-in 
     69Security::hasPermission($permission, $target_object, $user);  //user is optional, if unspecified, the current user is used.  User can also be null, meaning that there is no user currently logged-in 
    8270Security::hasEitherPermissions(array $permission, $target_object, $user); 
    8371Security::hasAllPermissions(array $permission, $target_object, $user); 
    8472 
    85 Security::requirePermission($permission, $target_object, $user);  //These function return an exception and ultimately allow the user to login (or login as another user) to repeat hte operation 
     73Security::requirePermission($permission, $target_object, $user);  //These function are to be prefered to the previous ones, as they will throw exceptions to allow the user to login (or login as another user) to retry the operation 
    8674Security::requireEitherPermissions(array $permission, $target_object, $user); 
    8775Security::requireAllPermissions(array $permission, $target_object, $user); 
    8876 
     77Security::getUsersWithPermission($permission, $target_object); //Return list of users with this permission 
     78Security::getUsersWithRole($role, $object_id); //Return an array of users with the given role.  If objects_id is null, all users with the specific role are returned, along with an array of objects for which they have this role.  Maybe this function won't actually be implemented, as it's there mostly for reporting and sending notification of hotspots going down. 
     79Security::getPermissions($user);  //returns array of PERMISSION constants for this user. 
     80 
    8981= Data model = 
     82 
     83== Data model == 
    9084permission_type table 
    9185 * permission_id 
     
    10599 
    106100One table per stakeholder type 
     101Node (ex: Node tech support, Node owner, etc.) 
     102Network (ex: User allowed to login multiple times, Content curator (can edit other people content(, Content editor, etc.) 
     103Server 
     104Content 
     105 
    107106(object_type)_stakeholers 
    108107 * object_id 
    109108 * user_id 
    110109 * role 
     110Note that the stakeholder tables list user-role pairs (and NOT user-permission pairs) 
    111111 
    112112== Problems to be solved by this ==