InCommon and Internet2 invite the community to respond to our request for proposal outlined below.
Introduction
The InCommon Assurance Program has been exploring implementation challenges associated with expressing Assurance over-the-wire and identified several issues with the Shibboleth Identity Provider version 2.3.8. In addition, Internet2 received an NSTIC grant to develop an approach to scalable privacy, a component of which is supporting Multi-factor authentication across Higher Education. A key deliverable of this award is a Shibboleth Identity Provider login handler to better support multiple authentication mechanisms and interactions between (and among) them.
This document is a Request for Proposal for the development of a Shibboleth Identity Provider plugin to address the technical requirements outlined in Assurance Enhancements for the Shibboleth Identity Provider. A copy of these Enhancements has also been forwarded to the Shibboleth Consortium for inclusion in their feature discussions.
The documentation associated with this Request for Proposal consists of this document and related software requirements linked above and below.
RFP Response Schedule
Responses should be submitted electronically to admin@incommon.org by 11:59 pm US Pacific Time (UTC/GMT -7 hours) on May 31, 2013. To receive updates about this RFP process, subscribe to the ShibRFPInfo list by sending email to sympa AT incommon.org with subscribe ShibRFPInfo@incommon.org in the subject.
May 1, 2013 - Release and distribution of RFP
May 7, 2013 - Bidder conference at 4:00 pm US EDT (UTC/GMT -4 hours)
Dial-in numbers: |
+1-734-615-7474 (Please use if you do not pay for Long Distance) |
Access code: |
0121864 |
Webinar URL: |
May 31, 2013, 11:59 pm US Pacific Time (UTC/GMT -7 hours) - Deadline for submitting proposals
June 17-21, 2013 - Finalists interviewed, if necessary
June 28, 2013 - Vendor selected
Questions can be sent to admin@incommon.org until May 17. They will be answered in a FAQ linked to this wiki.
Project Requirements
The technical requirements outlined in Assurance Enhancements for the Shibboleth Identity Provider must be met.
Internet2 requires an open development process using the Shibboleth Development list to ensure alignment of finished product. Weekly communications with InCommon staff and/or designated community collaborators during the project.
Required documentation includes: Design and Architecture document, Java document, wiki page outlining configuration and logging options.
The delivered software must contain the following copyright notice: "Copyright (c) 2013 Internet2", and be licensed under the Apache License, Version 2.0 for later contribution to the Shibboleth Consortium.
Project Phasing
Below are 5 key phases to this development Project with suggested time frames:
- Delivery of design and architecture
- Discussion: Detailed design and architecture review
- Delivery of code by end of August 30, 2013
- Discussion: Detailed code review outlining how the final code differs from the Design presented earlier.
- Community testing and bug fixing
- Acceptance of code by December 1, 2013.## If the Acceptance Criteria have not been met by this date, Internet2 may extend this date at its sole discretion.
- Optional post-project support
Submissions
Proposals should include the information outlined in this section; our ability to interpret and apply your proposal to these questions will factor into our decisions.
- Describe in detail the organization's proposal to address the requirements outlined in this RFP, including details such as technologies to be used and project phasing. Include your approach to unit testing.
- Provide a timeline for the completion of this proposal, including start and finish dates and project phases.
- Describe the fee structure of how Internet2 will be charged, including any optional components included in the proposal.
- Provide a brief history and profile of the organization. Provide a list of the organization's clients; include contact name, telephone number, website location, services provided and length of service.
- Detail your experience supporting Higher Education and Open Source Communities.
- Provide evidence of the organization's experience and work with Shibboleth software.
- Describe the project process and methodology including sample deliverables from past projects of similar size and scope. Document examples of the organization's experience in designing/developing each of the project requirements.
- List the project team and short biographies of each team member. If using freelancers or outside resources please indicate them as such; we reserve the right to approve/disapprove of selected resources. Indicate how many full time staff are employed by your organization.
- Provide a communication plan between your organization and Internet2 during the project.
- Provide a communication plan between your organization and the Shibboleth development team.
- Please provide an unsigned copy of your standard service contract for our review and any additional stipulations of which we should be aware.
- As an optional component, include a proposal of how the software could be supported after it is delivered to Internet2.
Response Review
As Internet2 is a community-driven organization, the Review Team will include Internet2 staff and members of the higher-education community. Access to the proposals will be limited to the Internet2 Staff and the Review Team. Internet2 will work with the winning bidder on a shared community announcement and informational website.
Assessment Criteria
A RFP assessment team will review the responses using the following criteria:
- Degree of experience working with and knowledge of the Shibboleth software.
- Degree of experience working with the Higher Education and Open Source Communities and InCommon.
- Level of cost effectiveness of the proposal and timely delivery of software.
- Ability to deliver the software as described in the RFP and in the organization's proposal.
- Qualifications of the staff identified to work on the project.
- Level of communications proposed between InCommon and the organization.
- Alignment of the contract with Internet2 legal parameters.
- Flexibility and cost-effectiveness of the optional support proposal.
Acceptance Criteria
The delivered code will be accepted when the following conditions have been met.
- The requirements in this document have been met, including the referenced technical requirements document, as verified by three test campuses.
- All bugs that impact required functionality have been corrected.