Grouper Developers Forum

["Jessica Bibbee" <>]

Grouper Working Group Meeting
January 10, 2007

*Attendees*
Tom Barton, U. Chicago (chair)
Gary Brown, U Bristol
Joy Veronneau, Cornell U.
Steve Olshansky, Internet2
[Jessica Bibbee, Internet2 (scribe)]

Carry-Over *Action Items*
[AI] {Blair} will begin profiling the API to for performance issues, based on {Shilen's} recent thread on the grouper-user list. (13-Dec-06)
[AI] {Joy} will share a write-up of a Cornell use case for the provisioning connector regarding the preservation of a query for group attributes. (9-Nov-06)

[AI] {Stephen L. and Blair} will speak offline regarding the development of additional interfaces. (6-Sep-06)
[AI] {Stephen L.} will pass along a link to their CVS for a model similar to the Grouper object model, including use cases and code. (6-Sep-06)
[AI] {SteveO} will work with {Tom} to create higher-level screenshots. (12-Jul-06)

*Agenda*
1. Near-term plans for the grouper api
2. Longer term plans for grouper
  . recording & propagation of changes
  . and more, depending on funding
3. Sig-Gro LDAP Connector v1.0 release this Friday (with a little luck)

*Discussion*
{Joy} is still working on the Cornell write-up of LDAP security; she will submit it as it is readied.

In {Blair's} absence, {Tom} highlighted the near term plans for the Grouper API: 1) there will be no major function changes, but some 2) internal refactoring, and 3) an improved DAO layer, all of which should lead to performance improvements. Transaction processing in the API is a consideration, but not in the near-term. {Gary} mentioned a list of check-ins, whether a member UUID is used or changed, etc. Columns in the table will need to be updated. The next release of Grouper may be as soon as March.  As for the UI, {Gary} said that he would like to address UI issues around stem search, e.g., when there are large trees with permissions across 20 thousand groups, though this change is time-dependent.

{Tom} briefly discussed how the funding model for Grouper is changing this year, dependent on an NSF proposal. It is possible that Grouper will have some connection with VO work, which may include adaptation of Signet/Grouper in that area.

The next big functionality enhancement will pertain to the roadmap, which will offer support on several items, e.g., changes in history. The idea is to start out with schema support for changes; every functionality transaction corresponds to a subset of API and would be encapsulated, so direct/indirect consequences of that management operation would be an atomic thing transported for tables. With that infrastructure in place, there would be different ways of putting them out to world, e.g., 1) have a string representation that is logged, 2) log4j fender, ways to take that and put in infrastructure in automation basis; a lightweight integration architecture and 3) EDDY architecture, part of the Middleware End-2-End Working Group, which offers external analysis archiving that can be mapped to variety of applications. Grouper can leverage their work and the increasing infrastructure out there. Likely, an EDDY adapter for Grouper will result, which will take Grouper management events and source them into an EDDY backplane. The EDDY analysis can operate on Grouper events.

This work may also lead to the notion of federating Grouper. For example, there may be multiple Grouper instances, you wanted to refer to a group within a set application that is a union of groups residing in different instances. {Tom} expressed interest in a published and scribed approach to integrating multiple instances; external auditing would be beneficial asking who is in a group, etc.

{Tom} emailed the Working Group with notice of the LDAP Connector v1.0, now released: <https://wiki.internet2.edu:443/confluence/x/FSU>.  (c.f. Tom's email, 12-Jan-06)

{Tom} discussed a more integrated QuickStart across Signet/Grouper, including the LDAP connector, LDAP directories, an apache web server – basically the entire mock-up environment. It may need to be put in a VM.

Regarding the Subject API, Signet/Grouper will work on standardized interfaces, with interoperable standards for managing groups and picking people and other subjects, especially those that can work in a federated context. There will also be web services and java bindings for those standards in reference of the implementations.

Another functional item of priority is aging and reactivation. Signet and Grouper will use the same rule process, along with hooks. Other items included namespace transitions and using audit tools by means of having an appropriate EDDY tool. {Gary} expressed interest in using Signet to control permissions in Grouper, but this is still in an idea stage.

The next Grouper Working Group call will be on January 24, 2007 at 12pm EST.

-- 
Jessica Bibbee, Technical Analyst
Internet2

mobile: +1-734-255-6644

Wishing you an inspired and innovative 2007.
http://www.internet2.edu/greetings/newyears2007/