Child pages
  • Grouper Call 31-July-2013
Skip to end of metadata
Go to start of metadata

 Minutes: Grouper Call 31-July-2013

Attending

Tom Barton, U. Chicago (chair)  
Chris Hyzer, University of Pennsylvania  
David Langenberg, U. Chicago
Jim Fox, University of Washington
Shilen Patel, Duke
Steve Olshansky, Internet2
Emily Eisbruch, Internet2, scribe

New Action Items

[AI] (Tom) request additional support for security testing of Grouper

[AI] (SteveO) develop a security form for Grouper.https://spaces.internet2.edu/display/Grouper/Grouper+Security+Issue+Report+Form

[AI] (SteveO) set up a Grouper Announce email list for security announcements and release notifications

[AI] (Chris) inform the list about the new security form and list
(when they are ready)

[AI] (Shilen) work on the web services security patch and let Chris know when it's ready

[AI] Chris will prepare Grouper 2.1.5 release

[AI] (Dave) will follow up on LDAP to Grouper Provisioing issue

{AI] (Dave) will touch base with TomZ around PSP support issues

[AI] (Chris) will put the Subject API / abstract class issue on the release steps wiki page

[AI] Chris will consider Subject API Security by realm related to the new Grouper UI

Carryover Action Items

[AI] (DaveL) follow up with SURFnet for architecture diagrams etc.

[AI] (Andrew) will let us know what emerges from the Apereo security notification process work.

[AI] (Shilen) email users lists to ask who is using the legacy attributes and ask how they are using them

DISCUSSION

Grouper security - quick review of testing, what constitutes a security issue, notification process
 
Chris developed a patch for a recently reported security issue.

[AI] (Shilen) will work on the web services security patch and let Chris know when it's ready

[AI] Chris will prepare Grouper 2.1.5 release, including the patches and a few other items

If possible, it would be helpful to contract with a resource to do a "Pen Test" of Grouper

[AI] (Tom) will request additional support for security testing of Grouper

Makes sense for Grouper to adopt a security form like Shib has used in the past. This would be a dedicated security reporting page where a user can submit a security concern or vulnerability. Submissions from this form would go to the Grouper-core list for assessment. When a patch is available, there is a public notification to the Users list

[AI] (SteveO) develop a security form for Grouper https://spaces.internet2.edu/display/Grouper/Grouper+Security+Issue+Report+Form

Makes sense to establish an Announce list for users who wanted security notices without the other traffic on the users list (this has been requested)

[AI] (SteveO) set up a Grouper Announce email list for security announcements and release notifications

[AI] (Chris) inform the list about the new security form and list (when they are ready)

Provisioning Issues on the Grouper Users List

[AI] (Dave) will follow up on LDAP to Grouper Provisioing issue as described here:https://lists.internet2.edu/sympa/arc/grouper-users/2013-07/msg00020.html

Dave will talk with TomZ about PSP support issues to be sure that there is a procedure so no inquiries fall through the cracks

{AI] (Dave) will touch base with TomZ around PSP support issues

Subject API Security by Realm https://spaces.internet2.edu/display/Grouper/Subject+API+security+by+realm

Chris has been working on an open-source project for U. Penn that involves using the Subject API in a non-Grouper application. There is a requirement to have admins see/search differently than normal authenticated users.  Chris is using the JDBC2 source, though this concept could be implemented in other sources too, based on requirements.  Admins are able to search anyone by name, and can see the full institutional name and affiliation of any user. For other authenticated users, a different view is used and data access can be limited.

Q: Is adding the realm parameter to the Subject API backward compatible?
A: Yes. It is backwards compatible, as long as the abstract class is used.

Q: Should we promote the importance of using the abstract class, especially if a deployment has their own custom implementation of the Subject API?
A: Yes, Chris will add that to the release steps.
[AI] (Chris) will put the Subject API / abstract class issue on the release steps wiki page

 Currently, this feature is implemented in the Subject API. To add this feature to Grouper, we would need a config param in the Grouper properties file to set up the realms and the groups for each realm.  Then every place the Subject API is called, it would be necessary to lookup this info.  

Q: Should this be incorporated into the new Grouper UI?
A: Yes, this would be part of the new Grouper UI.

[AI] Chris will consider Subject API Security by realm related to the new Grouper UI

Shilen commented that at Duke, preventing certain users from seeing privileged data in this way would be advantageous.

Grouper v2.2 Updates

Shilen is wrapping up (doing testing on) the 6 new privileges (2 for groups, 2 for stems and 2 for attribute-def).
Then will go back to work on Legacy Attribtue Migration work

Chris is making progress on the new UI. A question has arisen: On the mockup, there some tooltips that don't require clicking (just have a mouseover). For example, you can mouse over a group name to see a group name and description. But on a mobile device, you can't mouse over.  If you click once you go to another screen.  DaveL suggested that in such cases, on  a mobile device, you click once to get the tooltip and click twice to get to the other screen.  Chris will check out this approach.

Grouper UI Text Proposal

https://spaces.internet2.edu/display/Grouper/Grouper+UI+text+proposal

Chris developed a proof of concept for a new way to have externalized text in the Grouper UI, using config overlays instead of resource bundles.
Would make it easier to maintain. Easier to access expression language.
This would be more like the style of configuration used for other elements in Grouper.
The group agreed this is a good approach.

Next Call: Wednesday, Aug 14 at noon ET

  • No labels