Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] Action Items: Grouper Call 24-Jun-09

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] Action Items: Grouper Call 24-Jun-09


Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Chris Hyzer <>, Grouper Dev <>
  • Subject: RE: [grouper-dev] Action Items: Grouper Call 24-Jun-09
  • Date: Tue, 30 Jun 2009 12:26:35 +0100

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




Archive powered by MHonArc 2.6.16.

Top of Page