Grouper Developers Forum

[Emily Eisbruch <>]

Grouper Call 1-Apr-09**

 

 *Attending*

 

Tom Barton, U. Chicago (Chair)

Gary Brown, Bristol

Shilen Patel, Duke

Chris Hyzer, U. Penn

Tom Zeller, U. Memphis

Ann West, EDUCAUSE/Internet2  

Steve Olshansky, Internet2    

Emily Eisbruch, Internet2 (scribe)

Action Items*

[AI] (Gary) will investigate UI queries of user audit (when the API user audit code is available from Chris). 

[AI] (TomB) will ask Mark Pepping about XML standards for auditing data.

[AI] (TomB) will capture on the attribute framework wiki page information on handling of custom versus non-custom fields/attributes.

[AI] (TomZ) will ask the grouper-dev list about having ldappc produce SPML for more flexible provisioning, among other patches.

 

Carry Over Action Items*

 [AI] (TomB) will start a wiki page on attribute framework for Grouper. 

*Status for Grouper v1.5 Enhancements*

*Group/Stem Move and Copy Status*

Shlien reported that things are going well with group/stem move and copy. The next steps will be to get this feature integrated with the UI and into web services.

Should a browse feature (to specify the move/copy destination) be provided for integrating group/stem move/copy with the UI?  Should destinations be stored for future re-use?

Decision: The best approach is to do the simplest possible implementation and then see if there is a request for change. For the first cut it will be required to type in the move/copy destination.

*User Audit Status*

Chris reported that user audit import/export is done.  Plan is to set some context info in UI and WS and loader. 

User audit integration with the UI was discussed. Chris noted that the easiest approach is to have admins do queries on the audit logs. There will be a gsh call that would allow queries by ANDed criteria.

Should any audit data be exposed thru web service? Possibly yes, in a release after Grouper 1.5, if requested by people in the field.

Gary will advance thinking user audit query in the UI.

[AI] (Gary) will investigate UI queries of user audit (when the API user audit code is available from Chris). 

*Notification Status*

Plans are to have an event table and event type table. 

Every action at the database level would insert a record into the event table.  This will be Java-based in first pass. In next pass, ldappc could have complex filters. 

How much history to maintain? Should we allow the table to become huge, or use a push system (perhaps eventually a puller) to move history to an archive after an event is successful?

Method of handling history (timing and destination) should be configurable by the site.  Archiving of notification events should be allowed internally to Grouper or externally.

Issue: If archived events are replayed much later, things  might not be reproduced correctly.  If using UUID, things may have changed.  It will be helpful to put context ID in notification table.

How does point in time fit and how is it possible to do point-in-time audit/notification in a high performance way?

User audit events are one-to-many with notification events. Example: the user event “Add group as member to another group” creates many notifications.

Has someone worked out XML structures for audit? Should we try to find a standardized format?  

[AI] (TomB) will ask Mark Pepping about XML standards for auditing data.

Q: When we modify tables, what will / should happen XML?

A: We will map java objects to XML attributes.  If we change the underlying structure we can map it differently.

Put a version tag on the XML. People who use it will need to look at version and do conditional processing or ignore extraneous elements.

*Attribute Framework*

Is it acceptable to treat standard attributes differently from custom attributes for optimization reasons? 

TomZ noted that it is desirable to treat standard and custom fields and attributes similarly or at least to be sure that they behave/appear similarly. 

[AI] (TomB) will capture on the attribute framework wiki page information on handling of custom versus non-custom fields/attributes.

Ldappc Going Forward

TomZ has been looking at other tools, such as Spring and Shibboleth. The goal is to use existing tools where possible. 

[AI] (TomZ) will ask the grouper-dev list about having ldappc produce SPML for more flexible provisioning, among other patches.

Don’t want to assume ldappc will be end-to-end and we will control everything along the way.

Chris : Currently there are four stand alone processes that run for Grouper. If there is not a compelling reason to make the new ldappc a stand-alone, WS type thing, then it’s one more thing to maintain and it will be better to use a different approach. 

TomZ: U. Memphis doesn’t have a provisioning system live on same box as DB because of firewall considerations.

Chris: Wherever you run your loader is where new ldappc should run, in the same process. Loader job is what’s reading off the queue.

Suggestion was made to have a separate loader instance that’s running that loader job.

TomB: Should “spoon” for new ldappc be pluggable? A different spoon might create the complete notification description?

Yes, can put a hook on that so you can do what you want to any notification. Ldappc will be like any other notification consumer: Interface based and registered in a config file. Hooks will be in place so we have a couple of choices.

Suggestion to provide a web front end to the loader job.

Sometimes a server goes down, causing the process to fail. There will be further discussion about monitoring and making Grouper monitor-friendly in a future call or on emails. 

*Next Call*

Next Call:  Wed., 15-Apr-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/