COmanage-Dev Call 5-Sep-08
*Attending*
Heather Flanagan, Stanford
Digant Kasundra, Stanford
Scotty Logan, Stanford
Bruce Vincent, Stanford
RL "Bob" Morgan, U. Washington
Greg Wood, Internet
Steven Carmody, Brown
Jim Leous, Penn State
Renee Frost, Internet2
Ken Klingenstein, Internet2
Ann West, Internet2
Mike LaHaye, Internet2
IJ Kim, Internet2
Dave Donnelly, Stanford
Tom Barton, U. Chicago
Michael Gettes, MIT
Steve Olshansky, Internet2 (scribe)
*New Action Items*
[AI] (All) review the task list in the wiki and contribute as you are
inclined to.
[AI] (Stanford) will integrate the Shib 1.3 IdP into the VM image.
*Carry Over Action Items*
[AI] (Digant) will create COmanage video #2 by Sept. 19.
[AI] (Scotty} will redo COmanage video #1 to correct a few audio issues.
[AI] (Scotty)will send Renee info for the abstract on the COmanage BOF at the Internet2 Fall Member Meeting.
[AI] (Ken)will work on engaging Ed Seidel with COmanage at the
Internet2 Fall Member Meeting.
*Discussion*
- COmanage Logo
Greg led the group through the revised logo presentation, the link to
which was sent to list prior to the call.
The revisions were based on the assumption that the logo would be used
as an "ingredient flag," and incorporated feedback from the last call.
Consensus on the call was that logo idea #1 is the best, but that it
would be useful to explore the option of moving the word "manage" under
the disc and making it less prominent.
- Closing the discussion on the Shib SP environment
The Shib 2 SP is now incorporated into the VM image, with a bit of
configuration required to get rolling. The IdP is not yet planned for
inclusion, at least in early versions.
When COmanage is first installed, it is setup by default for localhost
use. Is there an option to utilize this approach for the Shib SP,
preloaded with the required dummy metadata? Another option would be to
configure implicit trust in an IdP at initial installation, e.g.
ProtectNetwork or TestShib. The intent is to enable installers to get
going as quickly as possible, with as little additional configuration
required, in order to explore and understand COmanage.
Another idea floated was to stand up an IdP dedicated to COmanage for
this purpose, but this could obviously not be used in the absence of a
network connection (e.g. on a plane).
In essence, the goal is to provide a "quick start" basic functional
system that can be moved into production use with additional
configuration. A configuration agent would be a useful enhancement
toward this end. It was observed that making the installation too simple
might be counter-productive, in that it bypasses the learning and skills
required to actually install and configure it to work in a production
environment.
The idea of including a Shib 1.3 IdP for expedience, and consensus was
that this would be fine since it would be transparent to the person
installing and exploring it. Shib 2 IdP would require integration work,
while the 1.3 IdP would be simple to include.
The online demo version will be available for people to explore, as an
alternative.
Puppet was discussed early on as an aid to building the VM image, but it
has not yet been included. There was discussion about using Puppet also
as a configuration aid after installation, but it seems not to be
optimal in our environment.
Q: Is there a configuration markup language/DTD that would be useful for
COmanage, to avoid making it so Debian-specific?
A: Not really in the short term, but perhaps further out...
[AI] (Stanford) will integrate the Shib 1.3 IdP into the VM image.
- Review of task list on wiki
https://spaces.at.internet2.edu/display/COmanage/Task+List
[AI] (All) review the task list in the wiki and contribute as you are
inclined to.
This is the list of Stanford tasks, and thus does not include others.
The GUI is not yet included, and will be added. The Fluid call is set
for 19-Sep-2008.
The "dashboards" in the task list are the primary management consoles,
mostly intended for Collabmin use.
Would invitation and people-picker (for people not in the local store)
functionality be useful additions?
Stanford suggested using COmanage-spawned e-mails for the invitation
function. The recipient would then need to authenticate locally (in
his/her home security domain) before being added to the VO. What about
inviting an existing external group, not just an individual user? What
about external namespace reconciliation issues? Dynamic groups are another
There are groups in Europe working on the invitation problem, and it was
suggested that we coordinate with them to avoid reinventing a solution.