InQueueShutDown

Steven Carmody (17 Oct 2006):

The Shibboleth and InQueue support teams announce the closing of the InQueue test federation. InQueue has served the Shibboleth community for several years as a testbed and learning facility, but as the community has grown InQueue has become increasingly impractical to operate, and has been superseded by other services.

InQueue operation will be shut down in phases. Here is the schedule:

• October 30, 2006: No new registrations will be taken after this date.
• December 22, 2006: No modifications to existing registrations will be done after this date.
• June 1, 2007: Publishing of InQueue metadata and operation of the InQueue WAYF will cease.

For those wanting to test their Shibboleth installations, the TestShib facility (http://testshib.org) is available.

Most SAML/Shibboleth-based federations are able to assist prospective members with installation and testing to interoperate with those federations. A partial list of federations can be found on the Community page of the Shibboleth web site.

For more information about InQueue, its history, and its issues, see below.

History

The Shibboleth team created the InQueue Federation during the early days of the Shibboleth project, long before there were any production Federations. The goal was to provide a way for sites to explore and learn about the Shibboleth software in an easy and straightforward fashion, at no cost. Using InQueue allowed sites to build local confidence in the technical and policy aspects of federation. InQueue has provided organizations with the ability to verify that their deployments (SP, IdP, or both) interoperate with other sites without having to worry about strong security (since InQueue is just for testing purposes).

Since InQueue was created, we have seen the appearance of a number of production-level Federations around the world; they are ready to provide a real and robust trust fabric and services that can serve as the basis for real and reliable trust between sites. InQueue was originally envisioned as a temporary stop as sites evaluated and tested the Shibboleth software. The expectation was that sites would leave InQueue within 90 days, and either move to a production Federation or stop their testing.

In current practice, InQueue is creating confusion along with its value as a test facility. Sites find that InQueue is easy to use, and that it "looks" like a real Federation. And, until recently, joining InQueue was the easiest way to test a new Shibboleth install. Unfortunately, InQueue provides metadata that "trusts" CAs that should not be trusted in production environments. Trusting these CAs during test and evaluation phases simplifies the test process, and allows sites to avoid needless expenditures for certificates during a pilot project. However, it is ridiculously easy to impersonate an IdP or SP in InQueue. This shouldn't be a problem for testing. However, it appears that a number of sites are running production services within the InQueue Federation. Frankly, this is not within the intended scope and could lead to unintended exposure of resources or user attributes.

Consequently, we will be closing down the InQueue test Federation, and we will stop accepting new members. Current members can continue to use the existing metadata. However, in the strongest language possible, we would encourage existing InQueue sites to use InQueue ONLY for testing, and to move to a production level Federation when they want to use Shibboleth in production. By June 1 2007, we will stop publishing the InQueue metadata.

The Shibboleth team does recognize the need to provide sites and individuals with an easy way to explore the Shibboleth software. Consequently, the Shibboleth team will be providing "TestShib" (https://www.testshib.org/), a new ZERO trust testing and demonstration facility suitable for testing and evaluating the Shibboleth software. Individuals will be able to use a self-service application to create and manage metadata entries within TestShib.

In addition, as part of this InQueue transition, the US InCommon Federation will begin to offer identity mechanisms that will allow its federation participants to test new software installations without disrupting their existing InCommon-based services.