Technical Requirements and Information

Supported Software

Organizations participating in InCommon must install and operate software systems that can interoperate with other participants. See the Software Guidelines for information on recommended software.

InCommon Deployment

The bulk of the work of configuring a Shibboleth IdP or SP is not specific to the federation(s) you are participating in, but there are various steps involved in making your deployment "InCommon-aware" once it's up and running. To get started, visit the Technical Guide on the InCommon Collaboration wiki.

Shibboleth software guides are also available:

Testing the Identity Provider

The best way to test the installation of your IdP is to also install the SP and run it yourself, using it to verify your system. If you want to run an IdP, you need to be able to control the SP and view the logs for troubleshooting purposes. Testing with Remote SPs is never a viable substitute.

You can even register such SPs in InCommon, if you like, and essentially use the exact same approaches as you will with outside SPs. Once installed, you can test your Identity Provider configuration by visiting the InCommon Test Service Web page, which runs the Shibboleth 2.x SP and supports SAML 1.1 and SAML 2.0. If you want to test with an external site, you can go to the Internet2 spaces wiki, find your IdP on the WAYF and log in.

Testing the Service Provider

There are at least two ways to test your Service Provider.

Participant Operating Practices

Federation participants must provide InCommon with a link to their practices as described in the Participant Operating Practices (POP). Download the template [doc] [html].

Your EntityID

Getting ready to start the federating process? The technical guide on the InCommon-Collaborate wiki provides important information about things to consider concerning your EntityID

Registering Your Systems in Federation: Metadata

It's fairly simple to activate a resource (SP) or identity management system (IdP) in the federation. All Participants' Administrators (as designated by your Executive) have access to the site admin management interface. InCommon's hours of operation are noted for your planning and convenenience.

Self-Signed Certificates: InCommon accepts self-signed certifications and, in fact, is transitioning the entire federation to self-signed certs in 2010 and 2011. For more information, see the wiki page on X.509 certificates.

Data for SPs: Entity ID, Assertion Consumer Service Endpoints: Type (post/artifact) and URL; KeyName; and Contacts (support, technical, administrative)

Data for IdPs: Error URL; URL and KeyName for Single Sign On Service; URL and KeyName for Attribute Service; and Contacts (support, technical, administrative)

For detailed information on InCommon metadata and the InCommon WAYF ("Where Are You From?") service, please see the Metadata page.

Identity Attributes

For information regarding the attributes InCommon recommends, please visit the Attributes page.

InCommon Operations Reference

InCommon is responsible for the operation of a number of technology platforms, including a Web server and the WAYF server, and a certificate authority (CA). Please note: InCommon accepts self-signed certs and, as of January 2010, does not accept certificates from the InCommon CA. InCommon also operates a redundant WAYF server. The WAYF does not preclude a Sponsored Partner from operating its own WAYF, which might, for example, list only those Higher Education Institutions with which it has an operating agreement.

Operation of the technical infrastructure is described generally in the FOPP (see policy page) and the following documents. These documents are made available for evaluation by participating organizations to establish trust in the secure operations of the InCommon Federation.

This page updated December 18, 2009