Grouper Developers Forum

[Emily Eisbruch <>]

Draft Minutes: Grouper-dev Call 9-Nov-2011

Attending

Chris Hyzer, Penn,  (stand-in chair)
Shilen Patel, Duke  
Tom Zeller, Unicon 
Jim Fox, University of Washington  
Steve Olshansky, Internet2  
Emily Eisbruch, Internet2 (scribe)

Carry Over Action Items

[AI] (All) Review Jira issues for the next release and ensure they are properly fleshed out. 

[AI] (TomZ) will review the Grouper LDAP Loader doc and provide feedback to Chris, possibly with lessons learned from LDAPPC work. 
https://spaces.internet2.edu/display/Grouper/Grouper+-+Loader+LDAP

[AI] (TomZ) will update JIRA to reflect the priorities  

[AI] (Rob) will follow up with Danno on obtaining the server for the Continuous Integration Environment.  

[AI] (Everyone) review Rob's chapters and give him feedback on the Grouper Users List.

DISCUSSION

Entities

https://spaces.internet2.edu/display/Grouper/Grouper+user+managed+entities

-  The Entities feature Chris has been working on does not add a lot of new functionality.
- It was always possible to have a group without members
- But Entities makes this more obvious -- that a certain group is intended to represent an external thing, such as a schema
- The user experience expert at U Penn has strong opinions on what to name the entities feature
- The naming issue will be taken up and decided when TomB is able to join the call.

Subject Search Performance Enhancement (and Grouper session requirement)

https://bugs.internet2.edu/jira/browse/GRP-691  (option to require Grouper session when doing subject lookups)

- In Grouper 2.0 and before, there is an order n issue with subject search queries on groups.
- Chris tried to fix that in Grouper 2.0 by adding a limit on number of results being returned.
- Unfortunately, this fix did not solve the problem; apparently the unit testing did not test with enough data
- Chris has now added a new feature in the subject API, where a query returns just the first page of data
- The prevents the problem of a search returning a huge number of members
- For databases it's easy, and it works well in the UI and in web service
- for LDAP, the LDAP request can specify the max # of records to be returned. TomZ will test this.

Another issue:
- To do a group subject search in a query, it's necessary to use the Grouper session
- A subject search determines if the results are in the cache; if not, the search is performed  and gets adds it to the cache
- The user you are acting as must be in the cache key, so the cache results are also secure
- This means you must have a Grouper session open when a subject search is done

- Nevertheless, if you do a subject search without a Grouper session open,  the root subject gets used
- We should keep that behavior in Grouper 2.02 so scripts will still work
- But in Grouper 2.1, we should change the default option in Grouper.properties so there must be a Grouper session open
- This makes it clear that security exists,
-  If a site wants less security, they will need to change the default in Grouper.properties
- All on the call agreed with this plan


Subject Attribute Security

https://spaces.internet2.edu/display/Grouper/Grouper+subject+filter+and+attribute+decorator

- One of the next items Chris hopes to work on is the subject attributes and subject filter
- This enhancement will facilitate secure subject attribute release. 

There are various ways to protect data when a subject search occurs:

1. Change the data to protect it (the user will see the subject, but might only see the NETID instead of the name)
2. Decorate the attribute names (this involves taking in a list of attribute names to decorate the subjects with)
3. Could  just say "protected-data"
4. Remove the subject from the results  ( the user will not know the subject exists )

Potential Use Cases where this security is needed:

    -  to protect FERPA information -- can use filter subjects method -- if a person is an admin they see data, otherwise they don't
    -  to create private subdomains of Grouper where users from one might not be able to see subjects in another (this could  apply to a COmanage situation)
    -  to create attributes which can only be seen by certain subjects

Related to that last use case, Penn (and possibly PSU ) have a need for person attribute security with permissions
- This would not be exposed thru UI
- Thru the web service, you specify which subject attributes you are interested in
-- Query to see if those attributes are allowed for that subject
- If allowed, those attributes get returned in web service

Q: Will you wil need to add attribtue to subject itself to have the info make the decision?

A: No, the info to make the decision of who gets the permissions is done through a call to a batch

Examples  of implementing the subject attribute security are found on the wiki page at   
https://spaces.internet2.edu/display/Grouper/Grouper+subject+filter+and+attribute+decorator

If there are common cases, we could provide some built in implementations with some configuration.

JimF: you mentioned a couple of ways to protect data: 1) show netID instead of name, OR 2)  remove the subject.
Of these, 1) seems preferable.

Chris : for the FERPA use case this is right, but for the possible COmanage use case, you may not want to see subjects outside of your own collaboration.


LDAPPC-NG (renaming, alternate stem name, etc)

TomZ is still finalizing the LDAPPC NG work
Shilen will do the work around alternate stem name

Shilen: we will assume that alternate names with a move will apply to both stems and groups

TomZ: it will not make sense to do a full sync if someone tries to rename the stem and the LDAP server does not support stem rename
Just need to sync the stem that is changed, because that will create the new stem. 
Later the full sync job runs, and it will remove the old one
This would be faster and would be sufficient

Q: Shilen: in the long run, is full sync needed in order to correct things like this, or in the long run could incremental take care of everything?

A: TomZ: in long run, we can use change log for everything.
But since this is new, use the sync. As we get more experience w the change logs, we could suggest that the full sync is optional

- Q : Shilen: When do you need the alternate stem name done?
- TomZ: Hope to finish up all tests and the code this week
- After Thanksgiving will cut a snapshot and give it to folks to try it
- Would be good if after Thanksgiving the stems can have alternate names

Index Issues

The index issue Chris had emailed about got resolved.

On the topic of indexes, in some tables, like Grouper memberships, there are multiple columns: 
- owner group ID 
- owner stem ID  
- owner attribute def ID
- owner attribute  (this contains one of the above 3)

changing this structure could reduce the number of indexes.
Decision is to leave it as is for now.

Box.net Groups and VOOT

Chris noted that there is a chance the Grouper Dev team will be more involved in Box.net groups in the future, to date there has not been a lot of involvement

Chris sent email to Leif about VOOT to see if there is interest in Grouper team becoming more engaged with VOOT

https://github.com/andreassolberg/voot/wiki/Protocol

Haven't heard back yet, maybe in future we will get engaged.


Next call is Tuesday, Nov. 22 at noon ET. 

Note : Change to TUESDAY for this call, due to Thanksgiving 

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/facebook