Alright, first, get rid of all your previous user management conceptions. It would also help to gain a basic understanding of Attribute-Based Access Control (ABAC), as I used some of the latest work being done on grid/web-service security access control to guide the design of the new system. Specifically, I want to be positioned to be able to adopt support for the emerging standards of SAML and XACML. But, enough justification and cursory background...
Let’s start with the idea of "Roles", which is no longer a way to link users to sets of permissions. The modUserGroupRole simply defines the level of authority a user holds within a Group, with 1 being the highest level of authority and 9999 the lowest (everyone has an authority of 9999, as the member of any modUserGroup).
Permissions are now defined by Policies. Policies are simple associate arrays (editable as a simple JSON string at the moment, though this is obviously not optimal) that can define any key/value combination to represent a permission (or attribute) which can be assigned to a relationship between an accessible object and a Principal (a generic term representing a User or a UserGroup). The manager interface currently only allows editing relationships between UserGroups and ResourceGroups (formerly DocumentGroups), but relationships directly between Users and Policies are also going to be possible.
So, for ResourceGroup permissions, consider you have a UserGroup related to a ResourceGroup and assigned a default Authority of 9999, and a Policy assigned to this relationship that consists of:
{
"create":true,
"remove":true,
"save":true,
"load":true
}
Theoretically then, you should be able to create a new Read-Only policy, defining it like so:
{
"create":false,
"remove":false,
"save":false,
"load":true
}
You’re in essence, simply saying UserGroup A with an Authority level >= 9999 (defined by a User’s Role within a UserGroup) has the Read-Only policy when accessing ResourceGroup A. When a user then tries to access a Resource that is in ResourceGroup A, the policy attributes the user has by nature of his (non-)membership in UserGroup A are compared to the policies that apply to the Resource and checks the attribute being queried (for reading a Resource, the "load" attribute is the one that would be checked) to make sure the User has the same attribute and the same value for that attribute.
The legacy manager permissions that define access to various pages and activities are controlled in the same way, except you assign these access control relationships between a UserGroup and a Context. I’ve duplicated all the permissions from the former Role table (not to be confused with UserGroupRole) as the Admin policy.
Of course, it seems the policy editor is now broken since the move to Ext2, so, I won’t be able to tell you how to add a new Policy until I get that fixed. So, let me get that fixed and you start asking questions from this brief overview of the new security framework.