Shibboleth Possible Features

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.
• Well 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)

1. Provide tools to manage target side policy (ie
   AAPs, and RM policy).
2. Provide a java-based target side implementation.
3. Finish support for multiple Federations Use the
   Federation trust file, rather than the general
   purpose CA bundle, when validating the SHAR/AA
   communication).
4. 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.
5. 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

1. Provide web-based GUI tools for managing ARPs.
2. 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.
3. Later versions could provide support for Dynamic
   Attribute Release.
4. Continue to extend the functionality in the AA's
   ARP engine.
5. Validate the ARP processing model with
   librarians.
6. Extend the implementation to support "ARPs
   associated with groups (ie courses)"
7. 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

1. Package the target side implementation as a
   library,
2. web based applications providing dynamic content
   can easily use Shibboleth functionality.
3. This will require producing a new kind of
   documentation -- a "Programmer's Guide".
4. 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?
5. Continue to improve the handling of error
   situations.
6. 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)
7. 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

1. 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

1. Publish the v1.0 Shibboleth Architecture
   Specification. ( See Date Tue, 24 Jun 2003
   093916 -0400  From Scott Cantor )
2. Librarians Guide to Deploying Shibboleth
3. Provide "Easier-to-use" installation
   documentation (packaging, content)
4. Document processes for managing a federation, and
   managing origins and targets (ie managing, once
   you've installed and are in production)
5. (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)