1. Shibboleth Working Group, Fall 2010 Scott Cantor, OSU Chad LaJoie, Itumi, LLC

2. Roadmap

3. Committed Work Necessary/expected ongoing functions Funded/staffed projects Planned Work Accepted for prioritization but uncommitted Under Discussion Rejected/Parked Work Lacking in some regard Subject to re-evaluation when circumstances change 3

4. Committed Project Overhead User Support Supported Release Maintenance SP 2.4 “Embedded” Discovery Service Metadata Aggregator 4

5. Planned Expanded introductory documentation V3 IdP / OpenSAML-J V2 Discovery Service V3 TestShib Back-channel Single Logout for the IdP Second Factor Authentication via SMS SP Delegation Enhancement (deferred from 2.4) 5

6. Service Provider

7. Service Provider V2.4 Release Candidate now available Minor feature update / bug fix rollup Backward compatible per usual Simplified configuration/defaults Metadata- and discovery-related enhancements Security changes Logging/monitoring changes 7

8. Configuration https://spaces.internet2.edu/x/fIk9 “Radical” defaulting of rarely-changed settings Reduction of order strictness Factored security policy rules into separate file Consistent message regarding Apache configuration via Apache commands Shorthand syntax for configuring “most” SSO/Logout needs 260+ lines to 120 lines 8

9. Metadata Background reloading of configuration / metadata resources Caching (incl. across restarts) and compression Delays backup overwrite until filtering completes Rational cacheDuration handling Support for extension drafts: http://wiki.oasis-open.org/security/SAML2MetadataUI http://wiki.oasis-open.org/security/SAML2MetadataAlgSupport 9

10. Discovery Supporting role; provide a “usable” view of IdP information extracted from metadata to discovery component Supplies JSON data from each metadata source Name/description/logo derived from metadata extension New handler aggregates and serves JSON to client Discovery scripts may or may not be in 2.4 release, probably not 10

11. Security Update/bug fix release of xml-security library Whitelisting/blacklisting of crypto algorithms at “application” level Conditional support of ECDSA signatures Dynamic selection of algorithms based on metadata extension: 11

12. Logging / Monitoring New default logging configuration: Mirrors WARN and higher to a warning log to highlight problems Dedicated debugging log for signature issues Status handler includes local system time and OS- derived platform data 12

13. Discovery Service

14. DS: Embedded Make discovery easier for SPs to deploy Consumes data from SP 2.4 Added to a page by: adding a adding two Beta release in November https://spaces.internet2.edu/display/SHIB2/DSRoadmap

15. DS: Centralized Use embedded DS as primary UI Better APIs for filtering and sorting Configuration more aligned with IdP Distributed with configured container

16. Identity Provider

17. Profile handlers to accommodate more in-flow extensions e.g. terms of use, attribute consent, holder of key support Rework authentication APIs better support for non-browser clients support for SPNEGO, OTP https://spaces.internet2.edu/display/SHIB2/IdPRoadmap

18. Identity Provider Reduced configuration files Support for HA-Shib like clustering: reduced configuration no process to manage & monitor provides a clustered data store https://spaces.internet2.edu/display/SHIB2/IdPSimplifyConfig

19. SPNEGO

20. What is SPNEGO Log in to Kerberos/Windows domain No need to log in to websites

21. Why is it hard?

22. 403 error page if SPNEGO not configured or user not logged in to domain No way to query the browser to determine if SPNEGO is configured Nothing a user can do once they get a 403

23. How do we fix it? Provide users a choice to log in with SPNEGO Provide a link to a separate app that: checks if a browser is configured provides browser specific config guides sets a permanent cookie if user/browser can ’ t support SPNEGO

24. How do we fix it?

25. One Time Password

26. Why? Certain use cases want multi-factor authn User certs and time sync tokens are hard and expensive to roll out

27. How? 1. User logs in 2. SMS with one-time code sent 3. User enters it in the IdP Google recently deployed a similar scheme

29. Technical Details Requires two log in screens as user has to be identified (by first factor) in order to know to whom to send the SMS Sites deploying will need to provide a way for users to opt-in in to such a method Might need to send a few tokens to users ahead of time in case they don ’ t have cell access