grouper-dev - [grouper-dev] Draft Minutes: Grouper Call 1-Aug-2012
Subject: Grouper Developers Forum
List archive
- From: Emily Eisbruch <>
- To: Grouper Dev <>
- Subject: [grouper-dev] Draft Minutes: Grouper Call 1-Aug-2012
- Date: Fri, 10 Aug 2012 14:48:09 -0400
| Draft Minutes, Grouper Call 1-Aug-2012 Tom Barton, University of Chicago (Chair) Chris Hyzer, University of Pennsylvania Bill Thompson, Unicon Shilen Patel, Duke Jim Fox, University of Washington Steve Olshansky, Internet2 Emily Eisbruch, Internet2 (scribe) Carry Over Action Items [AI] (Chris) upgrade the Grouper demo to the latest Grouper version 2.1 leave [AI] (Michael) will look into conducting user interviews premature [AI] (TomZ) add info to the wiki regarding doing testing on provisioning [AI] (TomZ) will put test data in the Grouper demo to show using an LDAP source. [AI] (TomZ) will review the Grouper LDAP Loader doc and provide feedback to Chris, possibly with lessons learned from LDAPPC work. https://spaces.internet2.edu/display/Grouper/Grouper+-+Loader+LDAP [AI] (Emily) Initiate an overall Grouper Features table with brief descriptions and links to documentation =========== DISCUSSION Grouper 2.1.2 - Work continues on the Grouper 2.1.2 release. - The biggest item in Grouper 2.1.2. is the PSP fix that TomZ is working on. - TomZ is using the AD infrastructure at U. Chicago for testing his work on PSP. - Timing for the Grouper 2.1.2 release depends on TomZ. - TomB will be in touch with TomZ to find out his timing. Other items/fixes to include in Grouper 2.1.2? - GRP 825, group move/rename failures in postgres (Shilen): - batched attribute assignments in Grouper 2.1.2 (Chris) - possibly custom loader jobs (Chris) - LITE UI session time out issue (Chris) ===== Roadmap for Grouper 2.2: New Grouper UI (has been discussed on previous calls) Other items are discussed are listed below Services in Grouper for Grouper 2.2 (Chris has started work on this) - Users of the Grouper UI, may want to manage things for their application - This tagging approach will mean that when users go to the UI to find groups to manage an application, then they could filter the UI for that application - At U Chicago, there is a spacial approach to using the hierarchy, using common folders - this tagging would offer a more dynamic approach The new UI should make it easy to: 1. present this dynamic view of all services/ objects 2. tag all requirements ===== Improved Grouper Configuration (for Grouper 2.2) In order to make Grouper more easily deployable across environments, and more easily upgradable, add ability for cascaded config files, and _expression_ language in config file entries. There can be a default configuration file, and an override file so that only the changes from the default can be tracked in the overlay - this will help for installation and for upgrades - will help for organizing your server - don't have to have config file in class path - can have a bunch of config files that overlay each other - you can keep things the same across environments in one central file - you can keep things that are environment-specific in their own file - minimal things to do for upgrade - don't have to merge old and new Grouper.propoerities - for upgrade, you just put the list of files - talked about some of the configs in the database? could make upgrades easier Q: What would be the agent to integrate all the config files together? A: The properties file could have a list of config files to use. Eventually we could get this from a URL if we want to. - The last declaration for a configuration is the one that's standing - could have an engine to detect config files changes. - A default config file (with overrides) is common Q: are there any properties that would be cumulative instead of replacing one with another? Q: A way to add rules and add hooks, ways to control inheritance? perhaps use _expression_ language Kuali RICE handles config files using Spring - Chris: might have this available in the Grouper Client? - the Client does not have Jar dependencies - make it as lightweight and easy as possible - Grouper client does not have EH cache, but does have EL - so where Kuali using Spring, then we can use EL (for aggregation part) - A property that should be EL-evaluated could have something added to its property name to identify it as such - Bill noted that the CAS project has been grappling some of these issues - Spring has robust options in these areas - also, can use a JSON file for some configuration aspects that need nested hierarchy - a JSON file can be more lightweight than using XML Q: is Spring used in PSP and Shib? A: Yes But Chris is just dealing w properties files, for Grouper Client, loader, API . - if you have XML config files , it is more complicated and a different problem ===== Treat privileges as Group lists (for Grouper 2.2 ) - Remove the pluggability of Grouper privileges (Group READ/UPDATE etc), treat them as group lists to improve WS operations, simplify the UI, etc - This means we would not honor the priv. interface anymore, so you can't plug in your own implementation of it - Then from the API operations, which cascade to WS operations, you can get the admin (or updaters) list of a group -if you are doing a membership search, you could filter by list or stem and see those memberships Q: This change is just for API, not a change in how privileges are kept in the databases? A: Right, but this could affect the admin UI, privileges could be handled list a list, with checkboxes. Q: should we do some other optimization behind the API? A: no not at this point Q: in the future should we think about treating this as roles? Should we manage Grouper's internal security using Grouper's roles and permissions? A: Issue is that performance issues could arise - It is good to be able to do a group find in one query - and with permissions that would not be possible to do in one query, due to allow / deny Q: what about priv inheritance (I am an admin in Group A, so also an admin in Group B) ? A; use rules for that Chris : We should get some examples or videos up IF <RULE about groups are in same stem> then assign that group to the admin list agreed, that would be a good video to have === Legacy attribute migration (for Grouper 2.2) Migrate from legacy attributes to the new attribute framework in a transparent way. The old API and WS and UI should still work correctly. Plan to migrate lists and hooks as well. - this is a good idea - won't be trivial to implement - must work on upgrade, to make it easy to migrate existing attribute assignments to the new approach - Chris is hoping there is an automatic way to migrate - some sites may need a GSH script for migration, if they have done customization - issue of hooks on the old attribute - unit testing the old APIs to be sure they still work will be important for the migration - is there a tool that might help with digging out dependencies? - Eclipse can help - large task, but we want it in Grouper 2.2 to keep the new UI as simple as possible ===== UNIX GID management (for Grouper 2.2) It's part of COmanage integration ===== Timeline and Priorities for Grouper 2.2 Possibly Q1 2013 - legacy attribute migration could be a difficult transition - legacy attribute migration will have the greatest timeline and greatest risk, so prioritize that ahead of treating priv. as group lists - Also, Services in Grouper can potentially be done later Next Grouper-Dev Call: Wed. 15-Aug. 2012 at noon ET Emily Eisbruch, Technology Transfer Analyst Internet2 office: +1-734-352-4996 | mobile +1-734-730-5749 Visit our website: www.internet2.edu Follow us on Twitter: www.twitter.com/internet2 Become a Fan on Facebook: www.internet2.edu/facebook |
- [grouper-dev] Draft Minutes: Grouper Call 1-Aug-2012, Emily Eisbruch, 08/10/2012
Archive powered by MHonArc 2.6.16.