An early RC (or pre-RC) version of ODK Aggregate enabled site admins to
create their own groups (roles), and assign roles and permissions and users
to those groups.
This would have been a precursor to enabling a single ODK Aggregate to
serve different subsets of forms to different users, and to manage the
ability of users to collect, view or manage content at a form-by-form level.
I.e.,
_granted_authority_hierarchy:
dominating_granted_authority
( -> subordinate_granted_authority )*
-> role
Site admin can create any number of authority groups and manage assignments
of groups to roles. This is ODK Aggregate's backing table for the Spring
Framework object you are asking about.
i.e. userX might be assigned to two groups:
- "view formA dataset" and
- "manage formB dataset".
Site admin would configure the first group with ROLE_DATA_VIEWER primitive
permissions, and the second with ROLE_DATA_OWNER primitive permissions.
Not present in current implementation -- a many-to-many association table:
Form Assignment: (formId, groupId)
Site admin can assign forms to authority groups.
i.e., formA might be assigned to the group "view formA dataset" and
"manage formA dataset" Those two groups would have been specified in the
earlier table with ROLE_DATA_VIEWER and ROLE_DATA_OWNER primitive
permissions.
···
====================
Privileges for a given user:
at the Spring Framework layer, look up the groups and roles that a user is
assigned via the _user_granted_authority association table. Resolve all
groups down to the primitive roles assigned to them to get the UI tabs and
features that the user has access to for at least some form on the system.
This is automatically handled by Spring and the UI as-is.
===============
Not implemented:
Each UI tab has a different primitive permission associated with it.
We then would need to restrict the list of forms that are visible on that
tab.
To do that, for the primitive permission associated with that tab, invert
the hierarchy table to find all groups that enable that role. e.g., all
groups that were assigned ROLE_DATA_OWNER.
Take that set of groups and intersect it with the list of groups given to
the logged-in user (retrieved from the user_granted_authority table).
This gives the active set of groups that affect the display on that tab.
Intersect this against the Form Assignment association table to retrieve
the set of formIds that are visible on that tab.
=================
In any case, we gutted this part of the Site Admin functionality because it
would be too difficult to explain.
But, if you were to add per-form access management, enabling site-specific
groups via a dynamic role-hierarchy would be one way to do that. (but
there are other ways)
On Fri, Nov 6, 2015 at 2:10 AM, meletis@surveycto.com wrote:
Hi,
We can see that the class RoleHierarchyImpl in ODK Aggregate (
https://github.com/opendatakit/aggregate/blob/master/src/main/java/org/opendatakit/common/security/spring/RoleHierarchyImpl.java)
is a customized version of the original Spring class (
http://docs.spring.io/autorepo/docs/spring-security/3.2.4.RELEASE/apidocs/org/springframework/security/access/hierarchicalroles/RoleHierarchyImpl.html
).
Basically, the difference is that the customized class is reading the
hierarchical roles from a database table (and it also refreshes the
periodically), while the original Spring class maintains the hierarchy in a
in-memory map.
Could you please explain the rationale behind that custom implementation?
Wouldn't the original Spring class work? It looks like that the hierarchy
map never changes, right?
Thank you in advance,
Meletis
--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com