Grouper Developers Forum

["Jessica Bibbee" <>]

Grouper Working Group Meeting

January 9, 2008

*Attendees*

Tom Barton, U. Chicago (chair)

Gary Brown, Bristol U. (stand-in chair)

Shilen Patel, Duke U.

RL "Bob" Morgan, U. Washington

 George Mathews, Fox Chase Cancer Center

Jennifer, Yuan. Pennsylvania

Chris Hyzer, U. Pennsylvania 

Bill Kasenchar, U. Pennsylvania

Tom Zeller, U.Memphis

Dave Donnelly, Stanford,

Joy Veronneau, Cornell U.

James Cramton, Brown U.

Ann West, EDUCAUSE/Internet2

Jessica Bibbee, Internet2 (scribe) 

Carry-over *Action Items*

[AI] {James} will report back to the Group with results of performance testing of v1.2.1. (12-Dec-07)

[AI] {Kathryn} will draft a proposal for future Ldappc work. (14-Nov-07)

*Agenda*

1. [BillK] UI analysis

2. [ChrisH] cvs projects and branching

3. More discussion of Grouper Web Services

4. [Joy] Populating directory with large groups

*Discussion*

-v1.2.1 Updates-

{James} reported that Brown has not tested the latest release of Grouper, but they do plan to report back to the group as they move towards its deployment.

-UI analysis-

{Bill} summarized his experience with the existing Grouper UI and shared a few of the items they have found to have shortcomings or, e.g., inconsistencies in the use of buttons. Delete has no confirmation box, which would be a useful safeguard against accidental deletes. He and others at U. Pennsylvania went through the different screens and identified what was a button, link, etc. and found inconsistencies, which they charted in a flow diagram.

When a person enters the UI, they are likely looking for either a group or a person, so the UI ought to cater to these views. They also recommend use of the term 'path' instead of 'stem', which is less common nomenclature. Due to the fact that a large organization may have multiple people with the same first and last names, they also would like to add additional items to ensure you are selecting the correct person. 

The Group also discussed which sources were associated with searches; it would be useful to have the ability to select which sources were searched, as many campuses may have multiple person subject sources. This raises issues around having either relational or LDAP sources.

Their work is not intended to address specific contexts, i.e., whether it is designed to use a java API or whether it will be a web services interface. Rather, it is meant to serve as a starting point for continued discussion and refinement of a UI to capture the best-scenario defaults for use by the community's use. {Bill and Jennifer} anticipate a working redesign by late spring of 2008. Detailed notes of these findings can be found in the wiki: < https://wiki.internet2.edu:443/confluence/x/sEo > Your use cases and feedback are welcomed and appreciated, and should be directed to the grouper-dev mailing list.

-CVS projects and branching-

The Group decided to postpone discussion of CVS projects and branching until the next Grouper WG call on 23-Jan-08.

-More discussion of Grouper Web Services-

{Bob} recommended that the Group clarify what exact functionalities are desired from an authentication system, as there seems to be confusion if the topic is too general.  How ought web services be reflected in the architecture? What should be included as part of the package to provide a plugable interface? There is likely a need for additional controls as to which server (or user) can do what. The backend should authenticate the middle tier, which actually specifies who is wanted to authenticate. {Bob} shared a local scenario where they expect the operations without the classic user context.

{Chris} hopes to collect a sampling of simple use cases to frame the web services work. It will be good to have a satisfy service authentication needs with whatever is on the backend, e.g., using certs, etc. {Bob} cited CAS proxying, and how it passes along a token in a plug-in type system; everything happens outside of the particular application, so there is not the need to provide the container, but just to check the container. Grouper could offer a web services component with an interface that allows portability, and hence variety for campuses. In particular, it means a plugable API to which people can attach whatever they want. {Tom} suggested sequencing work tasks such that they generalize sequences of authorization. Initial steps are not to be taken as final preclusions, but rather a place to branch from.

{Bob} shared a link to Acegi < http://www.acegisecurity.org/ > security framework, which is closely linked to the Springs framework.

-Populating directory-

{Joy} shared her experience with a large group having more than 190 thousand groups, which means a limitation of the directory for such a large group, and thus an increased loading time. A difference in security issues places concerns around large groups that are not public. Depending on the directory, per-attribute value and access controls may be possible. This discussion will continue on the grouper-dev mailing list.

The next Grouper Working Group conference call will be held on Wednesday, January 23, 2008 at 12pm EST.

-- 
Jessica Bibbee, Technical Analyst
Internet2

mobile: +1-727-369-6879

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