Scenario

An multi-institutional research group has formed. This group quickly comes to a realization: they need a service that will support their collaboration, providing tools such as file sharing, email lists, group calendaring, wikis, and a few specific domain science apps while still working with their usernames and passwords from their home institutions and allowing them to control access to the tools for the collaboration. This group wants to conduct their research, not build and support such a tool.

Introduction

A CMP is a service platform that offers integrated identity management to a variety of collaboration applications. In integrated identity management we include single (federated) login, consistent group management, roles, use of campus and collaborative attributes, and other common access control elements. By collaboration apps we include both general sharing tools (wikis, lists, netmeetings, group calendaring, file sharing, etc.) and domain tools (such as Grid software, instrument management, etc.) It could be argued that Microsoft, Google Apps, Adobe Connect, Cisco Webex and other products are CMP’s, but they are limited via proprietary protocols, range of apps supported, etc. We are interested in providing a service instance of an open-source, open standards, unlimited applications CMP.

Work on such platforms has been underway for a few years. In the US, where much of this was originated, the current focus, via our SDCI grant, has been the creation of a tool kit of CMP enablers (Shib components, Grouper, registries, etc.) that VO’s can plug into portals and gateways to build such capabilities into their own tools. In the Netherlands, the Dutch have worked with tool kit parts and assembled them into a more full-featured (e.g. end-user GUI, application rich) system, called Surfconnext. The Swiss, the Swedes, the Norwegians, and recently the Japanese have other efforts. We propose to use the Surfconnext as the user-facing component and COmanage as the strong person registry system designed for VO's as the platform for offering a powerful CMP to multi-institutional research groups.

Potential design

Target market

A CMP service has potential to be in demand by a wide variety of groups. Research groups from the humanities, from the hard sciences, government agencies, standards bodies, and more. The fundamental need for collaboration with strong, flexible and scalable access control reaches across all boundaries. The challenge to bring such a service in to being is not finding one market, but determining which of several to focus on. With the tools and concepts still developing, starting with a tight focus will be critical to the overall success of the service.

• Large research VO
• Federal agency or agencies
• I2 Member institutions
• I2 internal councils and working groups
  

Business Model

For each target market, a different business model might exist. In some instances external groups might be charged. In other cases, the costs might be handled internally as part of making the Internet2 organization more effective in its collaborations. That others, including Internet2 campuses, might offer similar services for their own communities will also affect the business model. Another factor is that collaborations are not used to paying an explicit fee for the service - they either have staff who do it, at real and opportunity costs, or they use some limited but free service, such as Google Docs. Depending on the requirements of the collaboration, the costs to be recovered might be modest. Lastly, the business model might reflect the considerable economies of scale that a service could enjoy. If development costs for a community can be avoided (by using common software, for example) and user support can be managed, there is little incremental cost to add users and communities.

Why should Internet2 do this?

• service to research community
• build better product
• foster I2 brand
• an above the net service

Why should Internet2 not do this?

• requires heavy integration across disparate areas across I2
• business model is unclear
• technology is still maturing
• potential competition with members
  

Costs

Staffing requirements

The level of staffing for such a service will vary with the number and complexity of VO supported. A few key roles will be required from the start:

• Support staff (help desk for the VO point of contact, not the entire VO user-base)
• Systems administration staff (support for servers, either virtual or physical)
• Development staff (domestication of new tools and integration of critical domain science apps)
• Engagement coordinator (interface w/ VO, solicit requirements, coordinate efforts)
  

Support and Development staff will need to scale up as additional VO are brought in to the CMP service. Some of the costs can be mitigated to the degree that the VO's can domesticate their own tools and install them in the environment. Support costs (for the collabmins within the Collaboration) are unknown at this point. End-user support is not much of an issue; they go their "portals" as before and are supported by the collaboration staff.

Environmental requirements

• Platform Development, QA, Production environments
• Development sandbox for integration testing
• Storage
• High-bandwidth (particularly for web-based meeting tools)
  

Deployment options:

The question of whether to do this work through the TSG of Internet2 or to focus more on cloud support depends on several factors:

• Does TSG have the necessary resources to accomplish this work? Is staffing-up an option if it proves necessary?
• Is a CMP service the right opportunity to explore the possibilities of cloud services?
• Is a CMP service the right opportunity to explore closer partnerships with key campuses that may run this service for Internet2?
  

What a VO might worry about:

• How do they extract their data (papers, reporting logs, etc) when their VO is done?
• Will this be suitable for PI or other LOA 2+ info?
• Can they submit their own domain-specific tools to be accessed via this service?
• What is the SLA?