Grouper Developers Forum

[Chris Hyzer <>]

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/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/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/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: 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.

#####

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

#####

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"

#####

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)

#####

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...

#####

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

#####

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.

#####

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

#####

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

#####

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)

#####

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).  Roles inherit privileges from roles with the "role set" 
mechanism.  If sites want to provide sources, they can use the loader.  e.g. 
your org structure could be loaded in with the loader.

#####

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/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
>