Grouper Developers Forum

[Chris Hyzer <>]

I contacted Bert.  I added descriptions of objects (what I talked about on the phone), and two use cases to the attribute framework page.  If someone has another use case they want me to describe how it will work with Grouper, let me know.

 

https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+Attributes

 

Here is the stuff I added:

 

Object types

AttributeDef

This is an attribute definition.  It holds all metadata about an attribute.  This object is useless with an attributeName.  Fields:

• extension
• name
• description
• stemId
• type: attribute, permission, or scope
• actions: e.g. read,write (this is a comma separated list of "actions" which are used in conjunction with an assignment to make it 3-way.  If not specified, the default is "assign".  Sort of like a "list" in a membership assignment.  These are comma separated since they are very simple strings which dont need to be over engineered with display names, descriptions, etc
• assignedTo: membership, group, member, stem, membershipAttributeAssignment, groupAttributeAssignment, memberAttributeAssignment, stemAttributeAssignment
• Note: we might need to make this multi-valued, since I could see permissions assigned to memberships, and also assigned to roles
• valueType: int, string, marker (no value), memberId (i.e. subject)
• assignedToNamespace (a list of groups, or like strings in the namespace)
• multivalued: T|F
• multiassigned: T|F (to the same object, i.e. witha  different value)
• multinamed: T|F if there can be more than one name for this attributeDef
• public: T|F (if not, then the def is only usable in the stem or substems for attributeNames)

AttributeName

This is linked to an attributeDef to make it whole.  Fields:

• name
• extension
• displayExtension
• displayName
• description
• attributeDefId
• stemId

Group

This is as we have now, it is a container of subjects, which can be other groups (but not roles).  Permissions cannot be assigned to groups.

Role

Type of group.  This cannot be added to another group.  Permissions can be assigned to roles, or assigned to memberships in roles (immediate, effective, or composite).  Roles can have privilege hierarchies.  So a role can be related to another role such that if one role has a privilege assigned, then another role would also have that privilege, though the member would not be "in" that other role.  Think: loan administrator and senior loan administrator

Permission

This is a special type of attribute.  Permissions can be assigned to only roles or memberships of roles (as opposed to attributes which can be assigned to anything).  If there is a decision point web service, it would only be applicable to see if a subject has a privilege (which is the assignment of a permission).  Permissions can have hierarchies (permission sets) such that an assignment of one permission implies also the assignment of other permissions.  You can also have a relationship with a permission set.  I was thinking that "permission set" would only be allowed for permissions, unless someone has a reason to bundle up attributes in sets too...

Use cases

Penn payroll permissions

Here is the use case.

This can be done with Grouper attributes in one of two ways.

1. Make two permissions: penn:isc:apps:payroll:permissions:org, and penn:isc:apps:payroll:permissions:center.  Have the value be a string.  Assign that to memberships in the role: penn:isc:payroll:roles:payrollUser.  It could be multivalued, so you could assign the org as 712, 934, 975-1034.  The "actions" would be read,write.  Then we would need a hook to do the decision logic.  A hook could also validate the org exactly, though it could also be approximated as a regex:

^[A-Z0-9-]{2,4}$

2. We could not have ranges, and put all orgs in the system as permissions.  Then we could maintain the hierarchy in permission sets.  This way if you assign 97XX, that would imply all the permissions in that set: 9701, 9702, etc.  The actions would still be read,write.  So ranges would not be supported.

Carnegie Mellon billing use case

Here is the use case.

First there is delegation here.  This can be either a permission (cmu:it:apps:billing:permissions:delegationFromStudent) with a single value (memberId) but the ability to be multi-assigned, or a permission with multi-value which can be single assigned.  If you want different start and end dates for the privileges, you need to do the single value and multi-assigned, since the delete date is on the assignment, not the value (the value will cascade delete though).  A hook would need to make sure that the person assigning this is setting value to be their own memberId.  The "update" security on this permissions would have the "cmu:community:student" group in it, so students can make this delegation assignment.

The privilege "cmu:it:apps:billing:viewOwnBills" would be assigned to the Role: cmu:it:apps:billing:roles:billingUserStudent, which would have the cmu:community:student group inside.

This part: "Local-billing-administrator -  can view the bills of any student that is enrolled in a department, college, or degree granting program over which they have been delegated "viewing"  privileges" can be done by putting all departments, colleges, and degree granting programs in as permissions (and permission sets).  There would need to be actions specific to this system associated with them, e.g. "viewBills".  These permissions can be assigned (among other uses) to memberships in the Role: cmu:it:apps:billing:roles:localBillingAdministrator

This part: "Designate-local-billing-administrator - this designation is only valid for a fixed period of time  and  as long as certain attributes of the designee are constant", would be a permission attached to a membership in a role.  Once the certain attribute of the designee are changed, the user might drop out of the role (e.g. fired or job change, no long an active employee in the same org, etc).  This would drop the permissions.  Also, there are end dates available for permission assignments.

 

 

 

 

From: Emily Eisbruch [mailto:]
Sent: Wednesday, June 24, 2009 1:38 PM
To: Grouper Dev
Subject: [grouper-dev] Action Items: Grouper Call 24-Jun-09

 

*New Action Items*

 

[AI]  (Shilen) and (Jim) will create a wiki page on handling entitlements to minimize publishing of group information.

 

[AI] (Jim) will put LDAP source adapter info from U-W on wiki.

 

[AI] (Gary) will enter a new JIRA issue related to GRP-295 and the removal of membership.

 

[AI] (Chris) will add use cases and framework to the attribute framework wiki page.

https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+Attributes

 

[AI] (Chris) will contact Bert re contributing privilege management use cases.

 

 

 

Emily Eisbruch, Technology Transfer Analyst

Internet2

office: +1734-352-4996 | mobile +1-734-730-5749

 

ESCC/Internet2 Joint Techs
July 19-23, 2009 - Indianapolis, Indiana
http://jointtechs.es.net/indiana2009/