Shib in the present and the future Ken Klingenstein Director, Internet2 Middleware and Security
Topics Core software development Coupled systems The GUI’s down the road Other AA backend dataplugins Alternative WAYF Shib-enriched apps Diagnostics Managing the processes The federation consequences
Shibboleth Today V1.2 on the streets, v1.3 in development Software still is “simple” but getting increasingly complex. Software is still early. Identified as the national R&E federation technology in the US, the UK, Australia, Switzerland, Finland, and perhaps others… Increasingly “at” Burton, Catalyst, DigitalID Conferences Interoperability discussions and commitments being made among federating software developers
Core software development V1.0 April 2003, v 1.2 May 2004 V1.3 targeted for fall; priorities include portal support, perhaps artifact SAML profile SAML 2.0, OpenSAML 2.0 and the meaning of Shibboleth WS-Fed interoperability Shib as WebISO SOAP and SAML –interim and long-term Shib-lite Refactoring into core and module for long-term management Integrated documentation and install guides
SAML 2.0 Historic relationship of SAML and Shib Contributions from both Liberty and Shibboleth to spec. TC under OASIS, with contributing editor S. Cantor, Individual Largely done, perhaps final committee work by end of August, then approval by Nov or IBM… Refactors a lot, in Shib and vendor products – how quickly will vendors adopt? OpenSAML 2.0 will happen…
Coupled systems The major GUI’s – SysAdmin, Autograph, PRM Other AA backend plug-ins Alternative WAYF approaches Interim Long-term Diagnostics Other trust fabrics
GUI’s to manage Shibboleth
SysPriv ARP GUI A tool to help administrators (librarians, central IT sysadmins, etc) set attribute release policies enterprise- wide For access to licensed content For linking to outsourced service providers Has implications for end-user attribute release manager (Autograph) GUI design now actively underway, lead by Stanford Plumbing to follow shortly
End-user attribute release manager (Autograph) Intended to allow end-users to manage release policies themselves and, perhaps, understand the consequences of their decisions Needs to be designed for everyone even though only 3% will use it beyond the defaults. To scale, must ultimately include extrapolation on settings, exportable formats, etc.
Privacy Management Systems
Personal Resource Manager
Shib-enriched apps uPortal OKI and Sakai Lionshare Fedora Globus Netauth Virtual organization systems
Diagnostics Fine grain transparent access controls are going to be difficult to diagnose. Right now, at least four different failure points result in the same Shib error message The target host is down Network performance caused time out of the Shib protocols Firewall blocked the ARP communications Shib itself is misconfigured And that error message sucks… (Shire not found) Worst, fine grain access controls will be harder for coarse users…
Diagnostics: next steps We have a possible large scale framework for the presentation of diagnostics We have a possible common event record for systems to create logs in and possible ways of end-end access of logs We have nothing in between Harvesters, threaders, automated diagnostic aids, etc… Worse, we have nothing with the network performance and security problems that can masquerade as Shib problems. Something needs to change, sigh…
Project management Moving to a more distributed development environment Setting priorities and coordinating international initiatives Technical architecture and code Coordinating investments IPR Commercial implementations Consulting opportunities, outsourcing, etc. Affiliating with other similar open source projects: Apache, Mozilla, etc.
Federation drivers As we begin to deploy federations, what operational experiences will drive modifications or enhancements of the code Authentication context field Multifederation support Diagnostic support Privacy enhancements, such as use of information fields, etc…
Down the road Boredom Dusty remembrances