Skip to end of metadata
Go to start of metadata

Shibboleth Project Work Packages

The following document track the various work packages within the Shibboleth project.

It provides:

  • a high level description of each work package
  • whether the project is being worked on now or will be in the future
  • estimated completion date of the work, assuming a stable level of developer resources
  • the total amount of time, given in person months (PM) each work package is expected to take
  • the amount of time, given in person days (PD) per calendar month, individuals spend working on the package
  • the relationship between packages
Icon

Note, all work packages related to software products include development, testing, packaging, and documentation within their total effort estimates. Total effort estimates however do not include user support time which is covered by a separate work package.

This document does not provide deep technical details of the work going on in any particular software project but it does link to such information when available.

Comments, suggestions, and discussions regarding listed work items should be directed to the developer's mailing list.


Committed Work

The following work items are currently staffed and work is ongoing.

Project Overhead and Infrastructure

Estimated Completion: ongoing
Total Effort: n/a
Monthly Effort: Scott: 3PD, Brent: 1PD, Rod: 1PD, Ian 1PD, Tom 1.5PD
Depends On: nothing
Work Description: This work package encompasses efforts to "keep the lights on" for the Shibboleth projects. This includes attending teleconferences, face-to-face meetings, core list emails, etc. Also includes ongoing management of the infrastructure, and basic coordination among the team.

Standards Development

Estimated Completion: ongoing
Total Effort: n/a
Monthly Effort: Scott: 1PD, Ian 1PD
Depends On: Nothing
Work Description: This work package encompasses the effort expended to participate in, and keep track of, specifications from standards bodies such as OASIS, W3C, IETF, Kantara, etc. We have scaled back our efforts here to focus on development work.

User Support

Estimated Completion: ongoing
Total Effort: n/a
Monthly Effort: Scott: 1.5PD, Brent: .5PD, Rod: .5PD, Ian .5PD
Depends On: nothing
Work Description: This work package encompasses the effort spent supporting users of the Shibboleth software through the user's mailing list.

OpenSAML-C, version 2, Maintenance

Estimated Completion: ongoing
Total Effort: n/a
Monthly Effort: Scott: .5PD (superseded by 2.5.2 deliverable)
Depends On: nothing
Work Description: This work package encompasses the effort in maintaining the C++ OpenSAML stack (the xml-security, xmltooling, opensaml libraries). This includes bug fixes, testing, release preparation and distribution.

OpenSAML-J, version 2, Maintenance

Estimated Completion: ongoing
Total Effort: n/a
Monthly Effort: Brent: .5PD
Depends On: nothing
Work Description: This work package encompasses the effort in maintaining the Java OpenSAML stack (the xmltooling, openws, opensaml libraries). This includes bug fixes, testing, release preparation and distribution. This product is in maintenance-only mode, no no features will be added to it.

IdP, version 2, Maintenance

Estimated Completion: ongoing
Total Effort: n/a
Monthly Effort: Brent: .5PD, Scott: .5PD
Depends On: OpenSAML-J, version 2
Work Description: This work package encompasses the effort in maintaining the V2.x Identity Provider product. It includes bug fixes, testing, and release preparation and distribution.

Native SP, version 2, Maintenance

Estimated Completion: ongoing
Total Effort: n/a
Monthly Effort: Scott: .5PD
Depends On: OpenSAML-C, version 2
Work Description: This work package encompasses the effort in maintaining the 2.X Service Provider product. It includes bug fixes, testing, and release preparation and distribution.

OpenSAML-J, version 3

Estimated Completion: Beta in first half of 2014, Released with IdPv3
Total Effort: TBD
Monthly Effort: Brent: 5.5PD, Scott: 1PD
Depends On: nothing
Work Description: This work package encompasses the work of developing the next major version of Java version of OpenSAML. This includes moving to a multi-module maven project, refactoring some code, removing deprecated APIs and addition of new features. More Details >>

IdP, version 3

Estimated Completion: Q3 2014
Total Effort: TBD
Monthly Effort: Tom: 15PD, Brent: 2PD, Rod: 8PD, Scott: 4PD, Daniel 3PD, Ian 1PD
Depends On: OpenSAML, version 3
Work Description: This work package encompasses the work of developing the next major version of the Identity Provider product. This includes moving to a multi-module maven project, refactoring some code, removing deprecated APIs and addition of new features. More Details >>

Metadata Aggregator, Snapshot Refresh (v0.8.0)

Total Effort: Tom: 5PD, Ian: 5PD
Monthly Effort: None at present
Depends On: OpenSAML 3 utility module
Work Description: A refresh of the prerelease Metadata Aggregator to provide a more stable snapshot with some bug fixes for early adopters, who have run into several issues with the existing release that have been fixed already. This would include tagged releases of some supporting libraries.

Metadata Aggregator, version 1

Estimated Completion: on hold pending other work
Total Effort: 3PM
Monthly Effort: None at present
Depends On: OpenSAML 3 utility module
Work Description: Software capable of reading in multiple metadata sources, validating and transforming the data, and outputting new metadata documents from the command line or via the Metadata Query Protocol. This work include development, testing, documentation, and release packaging.


Planned Work

Planned projects are work packages accepted by the consortium but which are not yet under development due to lack of resources. When committed work packages complete the individuals working on the completed work package will normally pick up the next project from this list.

The following items are listed in order of priority (those at the top being worked on before those at the bottom). The ordering may change depending on available developers.

 


Under Discussion

These are projects which have been proposed but which the Consortium has not yet decided to work on.

Understanding Shib/SAML Documentation

Total Effort: 2PM
Depends On: Nothing
Work Description: This work package encompasses the effort to develop a good set of documentation that explains SAML, Shibboleth, and Federations at a conceptual level. The intended audience for the documentation is those new to the subject matter.

TestShib, version 3

Total Effort: 1PM
Depends On: OpenSAML, version 2
Work Description: This work package encompasses the effort to create a new TestShib software package. The current TestShib's registration system was developed by a number of novice programmers over a period of years. It is a total mess and impossible to work with. It needs to be rewritten from scratch with a focus on ease of deployment and resilience to the invalid metadata that deployers throw at it. More Details >>

Centralized Discovery Service, version 2

Total Effort: 1.5PM
Depends On: OpenSAML, version 3 Embedded DS
Work Description: This work package encompasses the work of developing the next major version of the Centralized Discovery Service product. This includes significant internal code refactoring, changes in configuration files to align with the IdP, and production of JSON metadata feed used by SHIB2:embedded discovery service. More Details >>

IdP One Time Password SMS Authentication

Total Effort: TODO
Depends On: IdP, Version 3
Work Description: This work package encompasses the effort to add support, to IdP v3, an SMS based multi-factor authentication mechanism. The idea is that after a username/password loginthe IdP would send an SMS message containing a code that would be entered in to a second login page. More Details >>

SP Extension for Delegation Facilitation

Total Effort: 1PM
Depends On: nothing
Work Description: This work package encompasses the effort to extend the SP's current delegation support. Current support for delegated HTTP access includes a number of complex configuration tasks and duplication of settings between the SP and the HTTP client library, as well as direct access to the SP's private key. An SP extension invoked via "loopback" HTTP will offload much of the interaction with the IdP and possibly even WSP from the client library and radically simplify configuration and the amount of code needed. More Details >>

Small Item IdP Wishlist/Backlog

Work Description: a collection of small work items that have been suggested for the IdP More Details >>

IdP User Interface

Work Description: There are various things that the IdP might expose a UI in order to manage. They are:

  • User-initiated IdP-initiated Single Sign On and Single Log Out
  • User-initiated persistent ID disassociation
  • User-initiated removal of attribute release consent
  • Admin-initiated single log out of user

IdP Configuration Tooling

Work Description: From time to time people have requested some form of configuration tooling for the IdP. The suggestions range from command line tools, desktop UIs, and web-based UIs. In general it seems like the most often wish revolve around configuring:

  • Container's user-facing SSL certificate (may include generation of CSR as well)
  • New IdP credentials (in same manner as current installation)
  • Generate metadata based off of configuration
  • Add/remove metadata provider - will support file and URL based metadata and digital signature validation
  • LDAP/Kerberos/Container authentication
  • Database and LDAP data connectors
  • Configure release of attribute to all, or a specific, relying party

Small Item SP Wishlist/Backlog

Work Description: a collection of work items that have been suggested for the SP More Details >>

SP Client-Side Session Cache

Work Description: The use of server-side sessions is a significant hassle in deploying load-balanced applications behind an SP. Moving that state into a set of encrypted and signed cookies would be a major benefit, but there are likely to be size limitations and it would need to be efficient enough to use on systems with a decent number of requests. A format would also have to be developed, and XML would not be efficient enough in either space or time.

SP Validation Service

Work Description: The difficulty of finding effective metadata, signature, and certificate validation logic in other SAML implementations has led to suggestions that the SP should offer some kind of locally callable or "REST"-oriented service for validating SAML messages.

Scriptable SP Plugin(s)

Work Description: It may be possible to explore the embedding of a script engine into a plugin to the SP. This could take the form of dedicated plugins to accomplish existing functions with scripts, or even the possible use of interpreted C++ (yes, it does exist) as a way of implementing arbitrary plugins. The use of Javascript seems to be the most likely to be feasible.

Developer Documentation

Work Description: There is very little documentation available for developers that wish to extend Shibboleth. It has been suggested that we devote some time to developing a set of a docs for developers.

Infrastructure Documentation

Work Description: We have a lot of infrastructure services, but little formal documentation for them, which will make project transitions much harder.

Application/Framework Plugins

Work Description: Functionality and documentation of Shibboleth/SSO-enabling plugins for applications and development frameworks often lack robustness, good error handling, advanced features, or good documentation. We might work to improve this situation, either through direct development, collaboration with existing groups, authoring documentation for plugin authors, etc.

SAML-ECP GSS-API Mechanism

Work Description: Specification of a browser-less GSS-API mechanism for SAML based on ECP is largely complete with stable drafts available. Completion of the drafts depends on implementation feedback. A mechanism would need to be developed in C++ with C linkage to the mechglue layers of at least MIT and Heimdal GSS libraries. Other implementations, such as Java, would also be useful if possible. Some work on this is being done by NCSA staff with ISOC funding. This work item primarily refers to productionizing this code under the auspices of the project, and extending it with additional features.

ECP Extensions

Work Description: The version of ECP designed for the GSS-API mechanism (see above) includes security enhancements like channel binding and holder of key support that could be implemented in the IdP and/or SP. The IdP would be the likely starting point since it would support the GSS-API work as well.

OpenID Connect

Work Description: A large (a cynic might say massive) set of new specifications exist to implement SAML features in terms of OAuth2 and a new set of JSON security standards. Scoping and developing something in this area is an obvious future step for the project.

Office 365 Integration

Work Description: Microsoft has made documents publically available describing fat-client integration with Office 365 via WS-Trust. They are offering technical contacts to faciitate this work. We have to determine viability and our willingness to adopt non-standard profiles without public change control procedures.


Parked/Rejected Work

These are projects which were proposed but were found to either be ill-defined, out of scope, or without sufficient interest from the project members. These items may be revisited from time to time as situations change.

Java Service Provider

Work Description: An analogue of the native, C++, SP written in Java. It is unclear who would really use it, what technologies it should use, and which native SP features it should really support. State of current alternatives (e.g. OpenSSO, OIOSAML) also unclear.
Reason For Rejection: There is no clear demand for this work, but most particularly no consensus on approach/scope. A few sites expressed some interest but not enough to make the effort worth while. More info >>

ADFS, version 1, Support for IdP

Work Description: version 1.3 of the identity provider had support for Microsoft's proprietary ADFS, version 1, protocol. This was not brought forward in to version 2 because it didn't seem to be used by very many deployers.

OpenID Support

Work Description: Add support for OpenID, version 2 protocol along with Attribute Exchange, PAPE, and Simple Registration extensions to the IdP, SP, or both.
Reason For Rejection: There is no use case for this work or real interest from the community. An prototype extension was available for the IdP for 9 months and only one site tried it. OpenID is on the verge of obsolescence by a variant built on OAuth 2. More Details >>

InfoCard Support

Work Description: Add support for Microsoft InfoCard managed cards to the IdP, SP, or both.
Reason For Rejection: There is no use case for this work or real interest from the community. Furthermore, Microsoft has discontinued its delivery of future versions of this technology. More Details >>

Optional Attribute Control in IdPv3 Consent Engine

Work Description: Like uApprove today, the consent engine of the IdP will allow a user to either accept the release of all attributes or none of them. Metadata and attribute queries can carry information about which attributes are required and which are simply preferred by the SP. A suggestion is to use this data and allow the user decide which, if any, optional attributes they would release. It's unclear how usable such an interface would be.
Reason for Rejection: Current view is to get the consent engine done and incorporated in to the IdP and collect some real world usage data for about 9-12 months. This topic should be revisisted at that point.

Resource Registry, version 1

Work Description: Various federations have software that devolved management of IdP/SP information to people closer to those entities. SWITCH's Resource Registry is the canonical example of this. People have made requests that such a tool be available from the Shibboleth group.
Reason for Rejection: Currently there is no clear indication that the community really wants this. The couple of people that have suggested it in the past were never clear what functionality were really wished for. Currently each federation has something that might be considered a resource registry and each is very different so it's unclear that a single code base could ever cover the all, or even the majority, of these uses.

Security Audit/Review

Work Description: Various open source projects have undertaken formal code audits or reviews for security issues, and this sometimes is raised as a pseudo-requirement for governmental usage.
Reason for Rejection: Lack of resources/expertise, no explicit demand/requirement for it.

Conformance Testing

Work Description: Kantara (formerly Liberty) does annual conformance testing of SAML implementations against various conformance testing suites, particularly eGovernment profiles that the project has participated in the development of. Vendors have expressed interest in Shibboleth participating.
Reason for Rejection: Lack of demand from our community, and unwillingness to devote limited core team resources to the effort. Also the fact that we don't support some of the features required by the testing, and do support things we think are more important but aren't part of the testing.

SAML 2.1 Standard

Work Description: This work package encompasses the effort expended to update and revise the SAML 2.0 standard within the OASIS SSTC. With the project turnover, we feel unable to provide substantial work toward such an effort. Chad's new employer has allowed him to devote some time toward this, and the project will participate minimally as part of ongoing effort devoted to standards development.

  • No labels