Shibboleth Consortium

Background Shibboleth evolved out of Internet2 Middleware Activity in 2000, with first release in Significant funding from Internet2 (USA) and latterly JISC (UK) resulted in wide adoption by research and education communities enterprises around the world. Used by 26 national federations: UKAMF (UK), InCommon (US), SWITCHaai (Switzerland), AAF (Australia), (Croatia), ACOnet (Austria), Belnet (Belgium), CAF (Canada), CAFe (Brazil), CARSI (China), CESNET (Czech Republic), COFRe (Chile), DFN-AAI (Germany), Edugate (Ireland), eduID.hu (Hungary), GakuNin (Japan), GRNET (Greece), Haka (Finland), IDEM (Italy), LAIFE (Latvia), Tuakiri (New Zealand), RCTSaai (Portugal), RENATER (France), SIArnesAAI (Slovenia), SWAMID (Sweden), TAAT (Estonia) and ULAKAAI (Turkey).

Consortium Updates The Principal Member fee has been aligned to the Large NREN/Federation fee of €40,000 Members contributing this amount are entitled to a seat on the Board A mechanism for receiving donations has been incorporated Lalla Mantovani, of GARR, was elected to the Board as a Members’ representative A further Members’ representative election is underway – nominations welcome!

Consortium Board Principal Members’ Representatives:  Internet2 (US): Shel Waggener and Steve Zoppi  Jisc (UK): Josh Howlett and Jeremy Sharp  (SWITCH) Members’ Representative:  Lalla Mantovani, GARR (Italy) Developers’ Representative  Scott Cantor

Consortium Membership Principal Members Internet2 (US) & Jisc (UK) Federation Members SWITCH (Switzerland), ACOnet (Austria), NII/GakuNin (Japan), CSC/Haka (Finland), RENATER (France), NORDUnet (Nordic region), Belnet (Belgium), CANARIE (Canada), DFN (Germany), The European Space Agency, GARR (Italy), CESNET (Czech Republic) & RNP (Brazil) Academic / Non-Profit Members Carnegie Mellon University (US) & LIGO Scientific Collaboration (US) Commercial Members Overt Software Solutions, Clareity Security, Gluu & 9STAR

Membership Fees CategorySmallMediumPrincipal NREN/Federation Member€ 10,000€ 20,000€ 40,000 CategorySmallMediumLarge Academic/Non-Profit Member€ 2,000€ 4,000€ 6,000 Commercial Member€ 4,000€ 8,000€ 16,000

IdP V2 Support Timeline Project team proposed ending support on Dec 31, Member feedback largely consistent in proposing Dec 31, 2016 with one or two outliers. Compromise approved by Board is for a phased timeline: All security bugs and severe non-security bugs addressed until Dec 31, 2015 Moderate security bugs addressed until Feb 29, 2016 Important security bugs addressed until May 31, 2016 Critical security bugs addressed until July 31, 2016 (full EOL)

IdPv3 Maintenance Update Development currently underway on 3.2, expected late summer, early fall, may need to provide a in July to get IDP-703 fix out Major features under development: Documentation additions ongoing(not a feature, but needed) New or enhanced login options (e.g. IDP-114, hopefully IDP-111) Incorporation of SAML delegation extensions built for V2 HTML Local Storage support for session / consent storage Additional logout features (scope preliminary at this stage)

SP Maintenance Update After problem with last service patch for Windows, prospect of future patches using that approach is not good update is forthcoming systemd integration Library fixes Flip “same-version-update” bit in Windows installer Future Windows patches will rely on the fourth MSI version digit, used successfully with IdPv3 Windows installer

Project Roadmap Two major developments within the last month impacting our planning: Major funding reduction expected to hit in An independent source of funding is embarking on a project to at least start implementing OpenID Connect in the IdP In light of that, project team is unlikely to be proposing major new projects that would incur substantial technical/maintenance debt.

Project Roadmap cont. Possible smaller projects: CDS rewrite (*) XmlSecTool rewrite SP 2.6 Feature Update, IIS7 module, etc. Documentation New attribute filter policy language Ongoing feature work on IdP CDS – Needs rewrite or will be discontinued as a product Resources sufficient to complete, but continues to add to our maintenance burden Given outcome will be a changed configuration, are current users better served by a move to the EDS?

Questions?