COmanage Developers List

["GW Brown, Information Systems and Computing" <>]

Just to confirm what I said on the call, Grouper's Subject API 
implementation (SourceAdapter) can currently 'find' any group whether or 
not you have view privilege for it. I don't think it would be too difficult 
to change that and will raise it on the Grouper call.

Stems - or namespaces - are visible to all, but restrict who can create 
groups or sub stems, however, the UI can be used to restrict access to 
stems.

I have some questions:

1) How are users registered and how would they be assigned to a CO instance?
2) Would you also expect users registered in one CO instance not to be 
visible in another instance where they are not registered? May require 
filtering of search results...
3) Does CO maintain metadata about which apps are available in which CO 
instance and does it create default groups - effectively mapping to roles - 
for different apps?
4) Any idea how many groups a typical CO would use -10, 50, 100, 500, 1000 
or more?

I'm assuming that if you had a shared Grouper instance each CO would have a 
top level stem. Below that you could have a flat list of groups or you 
could have further stems for different apps. I'm interested in whether CO 
will 'impose' structure / naming conventions or if it is up to the CO 
administrator. Also what would be the balance between metadata in CO vs 
Grouper. Potentially the more metadata CO manages directly the simpler the 
groups UI can be.

Gary

--On 03 August 2009 13:24 -0400 

 wrote:

> These are based on the notes I took; please correct where I've made
> mistakes.
>
> The goal is to deploy a CO service as a "Limited Use Pilot".
>
> Definition -- "Limited Use Pilot". The pilot will run on I2's supported
> VM infrastructure; the contents of the VMs will be backed up. Initially,
> the service will only be offered to short term projects with explicit
> termination dates (eg planning an upcoming meeting); the service will NOT
> be offered to groups with an ongoing mission (eg AMSAC).
>
> Over some period of time, multiple groups will use the CO service (often
> in parallel). The service MUST support the ability to run multiple COs in
> parallel. The CO infrastructure MUST ensure that members of one CO are
> not able to alter content in a different CO instance. The service MAY
> support some method for capturing the data held within the applications
> when a group shuts down its use of the CO service.
>
> (We would prefer that the CO instances be strictly isolated from one
> another -- that a member of one CO CANNOT see any content or information
> about a different CO (including members or group info). In phase one,
> we're willing to accept seeing, but are requiring there be no WRITE
> access across CO boundaries.)
>
> During the "Limited Use Pilot" phase, there will be regular (bi-monthly?)
> reviews of operational issues. The CO developers and the I2 operations
> team will attend these reviews.
>
> Functionality:
>
> -- what is the process for vetting requests for new CO instances ?
>
> -- the CO super admin can create a CO environment for a new group, and
> delegate the mgmt of the new instance to the CO leader of the new CO
> instance
>
> -- the CO leaders have access to a collabmin intereface. They can
> configure the Shibboeth SP, Grouper, and ldappc for use supporting the
> CO. In addition, they can enable applications for use by CO members,
> create and manage groups, make others members of the CO. In addition, the
> CO leader can use the GUI offered by each application to manage
> permissions within that app (eg grant group x permissions to do Y)
>
> (deferred to a future phase -- the CO leader can invite others to be
> members of the CO)
>
> -- CO members can access a dashboard of some sort providing an overview
> of activity within the CO and the available applications and resources,
> directly access an application supporting the work of the CO
>
> (deferred to a  future phase -- accept invitations)
>
> AIs coming form the call:
>
> -- Danno -- reconfigure existing Co VM (this was done during the call)
>
> -- Jim, Digant, Steve -- develop storyboards describing flows for CO
> leader and members
>
> -- Michael -- begin installing + configuring glue software within the VM



----------------------
GW Brown, Information Systems and Computing