Grouper Developers Forum

["Jessica Bibbee" <>]

Grouper Working Group Meeting
October 31, 2007

 

*Attendees*
Tom Barton, U. Chicago (chair)

Gary Brown, Bristol U.

Shilen Patel, Duke U.

Celeste Copeland, Duke U.

Joy Veronneau, Cornell U.

James Cramton, Brown U.

Steve Carmody, Brown U.

Jeff Van Eeuwen, SNtial Technologies

Renee Frost, Internet2

Steve Olshansky, Internet2

Jessica Bibbee, Internet2 (scribe)

 

New *Action Items*

[AI] {Shilen} will put a new issue in JIRA, re: API changes proposed for v1.3.
[AI] {Shilen} will send a message to the Grouper-dev list re: groupmember query class  - pros and cons
[AI] {Gary} will look into whether it would be advisable to split JIRA GRP-7 into sub-issues
       < https://bugs.internet2.edu/jira/browse/GRP-7 >
[AI] {Tom} will send a link to Introduce out to the Dev list.

[AI] {Tom} will email the Group with more information on potential Ldappc modifications.

 

*Agenda*

1. Performance fixes for v1.2.1. C.f. attached v1.2.1-issues.jpg, or go to <https://bugs.internet2.edu/jira/browse/GRP>, choose "Road Map", select "1.2.1", click on "Pr" table column to sort in priority order.
2. Open-mic on roadmap priorities. Cf. <https://wiki.internet2.edu/confluence/display/GrouperWG/Priorities+for+Functional+Enhancements >

3. Integrating a (Grouper) Web Service with Enterprise Access Management.               

*Discussion*

- Performance fixes for v1.2.1-

 

{Shilen} reported that he spoke with the DBA at Duke to see if the Oracle database could be tuned, re: GRP-7; he was told that there was not much to be done on their end. {Gary} said he will rethink what can be done on the API end.

 

{Tom} discussed open and resolved issues in JIRA, as they pertain to GRP-7. 

 

{Shilen} spoke on the completion of GRP-48. Another issue focused on changing the way child stems and groups are determined, by using the name of stems in group, instead of using the API and moving up the hierarchy to change them. A third issue has been to rework queries related to groups to perform functions in one step and be able to pre-fetch attributes; they are now in testing. He also mentioned Gary's idea do privilege checking after the subject queries are executed; while this is an excellent idea, they have not had a chance to try doing so. He said that the filter classes are public, such that anyone can directly call. This could mean that essentially no privilege checking is happening. It would likely have a potentially large impact, depending on the type of query. The actual modifications would be simple, making changes in the API to change the methods from public to protected, and he said this issue might fall outside the scope of releasing v1.2.1. [AI] {Shilen} will characterize in JIRA the API enhancements for v1.3

 

{Shilen} proposed a new query class called groupmember, where the UI would call in inquiry that ends the member filter and another, e.g., attribute filter, such that the results are returned without the UI having to do more computation. {Gary} agreed that the proposed query class might be more efficient. He suggested an optional configuration in the UI, such that it could be used only if person has a reasonable number of memberships (50-100), and not several thousands. [AI] {Shilen} email the Grouper-develop list with a description of a proposed groupmember query class and its pros/cons.

 

{Gary} had no specific progress to report on GRP-7, but he has been looking at {Shilen's} concerns around TAAdmins. He is looking into Your Kit and has a fix, but has not submitted it to CVS yet. {Gary} is also addressing issues with privilege checking and suggested that there are related caching issues to resolve. For example, the API checks to see who is a  member of the wheel group, such that memberships information is not being cached. Doing a Can View check, the subject view of this group ends up being 6 separate calls; the more groups, the slower the query becomes for checking privileges. More ideally, this could be refactored so that a single query is made, then you could check against it 6 times.  He plans to spend time figuring out how to best remedy these issues. [AI] {Gary} will review changes involved for GRP-7 and report back to the Group on what is feasible for v1.2.1.

 

{Tom} addressed a request for more schema documentation (GRP-50), specifically on the relationship of columns and tables and how they work in Grouper, i.e., relationships are not implemented with foreign keys, etc. Is there other documentation that people are looking for? {James} said that at Brown, they have done some reverse engineering, looking into using figures in the database to figure out a solution for performance, such that they can identify groups that need to be provisioned into Ldappc. They will continue to seek out answer to English translations to SQL queries that they are trying to identify.  {Tom} said it (change notification) is an item that they will agree to do as soon as possible.  

 

{Tom, Steven, and Jeff} spoke about potential modifications to Ldappc. {Jeff} described a scenario where you have initially provisioned all (e.g., departmental) groups, but you then wish to provision just a subset of those groups. A groups entry synchronizer keeps track of what has or has not been provisioned and identifies what to compare against. On the memberships side, if provisioning group memberships to subject entries in the directory, it is now kept track of as an attribute in a list, and you have to identify all elements in the list to compare against. Modifications to Ldappc might address Brown's concerns around provisioning a specific subset of groups or memberships. [AI] {Tom} will email the Group with more information on potential Ldappc modifications.

 

For more information, go to <https://bugs.internet2.edu/jira/browse/GRP>, choose "Road Map", select "1.2.1", and click on "Pr" table column to sort in priority order.

-Upcoming Release v1.2.1 Timeline-

The Group agreed that Grouper v1.2.1 should aim to release at the end of November, whether or not all of GRP-7 is addressed. {Joy} mentioned that they are getting closer to testing and will mostly check the changes in CVS.

 

The Group agreed upon the target release-timeline:

     November 14 – last call for changes to be incorporated

     November 16 – code freeze; announce Release Candidate 1

     November 30 – Close RC testing/feedback period

     December   3 – announce release v1.2.1

 

-Open-mic on Roadmap Priorities -<https://wiki.internet2.edu/confluence/display/GrouperWG/Priorities+for+Functional+Enhancements >

 

{Tom} turned the discussion over to the Group, to voice items of importance on their campus.

 

{James} mentioned that Brown is focused on finding a nearer-term solution for timelier Ldappc provisioning, along with their primary need for Notification of Changes.

 

{Bob} said U. Washington is currently working towards development and is now mostly interested in potential web services. {Tom} asked how they might be using to ensure the web services from various parts of the infrastructure work together.

 

{Shilen} agreed that web services are also very important at Duke, as it will enable people from all over their campus to use Grouper without using the packaged UI.

 

{Joy} also voted for web services at Cornell; for now, they have written a minimal service with 2 API commands that will suffice for their deployment.

 

{Tom} mentioned the work of {Steve Langella} at OSU, who has wrapped Grouper in a web services API to produce GridGrouper. They used Introduce to create web services protected by Globus security infrastructure. See {Tom's} email appended below, with a link to Introduce.

 

-Integrating a (Grouper) Web Service with Enterprise Access Management-

At U. Washington, web services are protected by certificates, e.g., SSL.  At Cornell, they will use Kerberos to authenticate applications to Grouper. They will trust the application to authenticate the user.

 

{Bob} mentioned discussion around Kuali Identity Management at the recent EDUCAUSE Annual conference in Seattle, WA. For example, {Aaron Godert} of Cornell presented on Kuali Rice: < https://test.kuali.org/confluence/display/KULRICE/EDUCAUSE+October+2007 >. There may be many interesting opportunities for interaction regarding use of applications.

 

{Tom} suggested the Group consider ways to specify how a general application will interact with access or group management services.

 

The next Grouper Working Group conference call will be held on Wednesday, November 14, 2007 at 12pm EDT.

 

*****************************************

 

-C.f. {Tom's} email to the Grouper-dev list on 1-Nov-07, subject: Links to Introduce and GridGrouper-

 

Main Introduce website:
< http://www.cagrid.org/mwiki/index.php?title=Introduce >

Best ppt about it:
< http://bmi.osu.edu/resources/presentations/Introduce-OGF19.ppt >

And while we're at it, here's the main GridGrouper website:
< http://www.cagrid.org/mwiki/index.php?title=GridGrouper:Main >

I recently learned that GridGrouper has been very successful in 3 NIH-funded grids to which it has been deployed. The reasons seem to be: it's easy to install (leading to research groups sometimes installing their own to manage access to their apps and resources rather than using a centralized GridGrouper instance, even when those are running on the common grid); it solves real problems that have been intractable until now (e.g., using delegation and group math); it is well integrated into the process for developing and managing grid applications (using Introduce), and its UI is easy to use. In short, the folks at OSU's Multiscale Computing Laboratory did a really nice job with it.

-- 
Jessica Bibbee, Technical Analyst
Internet2

mobile: +1-734-255-6644

The Internet2 Dynamic Circuit Network:
Unleash your Interdomain Imagination
http://www.internet2.edu/network/dc/