Grouper Developers Forum

[Shilen Patel <>]

> If you wanted to setup what you describe, you could just add the  
> admin role to be a member of the sysAdmin role, then all people who  
> had admin, would also be sysAdmins, and then you will see the DB  
> rows you expect.  Otherwise, you need to query the database based on  
> the admin role, and you will see what I describe.
>
> Roles in Grouper has two sides, the membership, and the  
> permissions.  If you have a membership to a role, you have that  
> role.  If you setup groups/roles as members of roles, then the roles  
> cascade to the leaf member.  The roleSet role inheritance, does not  
> affect membership in the role, it affect the other side which is  
> which permissions a role has.


OK perfect.  That works great.

Thanks!

-- Shilen


On Dec 7, 2009, at 1:51 PM, Chris Hyzer wrote:

> Hey,
>
> Shilen and I are having a good discussion about Grouper permissions,  
> and I wanted to CC the list so other people can good this at some  
> point :).
>
> Basically the question is, if role inheritance is setup, why is  
> there not a row in grouper_perms_all_v for the role where the  
> permission is assigned and the user who has the subrole.
>
> The role "admin" inherits from sysAdmin.  This means that any  
> permissions that are granted to sysAdmin, would automatically be  
> granted to admins.
>
> > So now I want to know everything that all the sysAdmins can do (who
> > they are, the action, and the resource).  testUser is a sysAdmin due
> > to role inheritance.  But there are no rows for sysAdmins in
> > grouper_perms_all_v.
>
> testUser is not a sysAdmin.  testUser is an admin.  The admin role  
> inherits permissions from sysAdmin, but if you are an admin, it  
> doesn't mean you are a sysadmin.  So if you look in the  
> grouper_perms_all_v view, you see that testUser has the permission,  
> but in the admin role (not sysAdmin).
>
> If you wanted to setup what you describe, you could just add the  
> admin role to be a member of the sysAdmin role, then all people who  
> had admin, would also be sysAdmins, and then you will see the DB  
> rows you expect.  Otherwise, you need to query the database based on  
> the admin role, and you will see what I describe.
>
> Roles in Grouper has two sides, the membership, and the  
> permissions.  If you have a membership to a role, you have that  
> role.  If you setup groups/roles as members of roles, then the roles  
> cascade to the leaf member.  The roleSet role inheritance, does not  
> affect membership in the role, it affect the other side which is  
> which permissions a role has.
>
> Make sense?
>
> Thanks,
> Chris
>
>
> -----Original Message-----
> From: Shilen Patel 
> [mailto:]
> Sent: Monday, December 07, 2009 8:54 AM
> To: Chris Hyzer
> Subject: Re: role inheritance
>
> Ok so say if I do the following in GSH:
>
> roleTest = addRootStem("roleTest", "roleTest")
> adminRole = roleTest.addChildRole("adminRole", "adminRole")
> sysAdminRole = roleTest.addChildRole("sysAdminRole", "sysAdminRole")
>
> adminRole
> .getRoleInheritanceDelegate().addRoleToInheritFromThis(sysAdminRole);
>
> Stem resourcesTest = addRootStem("resourcesTest", "resourcesTest")
> resourcesDef = resourcesTest.addChildAttributeDef("resourcesDef",
> AttributeDefType.perm);
> resourcesDef
> .getAttributeDefActionDelegate
> ().configureActionList("view,create,delete");
> resourcesDef.setAssignToGroup(true);
> resourcesDef.store();
> resource = resourcesTest.addChildAttributeDefName(resourcesDef,
> "resource", "resource");
>
> sysAdminRole.getPermissionRoleDelegate().assignRolePermission("view",
> resource);
>
> sqlRun("insert into subject values ('testUser', 'jdbc', 'Test User')")
> adminRole.addMember(findSubject("testUser"))
>
>
> So now I want to know everything that all the sysAdmins can do (who
> they are, the action, and the resource).  testUser is a sysAdmin due
> to role inheritance.  But there are no rows for sysAdmins in
> grouper_perms_all_v.
>
> select count(*) from grouper_perms_all_v where
> role_name='roleTest:sysAdminRole'   => 0
> select count(*) from grouper_perms_all_v where
> role_name='roleTest:adminRole'         => 1
>
> So how would one query the database to determine that testUser can
> view the resource since he has the sysAdmin role without knowing that
> the inheritance exists?
>
>
> Does that make sense?
>
> Thanks!
>
> -- Shilen
>
>
> On Dec 6, 2009, at 7:55 PM, Chris Hyzer wrote:
>
> > grouper_perms_all_v is the union of perm by role or by user.
> > The view by role is: grouper_perms_role_v
> > That view joins role_set.
> >
> > If you joined the overall view with role set, then you would end up
> > with individuals who has permissions assigned to them, and now they
> > are assigned to multiple roles due to inheritance.  I think that is
> > not what we want.
> >
> > Right?
> >
> > Thanks!
> > Chris
> >
> > -----Original Message-----
> > From: Shilen Patel 
> > [mailto:]
> > Sent: Sunday, December 06, 2009 3:16 PM
> > To: Chris Hyzer
> > Subject: role inheritance
> >
> > Hi Chris,
> >
> > I've got a question about role inheritance.  In your slides for I2
> > (grouperWhatsNew.ppt) where you create the view
> > apps_sec_share_web_perms_v, the join that creates the view doesn't
> > include grouper_role_set_v.  If you want a view that includes role
> > inheritance, does it make sense to join grouper_perms_all_v with
> > grouper_role_set_v?  For instance...
> >
> > select then_has_role_name as role_name, subject_id, action,
> > attribute_def_name_name from grouper_perms_all_v perms,
> > grouper_role_set_v roles where perms.role_name=roles.if_has_role_name
> >
> >
> > Thanks!
> >
> > -- Shilen