Child pages
  • Grouper Call 27-Aug-2014
Skip to end of metadata
Go to start of metadata

Draft Minutes: Grouper call of Aug. 27, 2014


Chris Hyzer, University of Pennsylvania (Stand-in Chair)
Dave Langenberg, University of Chicago
Shilen Patel, Duke
Jim Fox, University of Washington
Gail Dunmire, The Pennsylvania State University
Bill Thompson, Lafayette College
Emily Eisbruch, Internet2, scribe

New Action Items

[AI] (Shilen) create a JIRA to add a subject identifier to the members table so it will be available for the messaging system and for the loader

[AI] (Dave) update the PSP planning page on the wiki with the results of today's discussion.

Carry Over Action Items

[AI] (Gail) develop bullets about lessons learned from Grouper 2.2 installation

[AI] (Tom) follow up on Pen testing of Grouper 2.2

[AI] (Chris) look into the error message on the demo access issue if no EPPN is sent.
[AI] (Shilen) create a Grouper training video on the new Grouper UI

[AI) (DaveL) look at PSP ChangeLogDataConnector Inconsistency issue

[AI] (Shilen) investigate ways to get new attribtues in a single step


Grouper IAM Online
Wed. Sept 10, 2014 at 2pm ET
Title: The New Grouper: Its New User Interface and More

Draft outline:

Performance Issue on main page of new UI

Chris: Did anyone install Grouper 2.2 on a large database and experience performance issues on the main page of the UI?

Shilen: this appeared during some occasions during testing
It was not consistent, so was not sure if that had to do with the database
Need to look at this issue.
Note: Shilen followed up with an email to Grouper-core on Aug. 29 titled "Performance on main UI screen"

Status of Current Work

Chris has been addressing emails on the list and working on adding new features to the new Grouper UI for the next release, including adding ability for the UI to handle attribute definitions and names

A few issues around attribute definitions and names will be addressed for Grouper 2.3.


Planning for Grouper 2.2.1 Release

Gail: When we might Grouper 2.3 be released?
When will the changes be available?

Decision: In the next month or so it makes sense to release Grouper 2.2.1 so changes/fixes can be made available.

Major changes won't be available until the release of Grouper 2.3

Goal: Finish development of Grouper 2.2.1 for the next Grouper-dev call if possible. Then test and release by end of Sept if possible.


Tom suggested in an Aug. 26, 2014 email these main principles we should to try to adhere to

  • Facilitate community contrib to provisioning connectors, since it is an unbounded functional area.
  • Remain focused on management of access info and replicating it where it needs to go with reasonable performance.
  • Continue to be integrable with most anything.
  • Keep it as simple as possible: aim to be easy to deploy, easy to use, reliable.


Message queuing to provisioners is being advocated by some. Some strongly advocate for Grouper to provision to ActiveMQ.
One advantage of AMQ is that it is free.
But maybe we can provide something gerneic and it will also work with AWS. We would write in Java, others might need to change that for their own purposes.

Chris:: Currently, Grouper has the change log and a change log temp.
And a process that moves things from the change log temp to the real change log. This is to correlate for things for multiple processing writing at once.

Under the suggested approach we would send to one message queue. We would not have the change log temp step.

Hooks could potentially send messages too.

U. Washington sends representations and uses AWS as outlined here:

Suggestion to store subject identifiers in the members table.

[AI] (Shilen) create a JIRA to add a subject identifier to the members table so it will be available for the messaging system and for the loader

Idea is to put the NetID in the change log message.

Do we need multiple NETID s or just one?
Agreed that one is fine for our use cases

Approach for message format and handling

May want to pattern the message format after U. Washington's. They use signing and encryption and AWS approach. Or could write our own from scratch.

Jim: As the downstream systems get more distant from Grouper and more generic, not everyone will be using Java.
People will want to consume in other languages. This is where contributions will play in.

If the main targets are AMQ and AWQ and the database, then we should suggest people provide contributions if they write for something else (see "Managing Contributions below")

Possible steps:
-Make a JSON representation for the messages that would go for different events based on the change log
-come up with encryption strategy
-Identify interfaces for reading and writing a message
-Find out if it's possible to write an implementation that's like the change log if a site does NOT want a messaging system.

Should it be possible to process the messages in random order?
Can that lead to a big performance gain?

Managing contributions around Grouper Provisioning

Suggestion: Deployers can send us a request if they have a contribution.
We determine if it should be part of Grouper or should be in the contrib. section of the wiki.

Example: a Google connector for the messaging system.
These things would live in Grouper misc.

Bill: for the CAS Project
-there were many extension modules, particularly for authentication handlers
-if a community member wanted to contribute they could become the module owner of that authentication handler.
--they would join the project for that module.

-Also Unicon did CAS add-ons in GitHub

-the add-ons are de-coupled from the CAS project
-and maintained by the owners (the Unicon team)

-need to avoid people writing extraneous provisioners and expecting the Grouper team to maintain them. It is an unbounded space

-We should have a framework for contributions, so things like high-availability are similar across all of them.
-Perhaps we provide a guide.
-The grouper web service status page provides info and alerts if something is not working.
-We may need to think about connecting to that for new modules.

[AI] (Dave) update the PSP planning page on the wiki with the results of today's discussion.


How should we package the messaging system(s) w Grouper?
Suggestion: We don't provide the external messaging system with Grouper. Run risk of supporting products that we ship.

We could have prompts in the installer, even if we don't ship the product.
Installer could ask:
"Do you want to use Grouper's Internal Database (change log consumer), or AWS or AMQ?"
It would be assumed that a site had installed AWS or AMQ if they select that option.

Grouper Guidance and Experience

-At Lafayette, there is a large need for adding people to a group and adding authorization. There are many use cases. Anxious to to going with a Grouper deployment.
-Lafayette is doing a Grouper evaluation deployment
-Want to stand on the shoulders of those who have gone before. concerning supporting infrastructure, default configuration, and everything it takes to run a successful Grouper deployment.
-Would welcome pointers and thoughts.

-Even in areas that each site must do according to their local environment (monitoring?) Lafayette would like help from people who have production experience
-Interested in generalized strategies.
-If these generalized strategy resources don't exist, Lafayette is interested in helping develop them.

Next Grouper Call: Wed. Sept. 10, 2014 at noon ET

  • No labels