Internal access control to support partitioning the resource model

[ahonor]

Provide an access control scheme that allows users to organize models by distinct management realms.

• Current thinking is to create a "project" table to drive access control permissions against it
• Current access control is limited to actions
• Prefer "project" selection to be implemented at the access level with each project being completely separated
• Even the projects names need to be filtered by ACL

See #163.

[gschueler]

Implementation can be done with the spring-security-acl plugin http://burtbeckwith.github.com/grails-spring-security-acl/docs/manual/index.html.

allows us to:

• grant permissions: read,write,delete,admin,X,Y,Z
• for domain instances: e.g. a Project A
• to usernames or rolenames: 'bob', or 'ROLE_YANA_ADMIN'

Questions/considerations:

• current project actions map pretty easily to read,write,delete, or admin.
• when a new project is created what new permissions should be set?
  • obvious ones: admin for ROLE_YANA_ADMIN, ROLE_YANA_SUPERUSER
  • what about 'read' for ROLE_YANA_USER? and 'write' (but not delete) for ROLE_YANA_ARCHITECT?
• are we considering that all access to project components (nodes, types, etc) requires some ACL entry for the project? E.g. you need 'write' access to the project to modify/import nodes/types ?
• should we create new Roles for each project, to allow access? How will this work with LDAP-based authorization?
• do we need GUI stuff to define access control to projects? using spring-security-ui? http://grails-plugins.github.com/grails-spring-security-ui/docs/manual/

[gschueler]

also, what do you mean by "Even the projects names need to be filtered by ACL" ?

[ahonor]

Project names shown in a menu must be filtered based on the user's read-access privileges.

[gschueler]

ok, that is easily done with the acl plugin

[ahonor]

• ROLE_YANA_ARCHITECT is for managing any type-level definitions (NodeType, Attribute, Filter, NodeTypeRelationship).
• ROLE_YANA_USER is for read and write access instance-level definitions (Nodes/ChildNode/NodeValue)
• ROLE_YANA_ADMIN and ROLE_YANA_SUPERUSER need better differentiation or perhaps just be consolidated.

[gschueler]

ok, so current thinking is:

• use ROLE_YANA_ARCHITECT, and ROLE_YANA_USER roles to allow default access to all projects for particular aspects (type level vs object level)
• use grant/deny for particular users/roles for new permissions called "type","instance" to selectively add or remove permission on a Project

[gschueler]

base permissions for projects: read, write, create, delete, administration

• 'read' grants read permission to all objects in a project.
• 'write' allow modifying project details
• 'create' allow creating a new project (?)
• 'delete' allow deleting the project
• 'administration' grants all access to the project

new permissions for yana:

• 'architect', allows write/create/delete for all Type-level domain objects
• 'operator', allows write/create/delete for all Node-level domain objects

[ahonor]

+1