Grouper Developers Forum

[Emily Eisbruch <>]

**Grouper Call 21-Jan-09**

 

 *Attending*

 

Tom Barton, U. Chicago (Chair)

Gary Brown, Bristol U.  

Bert Bee-Lindgren, Georgia Tech

Chris Hyzer, U. Penn

RL Bob Morgan, U. Washington

Tom Zeller, U. Memphis  

Ann West, EDUCAUSE/Internet2

Steve Olshansky, Internet2    

Emily Eisbruch, Internet2 (scribe)

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

https://wiki.internet2.edu/confluence/display/GrouperWG/Auditing

*Discussion*

New Working Group

A new working group has been established in place of the retired Signet-dev group.  This is a topic-centered  -- not product-centered -- working group. It will meet every second Friday at 11am ET. The group will include discussion of privilege management issues and problems, and a survey of available approaches and solutions. The group will continue to talk about the possibility of layering privilege management capabilities on top of Grouper. 

GRP-199 - read and view privileges

There was brief discussion of GRP-199, the issue of view privileges potentially leading to read. This item has been fixed, though not closed. Bert asked about the related issue of read privileges persisting after permission removal. The group agreed that addressing this is not a high priority. TomB suggested that Bert note this issue in JIRA so it does not get lost.

GRP-212 - expand two grouper_memberships cols so we can add foreign keys

Chris reported that GRP-212 has been completed. 

https://bugs.internet2.edu/jira/browse/GRP-212

This fix had some impact on the API, affecting those who happen to be using via or owner. The group discussed the impact of such changes on Java developers. Marking the Java docs was discussed.  Bert proposed a public interface, a “wrapper” to the API.   Chris suggested that we leave things as they are, with the knowledge that Java developers may have to recompile when changes are made. 

ldappc and Grouper 1.4.0

ldappc was not compatible with the Grouper 1.4.0 release.  TomZ has been fixing this issue and needs a few days to wrap it up, including fixing a bug in code called from gsh and modifying some documentation on the website.  TomB will make the fix available when it is ready via a link on the website, and the official 1.4.1 release will follow.

Notification and Provisioning LDAP Going Forward

ldappc via gsh is the main interface for connecting Grouper with LDAP. How should notification be implemented? Should there be separate hooks? 

Bert suggested that – on the authorization side – we should be striving for rapid (one minute or less) LDAP reflection of Grouper changes. Chris stated that it is realistic to query notification table every minute.

Chris noted that U. Penn uses a notification-based approach, and that this is a good way to do incremental provisioning. It’s less chaotic and better defined than using hooks.

Bert: Georgia Tech maintains two states: provision state and database state. The system looks for where the two columns are note the same, does LDAP differencing.  Chris: This approach can mean lower performance if tables have a large number of records.

How should notifications from multiple systems be handled?

Should a queue be created (has the advantage of providing sequencing) or should a flag on a row be used to indicate changes? TomB noted that there may be value to keeping work items for rollback and recovery purposes. 

TomZ: U. Memphis uses two methods to handle rollback and recovery: 1) Repair the whole thing (this can be difficult for extremely large groups due to processing time), or 2) maintain a single queue that includes person changes, password changes, and group changes. This single queue ensures that things work in the right order, and it’s subject to processing times. There are problems with removing something; hard to know what to do downstream. This part is not solved.

Bob: U. Washington uses a home grown message queue approach.

Gary: Bristol U. uses SQL scripts and cron jobs. They do not yet have a genuine notification.  

[AI] TomZ will send to the list a summary of the strands in the group's discussion on notification.

Approach to Auditing

TomB supports the approach of using database triggers for auditing, discussed on the 7-Jan-09 Grouper-dev call.

[AI] Chris will update the wiki page on auditing and notification. 

https://wiki.internet2.edu/confluence/display/GrouperWG/Auditing

Next Call

Next Call:  Wed., 4-Feb-09 at noon ET 

Emily Eisbruch, Technology Transfer Analyst

Internet2

office: +1734-352-4996 | mobile +1-734-604-5562

Imagination. Collaboration. Innovation.

May your New Year be filled with Discovery!

http://www.Internet2.edu/NewYear2009/