Proposals are due on May 31, 2013, 11:59 pm US Pacific Time (UTC/GMT -7 hours). Send them to admin@incommon.org.
InCommon/Internet2 have assembled a staff/community working group to assess the proposals. There will be representation from both the NSTIC Privacy/MFA grant and InCommon teams.
Subscribe to ShibRFPInfo@incommon.org list by sending email to sympa AT incommon.org with subscribe ShibRFPInfo@incommon.org in the subject.
For use case 1, the assumption for the first configured option is that the user won't be confused by the static list, as they may be presented with options they can't use. This use case is best implemented in a simple authn environment where the authn choices are few.
For use case 2, if Sam was already authenticated as Silver and the SP requests Silver, the transaction is transparent to Sam (no additional login required) and IdP sends back Silver IAQ.
For use case 3, the user has an option to set up, but not step down in authn levels.
Follow current Shib conventions. Suggest you don't plug into the existing login handler because it will change a lot in V3. Spring?
Yes.
Who: David Walker and Ann West. Approach: Either one works for us.
All of the information required for the Multi-Valued Session Object is already maintained by Shibboleth. Don't modify the existing structures, but you may have to compute some data on the fly.
Use the existing APIs to communicate the error back to user. Not all is known about the error conditions and UI. Up to the bidder to think through this and iterate on it during the development process as issues come up.
We expect them to break with the new plugin. Defining new login handler interface is part of RFP.
This is negotiable. We will be identifying 3 capable campuses to test the plugin, but at minimum we'd need an introduction call or webinar to orient the campuses on what they should be testing. InCommon would expect the bid winner to participate. Support should be minimal other than addressing functional or technical issues that deviate from the RFP.
Campuses needing support for Shibboleth v2 will need support for this plugin too.
Yes, especially if the code is clean and hits the right target. We are interested in getting this software finished and available to the community pretty quickly though.
The tests will be executed by three test campuses.
We do expect ongoing communication with the Shibboleth developer community during the project. However, the Shib Project has no right of refusal over the features and implementation. There will be presentations during identity week, so the bidder should be on notice that they may be asked to attend.
Shibboleth 2.4 must be supported. Support for earlier versions is desired but not required. Proposals must indicate which versions of Shibboleth will be supported
Note: The following diagrams were supplied by a potential bidder, not InCommon or Internet2. They should not be used as authoritative or as a true reflection of the requirements in the RFP.
General Flow of Assurance Enhancements for Shibboleth IdP
- The authn context that the IdP returns is the one that the SP requests.
Shibboleth 2.x Idp Internal Authentication with Multi-Context Broker for Assurance
- May need rethinking given the existing login handlers will likely break.