grouper-dev - [grouper-dev] Draft Minutes: Grouper Call 3-July-2013
Subject: Grouper Developers Forum
List archive
- From: Emily Eisbruch <>
- To: "" <>
- Subject: [grouper-dev] Draft Minutes: Grouper Call 3-July-2013
- Date: Mon, 8 Jul 2013 19:43:35 +0000
- Accept-language: en-US
- Authentication-results: sfpop-ironport01.merit.edu; dkim=neutral (message not signed) header.i=none
Draft Minutes: Grouper Call 3-July-2013
Attending
Tom Barton, U. Chicago (chair)
Chris Hyzer, University of Pennsylvania
David Langenberg, U. Chicago
Shilen Patel, Duke
Andrew Petro, Unicon
Jim Fox, University of Washington
Emily Eisbruch, Internet2, scribe
New Action Items
[AI] (DaveL) will start a wiki page about provisioning future.
[AI] (Andrew) will let us know what emerges from the Apereo security notification process work.
Carry Over Action Items
[AI] (Tom) add to the agenda for a future call: steps towards getting more info on who is using Grouper (pending)
[AI] (Shilen) email users lists to ask who is using the legacy attributes and ask how they are using them
[AI] (Emily follow up with Jeff around adding to the community requests table his idea for additional attribute functionality in the new UI (for post-2.2.0 release).
DISCUSSION
Should shipped config have group READ & VIEW default off?
Based on discussion on the list, the decision is to default READ and VIEW to OFF starting with the next Grouper release.
Chris updated the JIRA
Related issue:
Should Grouper support for READ and VIEW defaults-by-stem? Inheritence? By rules or otherwise? Just these privileges?
Chris: Penn users a rule as a marker for external users, since external users should be included only in certain folders.
For external members, the system "climbs up the tree" and checks in each folder for the rule. If the rule is not there, it gets the default from the config.
It would be possible to handle this READ and VIEW default issue using this same inheritance approach.
A deployer puts the rule in the right place and the inheritance mechanism happens.
Q: Does "climbing the tree" create unnecessary overhead ?
A: it is only for creating a group. But could have a config setting to turn off this feature
Decision: we may work on this feature in the future.
Chris created JIRA https://bugs.internet2.edu/jira/browse/GRP-918
Privileges on Permissions: Functional? Performant? Manageable?
Before Legacy Attribute Migration work moves forward, Shilen plans to add a couple of new privileges controlling who can read and update attributes on a group,
stem or AttributeDef, as outlined here:
https://spaces.internet2.edu/display/Grouper/Adding+attribute+read+and+update+privileges
Currently, in Grouper 2.1, group READ privileges are needed to allow reading an attribute on that group.
Under this proposal one would need GROUP ATTRIBUTE READ" privilege on the group.
It was noted that these new privileges may be challenging for users to understand. Tooltips will help.
A reasonable approach for a campus is to give the administrators GROUP ADMIN privileges (for assigning permissions), and only vary from that if needed.
PSP/provisioning Strategy
-DaveL has been analyzing PSP strengths and challenges
-PSP is extensible
-Not fast enough for all use cases, partly due to SPML foundation
-There are advantages to smaller and more efficient modules
-Jim: U. Washington is looking into MongoDB for document store
-MongoDB may replace LDAP for some use cases
-Would need different provisioning
-Jim will investigate whether there is a SCIM-to-MongoDB interface
-MongoDB uses a JSON data structure, uses puts and gets
-Grouper's REST API may need to be adapted, especially given the focus on REST in the CIFER project.
-Grouper's relational backend can be a drawback for scaling.
-With REST becoming more common, perhaps point-to-point connectors make more sense that a generalized provisioning engine like PSP
-Currently most sites using PSP use it for provisioning to LDAP and AD systems
- These would both be adaptable to a good point-to-point solution
-The provisioning engine approach (solve provisioning once with various connectors) sounds better than it actually is.
-It was agreed that it makes sense for the Grouper project to stop investing in PSP, which is a provisioning engine based on SPML
-For the SURFnet and SCIM work that is planned, the direction is to develop a change log consumers, more of a point-to-point approach
-It's important to ensure the point-to-point modules can work in parallel or can chain together to populate several consumers
-parallel processing will be part of the design
Q: Shilen: When using the change log for provisioning, what about the need for bulk synchronization?
A: DaveL: there will also be a mass reconciliation option
Grouper would need to interface with
-change log consumer (incremental) approach, AND
-bulk processing
[AI] (DaveL) will start a wiki page about provisioning future.
Dave's first focus will be on the SURFnet and SCIM work.
Then look at the issues around LDAP and AD point to point connectors.
Determining Who is Using Grouper
-What is the and Apereo and uPortal experience around determining who is using an open-source tool?
-Andrew: Apereo is looking at how to communicate with known adopters around security notifications
-Security notifications is a strong motivation for users to register.
-Processes and practices are being worked out.
[AI] (Andrew) will let us know what emerges from the Apereo security notification process work.
Next Call: Wed., July 17 at noon ET
Emily Eisbruch, Technology Transfer Analyst
Internet2
office: +1-734-352-4996 | mobile +1-734-730-5749
Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2 Become a Fan on Facebook: www.internet2.edu/facebookin leu |
- [grouper-dev] Draft Minutes: Grouper Call 3-July-2013, Emily Eisbruch, 07/08/2013
- Re: [grouper-dev] Draft Minutes: Grouper Call 3-July-2013, Scott Koranda, 07/08/2013
- Re: [grouper-dev] Draft Minutes: Grouper Call 3-July-2013, Tom Barton, 07/09/2013
- Re: [grouper-dev] Draft Minutes: Grouper Call 3-July-2013, Scott Koranda, 07/08/2013
Archive powered by MHonArc 2.6.16.