grouper-dev - Draft Minutes: Grouper Call 4-Feb-09
Subject: Grouper Developers Forum
List archive
- From: Emily Eisbruch <>
- To: Grouper Dev <>
- Subject: Draft Minutes: Grouper Call 4-Feb-09
- Date: Thu, 12 Feb 2009 09:29:32 -0500
**Grouper Call 4-Feb-09**
*Attending*
Tom Barton, U. Chicago (Chair) Gary Brown, Bristol U. Bert Bee-Lindgren, Georgia Tech Shilen Patel, Duke Chris Hyzer, U. Penn Tom Zeller, U. Memphis Steve Olshansky, Internet2 Emily Eisbruch, Internet2 (scribe) New Action Items [AI] (Everyone) will send to the list ideas on DB tables & triggers for audit / notification / as complete solutions / as infrastructure. [AI] (Chris) will email the group regarding auditing, transactions, and context IDs. Carry Over Action Items [AI] TomZ will send to the list a summary of the strands in the group's discussion on notification. [AI] Chris will update the wiki page on auditing and notification. *Discussion* Namespace Transition What privilege checking should be done for moving or copying a stem? Privilege checking seems more important for stem move than for stem copy. But maybe privilege checking is not needed at all, as long as one does not gain administrative access to the stem or groups by virtue of doing the move. Suggestion: optionally restrict who can move stems. Offer a configuration option that gives a site the ability to turn off stem copy or move unless the person doing it has stem privileges and/or is a member of a certain group. This gives deployers tools to enforce security but does not impose inconvenience for all sites. Chris: what privileges are needed to do a move? Shilen: For a move, create stem privilege on stem being moved and also on destination location. Chris: For a stem copy that’s OK, but for a stem move, admin priv. should probably be required due to the risk of breaking a lot of things. Shilen stated that it is possible rename a stem without admin privileges on those groups. Chris suggested that renaming should be addressed too. Bert noted there are analogies in other software where directory changes don’t require file and subdirectory permissions. We don’t want to make Grouper harder to manage than the tools people are used to. Chris: People may not understand that moving stems could mean you can’t use apps. Maybe we should document the seriousness of renaming stems. Decision was that to move a stem, a person must have stem access on that stem. For copies, they don’t need any access. There will be optional configuration options to allow enforcement of stricter restrictions on move, copy and rename. Also, help text will be enhanced to document risks. TomB: Are there analogous concerns for copying and moving an individual group or a set of groups? Shilen: For groups or sets of groups, we should do the appropriate priv. checking. Be sure the mover has the admin priv. to groups being moved and to the destination stem and read priv. for groups being copied. Options for Moving and Copying There was previous suggestion of providing checkboxes for users to specify which attributes, membership, privileges, etc. get moved over when a stem is moved. There was also sentiment to leave that for a future stage. The decision was to implement these choices: Copy attributes, Y/N Copy members Y/N Privileges Y/N This will be a reasonable initial capability. We’ll find out what really matters when people start to use it. Names for Copied Groups and Stems Another suggestion was to allow users to change names of copied groups, for example by applying an _expression_ to change all extensions. It makes sense to save this for a phase two, if needed. However, when a groups gets copied within a stem, a new name will be required. Decision was to do what Microsoft Windows does: give the copied group a name like “copy of” #.1 Aliases for Renamed Entities Chris: Does it make sense for all moves to create aliases, and then have a grace period before there is a requirement to use the new name? There could be a table tracking new name and alias. With the alias approach, there is a question of when to get rid of the alias. Bert: Using aliases would create the need to have two entitlements during provisioning. TomB: It would be good to decouple the editing operation on the registry from reliance on those names downstream. What about keeping a history of name changes rather than using aliases? If someone tries to reuse a name they’d be warned if that was a name that can’t be reused. TomB: One way of looking at this is that names are identifiers, so don’t reuse/recycle them. Once a name is used, it should always be available to point to the thing it used to reference. Bert: good identifiers are not infinite. TomB: need to find balance between maintaining a name history vs. maintaining aliases. This issue was not resolved on this call. Subject Search in UI Chris will start to create a new source adapter -- more sophisticated than the JDBC subject adapter -- so search results are prioritized. This would create a list with highest priority results at top and lowest at bottom. Chris: Also, do we need hooks on a subject search to prioritize which sources to search first? Gary: not sure hooks and subject API go together. Chris: How should we handle cases where people want to put extra identifiers -- that are not searchable -- in the subject repository? These can be service accounts or one-offs. TomB: Let’s save this discussion for a future call. [AI] (Everyone) will send to the list ideas on DB tables & triggers for audit / notification / as complete solutions / as infrastructure. [AI] (Chris) will email the group regarding auditing, transactions, and context IDs. Next Call Next Call: Wed., 18-Feb-09 at noon ET Emily Eisbruch, Technology Transfer Analyst Internet2 office: +1734-352-4996 | mobile +1-734-730-5749 Spring 2009 Internet2 Member Meeting April 27-29, Arlington, Virginia events.internet2.edu/2009/spring-mm/ |
- Draft Minutes: Grouper Call 4-Feb-09, Emily Eisbruch, 02/12/2009
Archive powered by MHonArc 2.6.16.