Implement User, Role, ACL, Security Concept

pageOutline(1-3,List of Topics on this page,inline)?

DeepaMehta needs an enhaced permission control system (PCS). Security needs to be implemented at the server back end and all access must be authenticated, e.g. through tokens. The client-server communication should be secured by TLS/SSL. For the special needs in the context of DeepaMehta we cannot apply strict ACL or OCL lists. Due to the nature of DeepMehta? a combined ACL and OCL approach in regard of the workspaces must be implemented into the PCS.

User Concept

Every operation in DeepaMehta should be done by an identified user. Users (and groups) should be handled through UID (and GID)

 SYSTEM
   |
  root 
   |
  user(n)
   |
 anonymous
   |
 nobody(?)

Every user should have their own group (like in UNIX)

Secure Passwords

Passwords should be stored securely, hashes with salt etc. (do research)

Operations

Which operations does the server offer/allow on objects and associations? We need to define a list of valid operations for Topics Associations and ~Types. Those are:

• create (createTopic / createAssociation / createTopicType / createAssociationType)
• update/modify
• delete
• get/read (by ID/Value)
• search/scan
• navigate (what's related?)
• still missing: equals/compare(true/false)

Roles

Valid operations should be defined/idenfied through roles (via Tokens), like

• SYSTEM
• administrator
• creator
• owner
• member (workspace)
• peer/manager/editor
• everyone (=every user)
• anonymous

Roles should be assined to users and groups.

Attributes

Every object should have a set of inherent attributes ( which may be properties or associations), e.g.

• create time
• modify time
• access time
• not property: creator -> association
• not property: owner -> association
• ro
• not property: hidden -> association (viewable e.g. based on context)
• private (interface shortcut for ACL)
• isolated (=object cannot be associated) (insterface shortcut for ACL)
• not property: label -> association -> name/label

Access Control Lists

Every object (nodes and edges) shall have inherent ACLs (properties) to define permissions on this object.

• Group A: read only (ro)
• Group B: read write (rw) incl. delete
• everyone: read only (ro)
• user(n): associate (a) (create an association towards this object)

Questions: How do ACLs relate to edges? May one see the association to a hidden object?

ACLs can be set on user and group level.

Operation Control List

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. The operation is to a certain role:

• role: operation
• member: createInstance

Locations

Operations could be limited through location address (localhost, 192.168.0.1, etc.), Just like in Apache or 'MySQL' Location shall be part of the Token to allow certain operations only from localhost, or IP XXX.YYY.ZZZ.ABC 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.

Token

Server creates Token for user and validates the token (like Kerberos or OpenAuth).

Since the need evolved to associate/store various tokens from third party services with a deepamehta-identity/user, i did a bit of research on oauth and gathered some resources around this topic on the OpenAuth-Page. Basically the oauth tokens can be stored opaque to the client/user but i wonder if that would be a good idea in a multi-user environment, so we possible need a encrypt/decrypt mechanism also for such access/refresh_tokens.