Grouper Developers Forum

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

--On 28 June 2009 10:15 -0400 Chris Hyzer 
<>
 wrote:

> Gary, thanks a lot for reviewing it!  Here are some responses:
>
> > GB: 6/28/09: I have put some specific comments below but some general
> > ones first. I think we have to be very careful about about mixing up an
> > enhanced, general purpose attribute framework and then trying to use it
> > for something as complicated as role/privilege management. The latter
> > necessarily involves a lot of business logic and I wonder if it would be
> > better to separate it into a separate project which leverages Grouper's
> > capabilities but doesn't directly pollute Grouper itself.
> > Role/privilege management has concrete concepts which may be best
> > implemented through an appropriate object model - mapped to new specific
> > tables rather than encoded in a general framework. Our experience with
> > the current Grouper attributes has shown that enumeraing attributes for
> > many groups is very inefficient. The new framework is more complicated
> > still and some of the features implied may not scale - depending on how
> > and when attributes are enumerated.
>
>
> CH: 6/28/09: well, there are pros and cons to a separate system vs an
> integrated system.  I would like to give it a shot, and solve the
> performance issues that we encounter. I think based on the recent and
> ongoing performance improvements of Grouper we are better equipped to be
> able to deliver such a product.  Also, as a readonly decision point, we
> can tune things to be even faster than computing based on relational
> database data (as we have discussed). Here are the advantages as I see it
> to have privilege management inside of Grouper:
>
> 1.  Performance.  How can you see what someone has access to for roles
> and individual privileges, if you cant join the group membership table?
> And why would you want to export all group memberships to the privilege
> management system, or visa versa?
>
> 2.  One system to for implementors to install/maintain/monitor/upgrade
>
> 3.  One place to go for applications to make access control queries (1
> web service strategy)
>
> 4.  Re-use the common services: provisioning in/out, web services,
> auditing, hooks, etc
>
> 5.  One place for auditors to go to see auditing/history/reports
>
> 6.  One UI for admins to go to for granting access (if they use the built
> in UI :) )
>
> 7.  Besides having two systems to upgrade, there might be complex upgrade
> dependencies (remember when we had to coordinate subject API and
> i2mi-common with signet?)
GB: 6/30/09: I wasn't thinking that a module would be completely separate - 
rather that it would potentially extend a Grouper installation by 
installing:

1) Domain specific group types/attribute definitions
2) Additional database tables and objects
3) Additional/extended configuration
4) Implementations of new interfaces
5) Custom UI and WS components - added to existing webapps

This approach would maintain a clear distinction between groups management 
and privilege management and probably improve the underlying design of 
Grouper by providing the integration points that someone else could use to 
build a product on top of Grouper.

The Subject API caused problems because it didn't have clear ownership 
between Signet/Grouper and the two projects were never integrated. In this 
case you would have ownership and be in a position to add integration 
points as necessary.

> #####
>
> GB: 6/28/09: Do attributes still belong to complex types? Can attribute
> values be a complex type?
>
> Well, the current implementation of "complex type" is if the type is
> applied, you can assign some attributes.  We can have something similar
> whereby you attach a marker attribute, and then you can have other
> attributes which are only available if a marker attribute is assigned.
> Going further, we could have an attribute type called "type", so the
> complete choices for attribute type would be: attribute, permission,
> limit, type...
GB: 6/30/09: Sounds like we ought to think of this as adding objects where 
an object type definition defines the attributes. permission, limit, type 
etc would simply be object types with specific attributes

> #####
>
> GB: 6/28/09: I can see that soem attributes may not be public even if the
> group is.
>
> Yes, that description wasn't up to date, we will support this, I added:
> This would be the eventual default, initially the security would be
> similar to group security where you can assign subjects to
> read/view/update/admin/optin/optout
>
> #####
>
> GB: 6/28/09: Why not? Groups could inherit some attributes from a stem -
> don't need to assign attributes directly to each group, but can
> supplement/override on individual groups
>
> Yes, this also was not up to date, I will support this also
>
> Types of values: an attribute could be single or multivalued, and could
> be a boolean, string, int, double, timestamp, marker (no value), [GB:
> 6/28/09: cistom type?].
>
> Well, the custom type is an attribute which implies more attributes to be
> assigned, if that's what you mean.
GB: 6/30/09: Using the object/attribute distinction above, an attribute 
value could be defined as an instance of an object type
> #####
>
> [GB: 6/28/09: You probably need interface(s) so that UIs can retrieve a
> set of allowed values and for validation - we can provide some simple
> implementations for list/regex*]*
>
> Yes, that is the idea
>
> #####
>
> GB: 6/28/09: I think having typed groups has potential - but more in
> terms of qualifying what subject type they can have a as a member i,e
> Group<Privilege>. Then you are only allowed to add groups of the same
> types as members and you gain inheritance using the existing tried and
> trusted mechanism.
>
> Yes, I have thought about this we could have an attribute, when applied
> to a group, would activate a trigger to restrict which types of subjects
> can be added
GB: 6/30/09: I think you would want it as part of the group definition i.e 
a system may create empty groups intended for a specific purpose which are 
only allowed Subjects of a particular type (or groups with the same 
restriction)
> #####
>
> GB: Also if attributes can have custom types, having an attribute be a
> group opens up possibilities - more on this below
>
> CH: 6/28/09: This is supported.  First off, the value of an attribute can
> be a memberId, so that helps with foreign keys.  But also, I picture
> custom formatters/validators that you could put on a String or memberId
> attribute so that you can make "custom types"
>
> #####
>
> CH: Would permissions attributes have a Y/N assignment qualifier? (for
> 1.5, no)
>
> GB: 6/28/09: as in grant/deny? If so it needs to be clear how conflicting
> assignments are resolved
>
> CH: Yes, for 1.5 lets not worry about this.  For now, everything is a
> grant.
GB: 6/30/09: OK
> #####
>
> CH: Are membership attributes on immediate memberships only?  Could be on
> immediate or effective.  The trick is if the effective is removed, and
> another effective remains, does the attribute (or privilege) shift to the
> other one?  I think it should (at least for privileges).  This is a
> namespace transition issue which can wait until after 1.5.
>
> GB: 6/28/09: I would have thought they apply to all members. Presumably
> you can apply them to custom lists?
>
> CH: Im talking about attributes on memberships, not attribute on groups.
> An attribute on a group could apply to all members, or just be group
> metadata.  Attributes on memberships apply to the
> group/member/list/whateverElseInMembershipRow
GB: 6/30/09: Having attributes attached to a Membership row would make them 
dependent on that individual Membership, which may be what you want, but is 
also susceptible to loss if a process drops memberships and recreates them 
- I'm not saying it shouldn't be possible but users should be aware of the 
maintenance issues
> #####
>
> CH: You can group attributes up, so that being assigned one attribute
> implies the assignment of other attributes
>
> GB: 6/28/09: is this not just a type - ie you assign types rather than
> individual attributes per se?
>
> CH: 6/28/09: think "org chart".  This might only be for permission type
> attributes.  But anyways, if you are assigned READ permission on the
> english department, then you also have READ permission on all
> subdepartments, and classes in the subdepartments.  It isnt really a
> "type"
GB: 6/30/09: OK, so inheritance of attributes...
> #####
>
> CH: There can be attribute types (currently I only think of "attribute",
> "privilege", "scope")
>
> GB: 6/28/09: may be a reference - to a custom type or a group?
>
> CH: 6/28/09: Of course, the attribute could be of type "attribute", with
> a value type of "string", and you can put a validator in there to make
> sure the string is a group uuid (or whatever you want)
>
> #####
>
> We should create a "role" object, which is similar to a group, but has
> some restrictions about what can be assigned where (e.g. a privilege can
> be assigned to a role, but not to a group?)
>
> GB: 6/28/09: I would see a role as a group of privileges and that you can
> assign the role to group lists, Members or Memberships
>
> CH: We should create a "role" object, which is similar to a group, but
> has some restrictions about what can be assigned where (e.g. a privilege
> can be assigned to a role, but not to a group?)
>
> #####
>
> GB: 6/28/09: I would see a role as a group of privileges and that you can
> assign the role to group lists, Members or Memberships
>
> CH: 6/28/09: Exactly, so what object do we have in grouper which can be
> associated with group lists or members?  A group.  And if permissions are
> attributes, then in this case you just assign the group attributes
> (permissions) to the group role, and you are all set.  I think
> duplicating everything that group does to make role a first class object
> would be too time consuming and too wasteful (would have a lot of
> code/data duplication, and the objects aren't too different)
GB: 6/30/09: I'm all for 'extending' a group to make a role - just want to 
be clear on what the members are - and as Members are Subjects that implies 
that objects/attributes are subjects - otherwise you are creating a new 
mechanism for inheritance?
> #####
>
> CH: There should be a user configurable stem where Grouper can put
> builtin attributes
>
> GB: 6/28/09: as per comments above I would see a configurable space
> reserved for modules so that different projects building on top of
> Grouper would register as a module
>
> CH: 6/28/09: I think this is fine, though those modules would need to
> have a configurable "start" stem, sort of like built in grouper
> attributes.  So if I want all my stuff to be in the "penn:" stem, I can...
GB: 6/30/09: OK
> #####
>
> CH: Assignments of attributes should have an "action", similar to group
> lists, where there is a verb.  Default would be "assign", but you could
> make it "read", "write", "admin", etc.  I guess these would be very
> simple strings (like group lists) that are specified on attribute
> creation (if any)
>
> GB: 6/28/09: does this only make sense for attributes that are privileges?
>
> CH: 6/28/09: good question, it especially makes sense for privileges.  If
> there is one action (assign) for other attributes, then they just do
> "assign".  If they need more flexibility, it is there
GB: 6/30/09: I think this is where privileges are 'polluting' the attribute 
framework. If we have an object type which is a privilege, it can have 
generic attributes one of which is 'actions' - a multivalued String i.e. 
every attribute def shouldn't have implied actions
> #####
>
> CH: 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
>
> GB: 6/28/09: I'm not sure we can assume they are always simple - look at
> the list of privileges you can assign to Oracle users. May just be a case
> of enabling them to work with tooltips.
>
> CH: 6/28/09: In trying to keep things simple, that is the current
> assumption, actions are simple.  If you need something more complicated,
> then you are probably structuring things not optimally with what a
> privilege is.  If you have a specific example you want to know how I
> would model, please elaborate and we can discuss.
GB: 6/30/09: I'll dig something up
> #####
>
> CH: valueType: int, string, marker (no value), memberId (i.e. subject)
>
> GB: 6/28/09: groupId, custom type?
>
> CH: 6/28/09: string is the data type, you can put custom validators to
> make sure the string is what you want
GB: 6/30/09: May be I'm after a custom instantiator...
> #####
>
> assignedToNamespace (a list of groups, or like strings in the namespace)
>
> GB: 6/28/09: Do we do that here or should they be assign to actual stems?
>
> CH: 6/28/09: Yes, you can do something like: penn:community:employees:%
> to limit to a stem or substem
GB: 6/30/09: OK, just need to ensure it can be updated at runtime
> #####
>
> CH: 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.
>
> GB: 6/28/09: I think your Pacman glossary was suggesting roles should be
> assigned to groups - and I agree, but here I'm not clear how that happens
> here
>
> CH: 6/28/09: Just add the group to be a member of the role (like adding a
> group to be a member of a group)
GB: 6/30/09: I guess I was thinking that Roles would have privileges as 
members. Also you can't specify a custom list - and in my mind at least 
custom lists would be nice to use for role assignments.

You could have a role as a group of privileges and then add the role to a 
group or custom list - all members would have the privileges conferred by 
the role.
> #####
>
> CH: 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
>
> GB: 6/28/09: I would see roles as groups of privileges/permissions. Roles
> could inherit privileges by adding another role as a member. This would
> mean providing adapters for roles and privileges - but I think that is
> good as it means that sites can implement their own sources for these
> things if they don't want to do it in Grouper directly.
>
> CH: 6/28/09: Roles are linking up privileges with a person or group (or
> combination).
GB: 6/30/09: I have always thought of roles as independent entities which 
are then assigned to a 'subject'
> Roles inherit privileges from roles with the "role set"
GB: 6/30/09: So what is the 'role set' mechanism? An additional inheritance 
mechanism?
> mechanism.  If sites want to provide sources, they can use the loader.
> e.g. your org structure could be loaded in with the loader.
GB: 6/30/09: I was thinking of subject sources - a way of referencing 
external data without having to pull it into Grouper
> #####
>
> CH: 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...
>
> GB: 6/28/09: aren't permission sets roles and attribute sets custom types?
>
> CH: 6/28/09: sort of... a permission set is a group of permissions (like
> an org chart), but its not really a role.  It might be a good idea to
> assign permissions to a permission set, then assign that to the role, but
> it is up to the implementor.  We can discuss custom types.  You can put
> custom validators on attribute validators, and link up attributes with
> the assignment of another attribute, which is like the current
> implementation of type
GB: 6/30/09: Not quite sure I follow this - are you talking about targets 
for a permission?
> #####
>
> GB: 6/28/09: I think ranges might not be generic - certainly wouldn't
> work at Bristol. Do orgs ever get reorganised so that they are no longer
> related to adjacent numbers?
>
> CH: 6/28/09: Yes, ranges would be custom hook logic... but they are
> possible, but not generic
>
>
>
>
>
>
> > -----Original Message-----
> > From: GW Brown, Information Systems and Computing
> > [mailto:]
> > Sent: Sunday, June 28, 2009 6:26 AM
> > To: Chris Hyzer; Grouper Dev
> > Subject: RE: [grouper-dev] Action Items: Grouper Call 24-Jun-09
> >
> > I've added comments to the wiki page
> > <https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+Attrib
> > utes>.
> >
> > 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+Attribu
> > te
> > > 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+Attribu
> > te
> > > 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



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