Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

I've added comments to the wiki page 
<https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+Attributes>.

I still think this all needs thinking through more.

Gary

--On 24 June 2009 14:16 -0400 Chris Hyzer 
<>
 wrote:

> 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+Attribute
> s
>
>
>
> 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+Attribute
> s
>
>
>
> [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/



----------------------
GW Brown, Information Systems and Computing