Changes between Initial Version and Version 1 of Roadmap


Ignore:
Timestamp:
19.07.2011 00:18:56 (9 years ago)
Author:
JuergeN
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Roadmap

    v1 v1  
     1[[PageOutline]] 
     2= DeepaMehta Server Version 4.1 = 
     3 
     4== Implement User, Role, ACL, Security Concept == 
     5 
     6=== User Concept === 
     7 
     8Every 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 
     23Every user should have their own group (like in UNIX) 
     24 
     25=== Secure Passwords === 
     26 
     27Passwords should be stored securely, hashes with salt etc. (do research) 
     28 
     29=== Operations === 
     30 
     31Which operations does the server offer/allow on objects and associations? 
     32We 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 
     43Valid 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 
     54Roles should be assined to users and groups. 
     55 
     56 
     57=== Attributes === 
     58Every 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 === 
     71Every 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 
     77Questions: How do ACLs relate to edges? May one see the association to a hidden object? 
     78 
     79ACLs can be set on user and group level. 
     80 
     81=== Operation Control List === 
     82Especially 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.   
     83The operation is to a certain role:  
     84  
     85 * role: operation 
     86 * member: createInstance  
     87 
     88=== Locations === 
     89 
     90Operations could be limited through location address (localhost, 192.168.0.1, etc.), Just like in Apache or 'MySQL' 
     91Location shall be part of the Token to allow certain operations only from localhost, or IP XXX.YYY.ZZZ.ABC 
     92e.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 
     96Server creates Token for user and validates the token (like Kerberos or OpenAuth).