Grouper Developers Forum

[Chris Hyzer <>]

Hey,

Two things (described below):

1. I have an initial implementation committed for attribute framework security

2. I am using delegates to organize the new API

#####################################
## Attribute framework security

a. To create any attribute framework objects, you need CREATE in the stem 
where the object is created:

    this.grouperSession = GrouperSession.startRootSession();
    this.top.grantPriv(SubjectTestHelper.SUBJ0, NamingPrivilege.CREATE);

    this.grouperSession.stop();
    this.grouperSession = GrouperSession.start( SubjectTestHelper.SUBJ0 );
    
    //this should work
    this.top.addChildAttributeDef("test", AttributeDefType.attr);

b. AttributeDefs (attribute definitions) have similar privileges that groups 
have: attrAdmin, attrOptin, attrOptout, attrRead, attrUpdate, and attrView.  
So for instance, to edit an attribute, you need to be an admin for that 
attribute:

    attributeDef.getPrivilegeDelegate().grantPriv(SubjectTestHelper.SUBJ0, 
AttributeDefPrivilege.ATTR_ADMIN, false);
    
    this.grouperSession.stop();
    this.grouperSession = GrouperSession.start( SubjectTestHelper.SUBJ0 );

    attributeDef.setDescription("whatever");
    //should succeed
    attributeDef.store();


Note, there are issues here about attribute assignments (as opposed to 
editing the attribute definition).  The subject in the session will need 
"attrUpdate" on the attribute, and will need privileges on the source object 
too:

- member: will need to be GrouperSystem or wheel
- group: will need ADMIN in the group
- stem: will need CREATE in the stem
- membership: will need UPDATE on the group
- attribute: will need ADMIN in the attributeDef
- attributeAssignment: will need to be able to assign the attribute (gets a 
little complicated here obviously)

This is yet to come...

##################################
## API delegates to organize API

One of the concerns with the attribute framework and privilege management was 
that it would bloat the API.  I think the current strategy the API uses for 
one-to-many methods in the API (just add all methods to the "one" object), is 
the cause for the bloat.  The Group object currently has thousands of lines 
of code, and hundreds of methods.  However, if we organized the methods by 
one-to-many (or other means), then it would be a lot easier to use / maintain 
/ test / etc.  i.e. look at the privilege assignment above:

attributeDef.getPrivilegeDelegate().grantPriv(SubjectTestHelper.SUBJ0, 
AttributeDefPrivilege.ATTR_ADMIN, false);

In the Group object (and note I am not changing existing API here, this is 
for new stuff), all the privilege methods are in the group object.  However, 
above you see that I am putting them in another class which exists to 
delegate logic from the "one" class, to the "many" class (in this case 
privileges).  I will use this technique for attributes and permission 
management as well, and we will not see any bloat.  You will notice that the 
resulting API object model does not mirror the data model... oh well.

Please give me any comments

Thanks,
Chris