Changes between Version 1 and Version 2 of Roadmap


Ignore:
Timestamp:
20.07.2011 15:19:47 (9 years ago)
Author:
JuergeN
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Roadmap

    v1 v2  
    22= DeepaMehta Server Version 4.1 = 
    33 
    4 == Implement User, Role, ACL, Security Concept == 
    5  
    6 === User Concept === 
    7  
    8 Every operation in DeepaMehta should be done by an identified user. Users (and groups) should be handled through UID (and GID) 
    9  
    10  
    11 {{{ 
    12  SYSTEM 
    13    | 
    14   root  
    15    | 
    16   user(n) 
    17    | 
    18  anonymous 
    19    | 
    20  nobody(?) 
    21 }}} 
    22  
    23 Every user should have their own group (like in UNIX) 
    24  
    25 === Secure Passwords === 
    26  
    27 Passwords should be stored securely, hashes with salt etc. (do research) 
    28  
    29 === Operations === 
    30  
    31 Which operations does the server offer/allow on objects and associations? 
    32 We need to define a list of valid operations for Topics Associations and ~Types. Those are: 
    33  * create (createTopic / createAssociation / createTopicType / createAssociationType) 
    34  * update/modify 
    35  * delete 
    36  * get/read (by ID/Value) 
    37  * search/scan 
    38  * navigate (what's related?) 
    39  * still missing: equals/compare(true/false) 
    40  
    41 === Roles === 
    42  
    43 Valid operations should be defined/idenfied through roles (via Tokens), like 
    44  
    45  * SYSTEM 
    46  * administrator 
    47  * creator 
    48  * owner 
    49  * member (workspace) 
    50  * peer/manager/editor 
    51  * everyone (=every user) 
    52  * anonymous 
    53  
    54 Roles should be assined to users and groups. 
    55  
    56  
    57 === Attributes === 
    58 Every object should have a set of inherent attributes ( which may be properties or associations), e.g. 
    59  * create time 
    60  * modify time 
    61  * access time 
    62  * not property: creator -> association 
    63  * not property: owner -> association 
    64  * ro 
    65  * not property: hidden -> association (viewable e.g. based on context) 
    66  * private (interface shortcut for ACL) 
    67  * isolated (=object cannot be associated) (insterface shortcut for ACL) 
    68  * not property: label -> association -> name/label 
    69  
    70 === Access Control Lists === 
    71 Every object (nodes and edges) shall have inherent ACLs (properties) to define permissions on this object.  
    72  * Group A: read only (ro) 
    73  * Group B: read write (rw) incl. delete 
    74  * everyone: read only (ro) 
    75  * user(n): associate (a) (create an association towards this object) 
    76  
    77 Questions: How do ACLs relate to edges? May one see the association to a hidden object? 
    78  
    79 ACLs can be set on user and group level. 
    80  
    81 === Operation Control List === 
    82 Especially for TopicType and WorkSpace, we need to define who may do what by role and operation on the object. It defines e.g if  user may create or search an instance of an object, user may join a certain workspace, create (and send) an email (function) or in general who may use domain specific functions.   
    83 The operation is to a certain role:  
    84   
    85  * role: operation 
    86  * member: createInstance  
    87  
    88 === Locations === 
    89  
    90 Operations could be limited through location address (localhost, 192.168.0.1, etc.), Just like in Apache or 'MySQL' 
    91 Location shall be part of the Token to allow certain operations only from localhost, or IP XXX.YYY.ZZZ.ABC 
    92 e.g. when uploading a file it is important to know if you work on localhost (just add a link) or if working on a remote server then open upload dialogue. 
    93  
    94 === Token === 
    95  
    96 Server creates Token for user and validates the token (like Kerberos or OpenAuth).  
     4 0. SecurityFeatures