Adding group features to aggregate - help

Hey,

Just trying to stir the pot and see if anyone has any thoughts on this.
Also, I was told I should try to get the attention of a person named Mitch
who has done this before. So, Mitch, if you're out there, I'd love to know
your thoughts.

Thanks,

John.

··· On Thursday, September 27, 2012 5:52:09 PM UTC-6, John Etherton wrote: > > Hello everyone, > > I'm working on a project to add groups to aggregate. This way both users > and forms would belong to one or more groups. Users from Group A could only > view/edit the forms that were also under Group A, and so forth. I think > this is pretty straight forward, just add a table in the DB for groups, and > then add one that maps users to groups and one that maps forms to groups. > But I'm new to Tomcat/beans and very new to things like Spring Security. > > So my question is, is it really as simple as I hope, or will rewrite some > stuff to get the various frameworks at play to work with this change? > Should I try to enforce separation of groups through Spring or should I do > that myself? Are there any other things I should be aware of when > implementing such a change? > > Thanks a lot, > >

Hi John -- thank you for the work you did with javarosa and cascading
selects!

The 'group' functionality is all already there, but not the
groups-have-access-to-forms functionality.

The current security model is governed by 2 tables:

_user_granted_authority -- maps users to the groups they belong to.
NOTE: super-user is also granted the ROLE_SITE_ACCESS_ADMIN privilege
in this table (so that if they ever are removed from all groups, they still
have site admin privileges).

granted_authority_hierarchy -- hierarchy of groups and, eventually, the
privileges (roles) assigned to those groups. Privileges are identified by
"ROLE
" prefix.

A very early alpha allowed for user-defined groups, but we stripped that
functionality out of the UI and restricted the user interface to just the 4
groups (Data collector, Data viewer, Form Manager, Site Admin). The
underlying tables, however, still have that capability.

The biggest issue with adding user-defined groups is that the UI and
service code would need to be rewritten to allow for more than these
assumed 4 groups. This means not passing GrantedAuthorityName across the
interface, but passing group name strings across. And you would probably
want a table mapping the group name to a friendly description (like what
GrantedAuthorityName does).

You would then need to add a 3rd table to define what groups have which
privileges for a given form (GRANTED_AUTHORITY, FORM_ID, PERMISSION) where
you would need to also introduce the notion of access permissions to a form.

And then implement checks in all the service and servlet methods to verify
that the logged-in user belongs in one or more groups that have the
appropriate permissions for that form. This can be done via:

-----------------------begin snippet
CallingContext cc;

// grants from _user_granted_authority table
Set directAuths =
cc.getCurrentUser().getDirectAuthorities(); // immutable

RoleHierarchy rh = (RoleHierarchy)
cc.getBean("hierarchicalRoleRelationships");

// get the expanded grants from a closure of directAuths with
_granted_authority_hierarchy
Set allUserAuths =
rh.getReachableGrantedAuthorities(directAuths); // mutable set...

// new method you implement on Form instance...
// gets all groups/privileges granted the needed permission on this form.
Set tableAuthsGrantedPermission =
form.yourMethodToAccess3rdTableForAuthsWithPermisson(permission);
// NOTE: this is likely an immutable set (cached in memory)

allUserAuths.retainAll(tableAuthsGrantedPermissions); // intersect

if ( allUserAuths.empty() ) {
// user didn't have any of the permissions necessary for the access...
throw new AccessDeniedException("you do not have the permissions to ___
this form");
}
-----------------------------end snippet

Mitch

··· On Thu, Oct 4, 2012 at 8:50 AM, John Etherton wrote:

Hey,

Just trying to stir the pot and see if anyone has any thoughts on this.
Also, I was told I should try to get the attention of a person named Mitch
who has done this before. So, Mitch, if you're out there, I'd love to know
your thoughts.

Thanks,

John.

On Thursday, September 27, 2012 5:52:09 PM UTC-6, John Etherton wrote:

Hello everyone,

I'm working on a project to add groups to aggregate. This way both users
and forms would belong to one or more groups. Users from Group A could only
view/edit the forms that were also under Group A, and so forth. I think
this is pretty straight forward, just add a table in the DB for groups, and
then add one that maps users to groups and one that maps forms to groups.
But I'm new to Tomcat/beans and very new to things like Spring Security.

So my question is, is it really as simple as I hope, or will rewrite some
stuff to get the various frameworks at play to work with this change?
Should I try to enforce separation of groups through Spring or should I do
that myself? Are there any other things I should be aware of when
implementing such a change?

Thanks a lot,

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Thanks Mitch. I might have some more questions, but for the moment
you've given me a lot to go on.

John

mailto:john@ethertontech.com

··· On 10/04/2012 05:52 PM, Mitch S wrote: > Hi John -- thank you for the work you did with javarosa and cascading > selects! > > The 'group' functionality is all already there, but not the > groups-have-access-to-forms functionality. > > The current security model is governed by 2 tables: > > _user_granted_authority -- maps users to the groups they belong to. > NOTE: super-user is also granted the ROLE_SITE_ACCESS_ADMIN > privilege in this table (so that if they ever are removed from all > groups, they still have site admin privileges). > > _granted_authority_hierarchy -- hierarchy of groups and, eventually, > the privileges (roles) assigned to those groups. Privileges are > identified by "ROLE_" prefix. > > A very early alpha allowed for user-defined groups, but we stripped > that functionality out of the UI and restricted the user interface to > just the 4 groups (Data collector, Data viewer, Form Manager, Site > Admin). The underlying tables, however, still have that capability. > > The biggest issue with adding user-defined groups is that the UI and > service code would need to be rewritten to allow for more than these > assumed 4 groups. This means not passing GrantedAuthorityName across > the interface, but passing group name strings across. And you would > probably want a table mapping the group name to a friendly description > (like what GrantedAuthorityName does). > > You would then need to add a 3rd table to define what groups have > which privileges for a given form (GRANTED_AUTHORITY, FORM_ID, > PERMISSION) where you would need to also introduce the notion of > access permissions to a form. > > And then implement checks in all the service and servlet methods to > verify that the logged-in user belongs in one or more groups that have > the appropriate permissions for that form. This can be done via: > > -----------------------begin snippet > CallingContext cc; > > // grants from _user_granted_authority table > Set directAuths = > cc.getCurrentUser().getDirectAuthorities(); // immutable > > RoleHierarchy rh = (RoleHierarchy) > cc.getBean("hierarchicalRoleRelationships"); > > // get the expanded grants from a closure of directAuths with > _granted_authority_hierarchy > Set allUserAuths = > rh.getReachableGrantedAuthorities(directAuths); // mutable set... > > // new method you implement on Form instance... > // gets all groups/privileges granted the needed permission on this form. > Set tableAuthsGrantedPermission = > form.yourMethodToAccess3rdTableForAuthsWithPermisson(permission); > // NOTE: this is likely an immutable set (cached in memory) > > allUserAuths.retainAll(tableAuthsGrantedPermissions); // intersect > > if ( allUserAuths.empty() ) { > // user didn't have any of the permissions necessary for the access... > throw new AccessDeniedException("you do not have the permissions to > ___ this form"); > } > -----------------------------end snippet > > Mitch > > On Thu, Oct 4, 2012 at 8:50 AM, John Etherton <john@ethertontech.com > wrote: > > Hey, > > Just trying to stir the pot and see if anyone has any thoughts on > this. Also, I was told I should try to get the attention of a > person named Mitch who has done this before. So, Mitch, if you're > out there, I'd love to know your thoughts. > > Thanks, > > John. > > > On Thursday, September 27, 2012 5:52:09 PM UTC-6, John Etherton wrote: > > Hello everyone, > > I'm working on a project to add groups to aggregate. This way > both users and forms would belong to one or more groups. Users > from Group A could only view/edit the forms that were also > under Group A, and so forth. I think this is pretty straight > forward, just add a table in the DB for groups, and then add > one that maps users to groups and one that maps forms to > groups. But I'm new to Tomcat/beans and very new to things > like Spring Security. > > So my question is, is it really as simple as I hope, or will > rewrite some stuff to get the various frameworks at play to > work with this change? Should I try to enforce separation of > groups through Spring or should I do that myself? Are there > any other things I should be aware of when implementing such a > change? > > Thanks a lot, > > > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitchellsundt@gmail.com

Did you made any progress on this, we are also looking for same
functionality?

Regards

··· On Tuesday, October 9, 2012 6:10:19 AM UTC+5:30, John Etherton wrote: > > Thanks Mitch. I might have some more questions, but for the moment > you've given me a lot to go on. > > > John > > > On 10/04/2012 05:52 PM, Mitch S wrote: > > Hi John -- thank you for the work you did with javarosa and cascading > selects! > > The 'group' functionality is all already there, but not the > groups-have-access-to-forms functionality. > > The current security model is governed by 2 tables: > > _user_granted_authority -- maps users to the groups they belong to. > NOTE: super-user is also granted the ROLE_SITE_ACCESS_ADMIN privilege > in this table (so that if they ever are removed from all groups, they still > have site admin privileges). > > _granted_authority_hierarchy -- hierarchy of groups and, eventually, the > privileges (roles) assigned to those groups. Privileges are identified by > "ROLE_" prefix. > > A very early alpha allowed for user-defined groups, but we stripped that > functionality out of the UI and restricted the user interface to just the 4 > groups (Data collector, Data viewer, Form Manager, Site Admin). The > underlying tables, however, still have that capability. > > The biggest issue with adding user-defined groups is that the UI and > service code would need to be rewritten to allow for more than these > assumed 4 groups. This means not passing GrantedAuthorityName across the > interface, but passing group name strings across. And you would probably > want a table mapping the group name to a friendly description (like what > GrantedAuthorityName does). > > You would then need to add a 3rd table to define what groups have which > privileges for a given form (GRANTED_AUTHORITY, FORM_ID, PERMISSION) where > you would need to also introduce the notion of access permissions to a form. > > And then implement checks in all the service and servlet methods to verify > that the logged-in user belongs in one or more groups that have the > appropriate permissions for that form. This can be done via: > > -----------------------begin snippet > CallingContext cc; > > // grants from _user_granted_authority table > Set directAuths = > cc.getCurrentUser().getDirectAuthorities(); // immutable > > RoleHierarchy rh = (RoleHierarchy) > cc.getBean("hierarchicalRoleRelationships"); > > // get the expanded grants from a closure of directAuths with > _granted_authority_hierarchy > Set allUserAuths = > rh.getReachableGrantedAuthorities(directAuths); // mutable set... > > // new method you implement on Form instance... > // gets all groups/privileges granted the needed permission on this form. > Set tableAuthsGrantedPermission = > form.yourMethodToAccess3rdTableForAuthsWithPermisson(permission); > // NOTE: this is likely an immutable set (cached in memory) > > allUserAuths.retainAll(tableAuthsGrantedPermissions); // intersect > > if ( allUserAuths.empty() ) { > // user didn't have any of the permissions necessary for the access... > throw new AccessDeniedException("you do not have the permissions to ___ > this form"); > } > -----------------------------end snippet > > Mitch > > On Thu, Oct 4, 2012 at 8:50 AM, John Etherton <jo...@ethertontech.com wrote: > >> Hey, >> >> Just trying to stir the pot and see if anyone has any thoughts on this. >> Also, I was told I should try to get the attention of a person named Mitch >> who has done this before. So, Mitch, if you're out there, I'd love to know >> your thoughts. >> >> Thanks, >> >> John. >> >> >> On Thursday, September 27, 2012 5:52:09 PM UTC-6, John Etherton wrote: >>> >>> Hello everyone, >>> >>> I'm working on a project to add groups to aggregate. This way both users >>> and forms would belong to one or more groups. Users from Group A could only >>> view/edit the forms that were also under Group A, and so forth. I think >>> this is pretty straight forward, just add a table in the DB for groups, and >>> then add one that maps users to groups and one that maps forms to groups. >>> But I'm new to Tomcat/beans and very new to things like Spring Security. >>> >>> So my question is, is it really as simple as I hope, or will rewrite >>> some stuff to get the various frameworks at play to work with this change? >>> Should I try to enforce separation of groups through Spring or should I do >>> that myself? Are there any other things I should be aware of when >>> implementing such a change? >>> >>> Thanks a lot, >>> >> > > > -- > Mitch Sundt > Software Engineer > University of Washington > mitche...@gmail.com > > >

Techbyte,

No progress has been made. My client has put this on hold to prioritize
other things.

Thanks,

John.

··· On 11/29/2012 11:35 PM, techbyte wrote: > Did you made any progress on this, we are also looking for same > functionality? > > Regards > > > On Tuesday, October 9, 2012 6:10:19 AM UTC+5:30, John Etherton wrote: > > Thanks Mitch. I might have some more questions, but for the moment > you've given me a lot to go on. > > > John > > On 10/04/2012 05:52 PM, Mitch S wrote: >> Hi John -- thank you for the work you did with javarosa and >> cascading selects! >> >> The 'group' functionality is all already there, but not the >> groups-have-access-to-forms functionality. >> >> The current security model is governed by 2 tables: >> >> _user_granted_authority -- maps users to the groups they belong to. >> NOTE: super-user is also granted the ROLE_SITE_ACCESS_ADMIN >> privilege in this table (so that if they ever are removed from >> all groups, they still have site admin privileges). >> >> _granted_authority_hierarchy -- hierarchy of groups and, >> eventually, the privileges (roles) assigned to those groups. >> Privileges are identified by "ROLE_" prefix. >> >> A very early alpha allowed for user-defined groups, but we >> stripped that functionality out of the UI and restricted the user >> interface to just the 4 groups (Data collector, Data viewer, Form >> Manager, Site Admin). The underlying tables, however, still have >> that capability. >> >> The biggest issue with adding user-defined groups is that the UI >> and service code would need to be rewritten to allow for more >> than these assumed 4 groups. This means not passing >> GrantedAuthorityName across the interface, but passing group name >> strings across. And you would probably want a table mapping the >> group name to a friendly description (like what >> GrantedAuthorityName does). >> >> You would then need to add a 3rd table to define what groups have >> which privileges for a given form (GRANTED_AUTHORITY, FORM_ID, >> PERMISSION) where you would need to also introduce the notion of >> access permissions to a form. >> >> And then implement checks in all the service and servlet methods >> to verify that the logged-in user belongs in one or more groups >> that have the appropriate permissions for that form. This can be >> done via: >> >> -----------------------begin snippet >> CallingContext cc; >> >> // grants from _user_granted_authority table >> Set directAuths = >> cc.getCurrentUser().getDirectAuthorities(); // immutable >> >> RoleHierarchy rh = (RoleHierarchy) >> cc.getBean("hierarchicalRoleRelationships"); >> >> // get the expanded grants from a closure of directAuths with >> _granted_authority_hierarchy >> Set allUserAuths = >> rh.getReachableGrantedAuthorities(directAuths); // mutable set... >> >> // new method you implement on Form instance... >> // gets all groups/privileges granted the needed permission on >> this form. >> Set tableAuthsGrantedPermission = >> form.yourMethodToAccess3rdTableForAuthsWithPermisson(permission); >> // NOTE: this is likely an immutable set (cached in memory) >> >> allUserAuths.retainAll(tableAuthsGrantedPermissions); // intersect >> >> if ( allUserAuths.empty() ) { >> // user didn't have any of the permissions necessary for the >> access... >> throw new AccessDeniedException("you do not have the >> permissions to ___ this form"); >> } >> -----------------------------end snippet >> >> Mitch >> >> On Thu, Oct 4, 2012 at 8:50 AM, John Etherton <jo...@ethertontech.com > wrote: >> >> Hey, >> >> Just trying to stir the pot and see if anyone has any >> thoughts on this. Also, I was told I should try to get the >> attention of a person named Mitch who has done this before. >> So, Mitch, if you're out there, I'd love to know your thoughts. >> >> Thanks, >> >> John. >> >> >> On Thursday, September 27, 2012 5:52:09 PM UTC-6, John Etherton wrote: >> >> Hello everyone, >> >> I'm working on a project to add groups to aggregate. This >> way both users and forms would belong to one or more >> groups. Users from Group A could only view/edit the forms >> that were also under Group A, and so forth. I think this >> is pretty straight forward, just add a table in the DB >> for groups, and then add one that maps users to groups >> and one that maps forms to groups. But I'm new to >> Tomcat/beans and very new to things like Spring Security. >> >> So my question is, is it really as simple as I hope, or >> will rewrite some stuff to get the various frameworks at >> play to work with this change? Should I try to enforce >> separation of groups through Spring or should I do that >> myself? Are there any other things I should be aware of >> when implementing such a change? >> >> Thanks a lot, >> >> >> >> >> -- >> Mitch Sundt >> Software Engineer >> University of Washington >> mitche...@gmail.com >