grouper-dev - Draft Minutes: Grouper Call 7-Jan-09
Subject: Grouper Developers Forum
List archive
- From: Emily Eisbruch <>
- To: Grouper Dev <>
- Subject: Draft Minutes: Grouper Call 7-Jan-09
- Date: Sat, 10 Jan 2009 13:44:41 -0500
**Grouper Call 7-Jan-09**
*Attending*
Gary Brown, Bristol U. (stand-in chair) Chris Hyzer, U. Penn Tom Zeller, U. Memphis Scott Koranda, University of Wisconsin-Milwaukee Renee Frost, Internet2 Ann West Internet2 Steve Olshansky, Internet2 Emily Eisbruch, Internet2 (scribe) *Carry Over Action Items* [AI] (TomB) will create a JIRA issue related to documenting security issues, such as view privilege potentially leading to read. [AI] (Bert) will send to Chris information on using a different SSL trusted route for the new Grouper client. [AI] (TomZ) will continue to look into future of ldappc and develop options for directions. [AI] (TomZ) will investigate wisdom in the Spring Framework for binary release and directory structure.
[AI] (TomZ) will record membership problems discovered at U. Memphis as Jira items. *Discussion* - Audit wiki page: related email: Gary summarized discussion so far: Chris made a case for using database triggers for doing point-in-time logging and notifications, suggesting it’s centralized, robust and efficient, and probably less work than trying to implement in Java. Chris considers user auditing as logging high level actions, which would still be implemented through JAVA. Tom Barton expressed some concerns, including 1. Portability, since triggers may not be available in some databases. This could potentially make it harder to market Grouper. 2. Concerns about long-term support of databases. Will the database trigger approach mean we have to support older versions of databases? 3. At the database level, when executing a trigger, will there be sufficient context to store all the info we want to store? Things available at the Java level might not be available at the database level. 4. Should we consider an approach where each API instance submits notifications separately, using a daemon rather than relying on database triggers? Comments on these audit issues: Gary said issue #3 (context available at database level) could be worked around. Each database row could have a context ID added to it. So when a high level operation is enacted in Java, the context ID is passed through and made available to the database for updates or inserts that take place. This way, any low level operations can be linked back to the high level operation enacted by a user. Chris agreed with this approach. Chris asked: If a membership is deleted and the point-in-time auditing has the membership ID, do we also want to have other identifiers like group name? If yes, we can do simple queries in the trigger. Gary noted that there is a question of how much data is stored directly and how much can be derived from the info that has been stored. On notifications, issue #4, Gary commented it’s harder to control and configure notifications via the API. If notifications happen through the database, they are less likely to get lost. We can make methods available through API and web services so any client interested in notifications can query for what has changed. Chris noted that implementing audit via database triggers won’t preclude us from doing Java later if some of the issues Tom raised turn out to be substantial problems. TomZ suggested auditing implementation in two phases: a phase one using database triggers and phase two using Java code. It was agreed that Chris would start with higher level, user auditing. But the group would wait for more discussion with TomB on the database trigger or Java approach. - Membership Foreign Keys Chris asked if anyone has issues with splitting owner of memberships into two columns: one for groups and one for stems that are mutually exclusive? Gary expressed his opinion that there is no problem with this. If the API doesn’t change, then there is no reason not to proceed with this approach. Chris is going to work on this issue also. - Namespace Transition wiki page: related email thread starts with: Gary explained that this issue is about copying or moving groups, a collection of groups, or a stem and descendent children. Can be important when: - when organizations change their structure - when things are created in the wrong place. - to save a structure in the repository that can be copied as a starting point for each new course - when a course module needs to be available to more than one course. There are questions around what should be preserved when moving/copying memberships, privileges, attributes, etc. The group agreed it’s important to maintain previous group stem names so it’s always possible to find a group or stem by a previous name. Chris proposed a phased approach. Suggestions for check boxes about which groups to keep with copy may be too elegant for first release. The person moving a group should have correct admin priv. Suggestion: for larger transformations, maybe only allow a sysadmin to do this. TomZ: wondering how to send these moves downstream. Systems need to be notified. Chris: Each update to the membership and group table puts a record on the notification table. TomZ: If we rename a stem, then when LDAPPC runs, it needs to process things in the order they were changed. LDAPPC could see a stem rename, and if groups are already renamed, it could ignore that. But right now, LDAPPC does not have access to change log or change queue. That was on the long-term plan for LDAPPC, but now it’s up for grabs how to do real-time notification based on provisioning. TomZ: suggestion to store UUID downstream, so when LDAPPC runs, it does lookups on UUID that never changes. Chris: keeping UUID in LDAP would be a good idea. It will helps when you delete a group and you only know UUID (not name) of what was deleted. - Attributes wiki page: related email: Gary summarized that Chris proposes ability to assign attributes to any grouper object: groups, stems, membership, members, and other attributes. Attributes can be useful for life cycle management provisioning and can help with filtering, queries and provisioning. Attributes allow sites to have custom metadata to integrate into existing infrastructure. Tom suggested we should look at implementing the same style of attributes across all of the objects we want to use. Look at how attributes are handled in LDAP directories or X.500. Chris: We already have a way to do group attributes and it’s primitive. Maybe as part of this effort, we’ll need to consider reworking group attributes. Possibly have two ways of doing group attributes with one being deprecated. Otherwise, it could make a lot of work for existing users to migrate to a new way of handling group attributes. Gary: first step is to create the proposal for how it should work. New suggested features include allowing multivalued attributes and allowing the same attribute for more than one type. Gary noted that adding attributes to lot of objects adds complexity to the API, Web services and UI. It’s important not to adversely affect performance. Tom suggested only the Grouper sysadmin should be able to define new attribute types that will be available. Chris thinks it may make sense to have an option for a more distributed security scheme if some power Grouper users don’t want to bother IT people. - LIGO Project and Grouper Scott explained that he is part of the LIGO project, funded by NSF. LIGO is starting to get to the point of deploying Grouper. There are about 600 people in the worldwide LIGO collaboration, which is led by MIT and Cal Tech. Local groups write up an MOU and are allowed to join the collaboration.There are 50-65 MOUs in place right now. There is a sister project in Europe called Virgo, that needs to be part of group structure. Then there are functional groups to help run experiments (e.g. four different data analysis groups). Within those there are subgroups for people doing certain things in their analysis. LIGO is also using LDAP with Shibboleth for authentication. Grouper will be central for helping LIGO manage using Grouper to manage membership in those groups and authorization. LIGO will dirve Grouper thru web services, PHP pages, and the UI to allow users to create their own groups and subgroups to manage authorizations for their sub-projects. LIGO is highly interested in the point-in-time auditing planned for Grouper 1.5. In general, what is the best way to convey a feature request to the Grouper-dev group? Gary suggested using Grouper’s email list or contributing to the wiki. The more you can record about requirements, the better. Gary: Would LIGO want to keep auditing info forever? Scott: Yes. Chris: Plan is to make length of time to keep audit data configurable. Scott said he has an account on the wiki. Withinn next couple of weeks, Scott will add a use case including diagrams, and link to it from the Grouper wiki auditing page.
- Next Call Next Call: Wed., 21-Jan-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! |
- Draft Minutes: Grouper Call 7-Jan-09, Emily Eisbruch, 01/10/2009
Archive powered by MHonArc 2.6.16.