Shibboleth Possible Features – Version 2

1. ShibbolethPossible Features – Version 2 Steve Carmody July 9, 2003

2. Outline • Version 1.0.1 (July 2003) • Version 2 • Process Going Forward….

3. Version 1.0.1 (July 2003) • W2K based target • Apache • IIS (somewhat crude) • No htaccess support • Configuration done by editing text files • SHAR will run as service • Will come as a zip file…..

4. Version 1.0.1 (July 2003) • Target side support for storing session information in an SQL DB. • We’ll distribute a plugin that supports MySQL (licensing issues worked out) • Someone in this room is rumored to be soon working on an Oracle plugin….

5. Version 1.0.1 (July 2003) • Simplify target configuration process (eg overlapping directives).

6. Version 2 • Release Strategy • Through the various alpha and beta releases, leading up to the v1.0 release, the Shibboleth project has created "release packages", bundling large numbers of changes into each release. With the v1.0 release, however, we think we have provided a stable platform, and (hopefully) many varieties of new functionality can be built on top of this platform. • Going forward from this point, we expect that in many cases new functionality will be provided as an add-on, rather than as a completely new release. This should greatly simplify the upgrade process. There will still be major releases, when significant functionality improvements occur. However, we will no longer be waiting for the next major release in order to make add-on functionality available.

7. Desired Functionality (50K foot view) • Additional Scenarios • Video • Use in 3-tier situations • Use by applications (when web-server embedded approach is inadequate) • Use by applications with no web browser component (eg LionShare) • Use in complex intra-campus authn + authz frameworks (eg Wisconsin)

8. Desired Functionality (50K foot view) • Provide web-based GUI's for managing ARPs. There will likely be more than one interface, targeted at different audiences and skill levels. • Extend the functionality of the AA's ARP engine (support ARPs associated with groups). • Provide a more flexible target side implementation, one that is better suited to the delivery of dynamic content (using the same url) and optional login. Review WebISO: Target Side Models sections 3 and 4 for a discussion of related issues. • Provide a more "polished, fully functional" W2K/IIS package • Provide tools to manage Federation metadata

9. Desired Functionality (50K foot view) • Provide tools to manage target side policy (ie AAPs, and RM policy). • Provide a java-based target side implementation. • Finish support for multiple Federations Use the Federation trust file, rather than the general purpose CA bundle, when validating the SHAR/AA communication). • Improve the handling of error situations. Append error-specific information to the origin site url included in the error page presented to the browser user. This should make it easier for browser users to "remember" the error messages, and correctly report them to their help desk. • Virtual host support (with the different virtual hosts using different keys, and being in different federations, etc) (both origin and target; shibboleth.ini currently allows overriding per hostname; some policy things are currently monolithic)

10. Short Term Priorities • Simple ARP Viewer For this target, list applicable ARPs For this target, display Effective ARP • Finish support for multiple Federations • Use the Federation trust file, rather than the general purpose CA bundle, when validating the SHAR/AA communication).

11. Short Term Priorities • Improve the handling of error situations. • Append error-specific information to the origin site url included in the error page presented to the browser user. • Possibilities include: • Defined error codes • Error message text • Info describing target site and context of error • This should make it possible for origin sites to process this info, and help users to “report” problems • Apache 2 Support (with IP V6)

12. Other PossibilitiesFeedback PLEASE!

13. Origin • Provide web-based GUI tools for managing ARPs. • We currently imagine a range of tools matching different roles and skill levels, ranging from site admins and librarians on the high end to "general browser user" on the low end. • Later versions could provide support for Dynamic Attribute Release. • Continue to extend the functionality in the AA's ARP engine. • Validate the ARP processing model with librarians. • Extend the implementation to support "ARPs associated with groups (ie courses)" • Work with campuses that have PKI-based authn frameworks deployed, identify various PKI-authn-related scenarios and address the important ones (see recent note from Bob Brentrup describing recent conference call among these sites).

14. Origin • Extend the AA implementation so that a single instance of the AA can be configured to support multiple origin site names. • Validate HS crypto performance. • Provide a more dynamic method for an origin to specify the authn method for user x (especially if origin is offering multiple possible authn methods). • Provide support for Audit logging • Possible additional attributes • baseURL (used by sfx), • CampusAffiliation, • Unique persistent opaque ID )

15. Target • Package the target side implementation as a library, • web based applications providing dynamic content can easily use Shibboleth functionality. • This will require producing a new kind of documentation -- a "Programmer's Guide". • Provide a more "polished, fully functional" W2K/IIS package (drawing on PubCookie's experience, and the requests they've received.) Possibilities include: re-do configuration in "IIS-style"; possible GUI configuration tool; protecting content and applications when some browser users are not in the local AD. Are there .NET issues? • Continue to improve the handling of error situations. • Provide virtual host support (with the different virtual hosts using different keys, and being in different federations, etc) (both origin and target; shibboleth.ini currently allows overriding per hostname; some policy things are currently monolithic) • Develop a java-based target side implementation (OCLC, possibly JSTOR, OKI, etc)

16. Target • Implement the target side functionality required to support GUI ARP management • Provide an interface that myAA could query, in order to obtain target metadata. • Provide support for Dynamic Attribute Release. • Provide tools that simplify the management of target side policy (eg locally managed sites files, AAP, attribute definition, htaccess files) • Provide an optional Resource Manager that uses XACML. • Extend the SHAR/AA to support non-URL named resources • Smaller Items: • Provide support for apache 2.0 • Provide support for RH 9 (RH 7.x and 8 are losing support this december) • shire fills error logs when sites.xml mis-specified; (code up something like mod_ssl uses)

17. WAYF • Provide improved “remember the origin” functionality described by vendors

18. Shibboleth Architecture • Think about and explore: • Various methods that commercial targets could use to determine the browser user's origin site (continue the current conversation) • Browser navigation in a "multi-federation world". • The relationships between RBAC and shibboleth attributes • Relationships with Liberty v2, SAML v2 • Shib as ISO

19. Federations • Finish support for multiple Federations • Extend metadata to include information about Application Domains and additional information about Origin sites. • Provide tools that Federations would use to manage Federation metadata (especially important for other federations)

20. Documentation • Publish the v1.0 Shibboleth Architecture Specification. ( See Date: Tue, 24 Jun 2003 09:39:16 -0400  From: Scott Cantor ) • Librarians Guide to Deploying Shibboleth • Provide "Easier-to-use" installation documentation (packaging, content) • Document processes for managing a federation, and managing origins and targets (ie managing, once you've installed and are in production) • (requested by Barry) Running Shib in Production (Sysadmins Guide)

21. Process • Open discussion to the Shib community • Use a collaboration tool to manage (and organize) discussion (bugzilla, wiki, ?) • Develop definitions and priorities • Encourage broader participation in coding effort (evolution toward structure as an open source project)