Grouper Developers Forum

[Chris Hyzer <>]

Hey,

So we had 10 types of attributes:

Group attributes, stem, member, attribute definition, and immediate 
membership attributes.
Then attributes on the assignment of attributes to the above 5 (note, you 
cannot add an attribute to an assignment of an assignment of an attribute).

But, for permission management, we need to assign an attribute to a subject 
who is in a role.  And the subject might not be an immediate member.  So we 
need effective membership attributes (effective or immediate, whatever 
exists).  My original design was to key off the effective membership id in 
the membership view (since effective memberships aren't stored anymore), but 
the problem is if the immediate membership is removed, and there is another 
effective membership, the attribute will not automatically transfer over.  It 
will be orphaned, and it will be hard to figure out by the id what it used to 
be assigned to.  The new (and current) design is to do this like composite 
intersections or minus.  I have a composite key off of group_id and 
member_id.  If there is an effective membership, then the subject has the 
permission.  If not, then the subject doesn't.  If the membership goes away 
and comes back, then the subject will have the permission again (since no 
foreign key to the membership object, it doesn't get deleted when there isn't 
a membership).  We can eventually have some sort of loader job which cleans 
out the table of the old unused orphans.

So I added an 11th and 12th type of attribute: effective membership, and 
assignment of attribute to effective membership.  Also, I made views to link 
up all the permission management stuff (role memberships (immediate and 
effective), role directed graph inheritance, and permission directed graph 
inheritance), and now we have one view which shows which permissions users 
have.  

So I can create a role, add a subject to a role, assign a privilege to a 
role, and see that the subject has that privilege:

//create role add member
Role role = this.top.addChildRole("test", "test");
role.addMember(SubjectTestHelper.SUBJ5);

//create permission resource
AttributeDef attributeDef = this.top.addChildAttributeDef("test", 
AttributeDefType.perm);
AttributeDefName attributeDefName = 
this.top.addChildAttributeDefName(attributeDef, "testName", "test name");

//assign permission to the role
role.getPermissionRoleDelegate().assignRolePermission(attributeDefName);

//print out the permissions for the subject (it prints out)
Member member = MemberFinder.findBySubject(this.grouperSession, 
SubjectTestHelper.SUBJ5, true); 
Set<PermissionEntry> permissionEntries = 
GrouperDAOFactory.getFactory().getPermissionEntry().findByMemberId(member.getUuid());
for (PermissionEntry permissionEntry : permissionEntries) {
  System.out.println(permissionEntry);
}

#####################
Also, I can add a subject to a role, assign a permission to that subject in 
that role (not role-wide), and see that the subject has that permission:

//make a permission resource, assign it to the subject in that role
AttributeDefName attributeDefNameEff = 
this.top.addChildAttributeDefName(attributeDef, "testNameEff", "test name 
effective");
role.getPermissionRoleDelegate().assignSubjectRolePermission(attributeDefNameEff,
 member);

//print out the permissions for the subject (it prints out)
permissionEntries = 
GrouperDAOFactory.getFactory().getPermissionEntry().findByMemberId(member.getUuid());
for (PermissionEntry permissionEntry : permissionEntries) {
  System.out.println(permissionEntry);
}

Anyways, I believe now I can create some demos for the conference that show 
how this stuff can be used.  :)

Regards,
Chris