Working with Sponsored Partners
Higher education institutions have a range of reasons for joining the InCommon Federation. Sometimes one application or service drives the decision, but the college or university doesn't federate with another sponsored partner.
Here are some resources to help - whether you are looking to join InCommon, are new to InCommon, or are looking to extend your federated identity program with other sponsored partners.
Value Proposition on the Web - You can point your vendors to this page, which explains the value of InCommon from their point of view.
Webinar and Presentations
"Working with Sponsored Partners"
(IAM Online Archive [Adobe Connect]) - Hear from John Harwood (Penn State) and Paul Caskey (University of Texas System) about how they approach potential sponsored partners.
Contract and RFP Language
Some higher education institutions work federated identity language into their contracts and requests for proposals (RFPs). Here are some samples and examples:
University of California RFP language (note that the "UCTrust" referred to is the University of California federation built on InCommon) - UC avoids incorporating technical specifications in this language by referring potential vendors to existing specifications at UCTrust and at InCommon.
University of Texas system language - Texas includes specific mention of SAML and the ability to pass assertions.
Describe the technical aspects of LMS and Hosted Services proposed to be provided in connection with the LMS.
2.1 USER ACCESS. Include a statement of ability to comply with SAML 2.x, a standards-based single-sign on authentication method, in which the software/site in question allows System to authenticate a user and accepts System's assertion of authorization via SAML. At login, System will be the identity provider and will determine whether the user has authenticated properly using their local credentials. If the user authenticates correctly, System will redirect the user's browser and pass a SAML assertion to the system/site in question, which the system/site will consume in order to grant access.
SAML 2.x is strongly preferred, but if system/site is unable to comply with SAML 2.x, include a statement of ability to support authentication via a proxy.
2.1.1 USE OF IDENTIFIER. Include a statement of understanding that the system/site shall not require its own internal username and password for users, nor shall it rely solely on a user's inclusion in System's Active Directory, but shall use the appropriate unique identifer as identified by System.
Specific Section for SAML Support - Texas also includes a specific section for SAML support:
SAML Support: Contractor will ensure that the LMS supports SAML 2.x or later authentication and attribute assertions in lieu of direct authentication by the LMS's web application by System Administration employees. The LMS's web application shall use System Administration's institution discovery service to allow users to select their home institution. Contractor shall abide by System Administration's security policies regarding data security and requirements of the UT System Federation. It is recommended that Contractor provide and implement Shibboleth software in the LMS in order to meet this requirement.
Leveraging the Crowd
Colleges and universities have found that approaching a potential service provider as a group increases their leverage.
Committee on Institutional Cooperation (CIC - consisting of the Big Ten schools plus the University of Chicago) - The CIC has an identity management task force; one of the group's charges is to employ a federated model for the sharing of applications and resources. The CIC seeks to federate with external resources, as well as providing federated access to its own resources.
The InCommon Library Collaboration Group, in addition to developing and promoting a Shibboleth/EZproxy hybrid for federating library resources, used a group approach to several vendors, with the result that several joined InCommon and started providing federated access.