This page is used to capture the "broad" picture of where the project spends its time and energe and some of the "big ticket" work items that have come up in the past that are either queued up, or have been parked for various reasons. This document does not provide deep technical details of the work going on in any particular software project but may link to such information when available.
Comments, suggestions, and discussions regarding listed work items should be directed to the dev mailing list.
The best way to keep tabs on the project day to day is through Jira. We do not have a very sophisticated model there at the moment; rather we have issue filters that will show the issues and tasks scheduled for particular releases of the major software projects. Because our code is spread out into separately versioned components, the filters are the only "comprehensive" view of all the issues being worked on or planned.
The Dashboards for the IdP and SP products are somewhat organized and include access to a view of "Favorite filters", but you can also search for specific filters via https://issues.shibboleth.net/jira/secure/ManageFilters.jsp (just enter SP or IdP or whatever else into the search box). These are organized by version of course and should include versions beyond current releases to help track what is being worked on for future versions.
The following work items capture things that demand ongoing project time but do not represent "new" functionality or enhancements to code, processes, etc. They are documented for transparency in light of the significant resources they take.
Project Overhead and Infrastructure
This is "keeping the lights on" for the Shibboleth projects. This includes attending teleconferences, face-to-face meetings, core list emails, etc. Also includes ongoing management of project infrastructure, and basic coordination among the team.
Participation in, and keeping track of, specifications from standards bodies such as OASIS, W3C, IETF, Kantara, etc., as well as activities focused on the REFEDS community. We have scaled back our efforts on standards to focus on development work in recent years but continue to participate and inform REFEDS work.
Supporting deployers of the Shibboleth software through the Member-only support mechanisms or in response to mailing list questions from members. Non-member support is not subsidized and not project time.
Native SP Maintenance
Maintaining the supported Service Provider product version(s). It includes bug fixes, testing, and release preparation and distribution, and also includes the maintenance of a half dozen dependent libraries. It does not include significant feature work.
Embedded Discovery Service Maintenance
Maintaining the EDS, including bug fixes, testing, and release preparation and distribution.
Maintaining the Java OpenSAML library and supporting libraries. This includes bug fixes, testing, release preparation and distribution.
IdP and IdP Plugin Maintenance
Maintaining the Identity Provider product core and plugins. It includes bug fixes, testing, and release preparation and distribution. New feature work has largely moved out to plugin development.
These are projects and tasks that have staff time committed to them and are usually under active development.
Ensure support for Java 17 (the upcoming LTS release replacing Java 11) for the current IdP release branch. Other minor improvements as warranted.
Java 17, Spring 6
Migration of the IdP platform and dependencies (including OpenSAML) to Java 17 and Spring Framework 6.x to keep the platform appropriately current. This will remove some deprecated function but is not focused on new features.
Second Generation IdP Proxy Support
Add sufficient OIDC and possibly CAS support to IdP to handle proxying use cases without additional software footprint. SAML proxying support was added to IdPv4.
Additional features for the OIDC OP plugin, initially focused on use cases adjacent to OIDC specs, or adding optional OIDC material. Distinct from work focused on API security and full OAuth functionality, which is captured as "OAuth Authorization Service" below. See JOIDC project in Jira.
SP Packaging Automation
AWS-based process for automating SP packaging, at least encompassing RPM platforms. This will conincide with changes to the packages we produce.
SP V4 Redesign
Substantial design work
The SP is on an unsustainable path and needs to be replaced with a different software redesign that addresses sustainability challenges – see SP4Details
This work has begun with preliminary technical work and early planning and design, likely through 2021, with more comprehensive work starting in 2022.
Java Project Deployment Changes
The problems of unauthorized artifacts showing up in Maven Central require that we revisit and make decisions about supporting it, but no decisions have been made yet.
Browser Integration Testing
End to end testing with browsers through the free Sauce Labs service
We have a lot of infrastructure services, but little formal documentation for them, which will make project transitions much harder. With a number of things changing this year, it’s a good time to get this done.
Planned projects are work accepted by the Consortium but which are not yet under development due to lack of resources or unmet preconditions. When committed work is complete the individuals working on the completed work will normally pick up a project from this list.
Java, Various Techs
Research and implement support for emerging passwordless authentication features such as WebAuthn. Our problem remains the lack of a viable path to building a token management solution to support the core technical features, which are tractable but do not offer a deployable feature. The estimate entails the work that a "complete" solution might take.
Some preliminary work underway to assess WebAuthn and various options for implementing.
Metadata Aggregator V1.0
Java, XML, SAML
Initial product release of the framework and command line tool. Excludes previously intended Metadata Query Protocol functionality and in-depth documentation. Scope of work subject to input and time to develop final requirements by existing users.
These are projects which have been proposed but which the Consortium has not yet decided to work on. Most estimates here are highly speculative. These are generally "long haul" items that have been tabled for many years due to resource constraints and other priorities but have yet to be outright parked as rejected or infeasible.
Understanding Shib/SAML Documentation
Tech Writing, SME
Developing 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.
Enhanced Product Documentation
Tech Writing, SME
Developing a good set of product documentation that explains features more thoroughly and contextually, with examples, and better how-to material that is task focused instead of reference oriented.
3PM per product
Developing a good set of developer documentation for extension work on Shibboleth products. Documenting the SP and IdP would be separate items.
Packaging / Installation / Deployment
Packaging, Containerization, Installer Tools
This would span general installer improvements all the way to possible use of container technologies like Docker. Unclear if there's value in a general solution to that, but various groups have asked or have worked on things like this. Internet2 has stepped in to do this work with the TAP container.
An effort to create a new TestShib software package and platform. Of late, samltest.id seems to have filled this niche well enough.
Expansion of IdP Integration Testing
Java, Installer Tools
We need more extensive coverage of the installation processes and integration tests across different supported containers and platforms, to improve QA.
IdP User Interface
There are various things that the IdP might expose a UI in order to manage, such as:
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 logout of user
Admin-initiated reload of selected subsystems or metadata sources
Java Service Provider
An analogue of the native, C++, SP written in Java. This has been requested for a long time due to the deficiencies so many other SAML implementations have had. It's been parked for a long time, and we had hoped to see good implementations emerge, but that hasn't happened.
The work to redesign the SP is expected to migrate much of the core function into Java, and the agent architecture under discussion is hoped to provide a path to producing new agents at much less cost to the project. The estimate of time is based on having a delivered SP redesign to work from.
Office 365 Integration
Java, WS-Trust, OAuth
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.
This work seems of questionable value now given the SAML support across most of the applications and would probably take the form of OAuth support if we did anything.
OAuth Authorization Service
OAuth 2 introduces an infrastructure component for issuing authorization tokens, essentially similar to some of the eventual goals for SAML. We could add this kind of functionality to the IdP. Neither the demand for this, nor the actual use cases, are very clear at the moment.
IdP Configuration Tooling
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:
Generate metadata based off of configuration
Add/remove metadata provider - will support file and URL based metadata and digital signature validation
Database and LDAP data connectors
Configure release of attribute to all, or a specific, relying party
The Unicon GUI is convering a lot of this space at the moment though in a highly abstracted/insulated way through the metadata boundary and the MetadataDrivenConfiguration work.
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. We have a lack of resources/expertise, and no explicit demand/requirement for this. It would also be costly in time. With the need to rewrite the SP, it doesn't make a lot of sense to audit that right now.
These are projects which were proposed but were found to be strategically unaligned, 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.
Centralized Discovery Service, version 2
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 the embedded discovery service.
After consultation with members, the decision was made to park any work on this codebase and allow the original version to sunset with the V2 Java code base.
IdP Support for WS-Federation
Version 1.3 of the IdP had support for Microsoft's proprietary ADFS v1 protocol. This was not brought forward because it didn't seem to be used by very many deployers.
Support for OpenID 2 protocol along with Attribute Exchange, PAPE, and Simple Registration extensions in the IdP, SP, or both. 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.
Support for Microsoft InfoCard managed cards in the IdP, SP, or both. There is no use case for this work or real interest from the community. Microsoft has discontinued its delivery of future versions of this technology. More Details >>
IdP OTP SMS Authentication
SMS seems to have rightly lost a lot of supporters given its security flaws. Work on other tech makes more sense now.
Support for the emergent TLS Token Binding extension in our SAML implementations. This is dead in light of Google having pulled Chrome support for Token Binding.
SAML-ECP GSS-API Mechanism
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. Some prototype work on this was done by NCSA staff with ISOC funding.
At this point the work seems to be largely overtaken by other simpler approaches and in any event the project lacks the C++ development resources long term to seriously consider something like this.
SP Availability in Fedora
Effort to produce SP packages compatible with Fedora standards and to get them accepted into the Fedora project. This has unknown implications on Red Hat packaging. This was a request from the Moonshot team. GIven the state of the SP, this is parked regardless of the effort involved.
Resource Registry, version 1
Various federations have software that devolves 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 project. 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 all, or even the majority, of these uses.
Kantara (formerly Liberty) does (or did) some 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 at times, though not recently. There is a lack of demand from our community, and unwillingness to devote core team resources to the effort. We also support many things we think are more important but aren't part of the testing, and thus do not believe as a technical matter that the result is meaningful to customers, other than to rubber stamp poorly designed SAML implementations by competitors.
SAML 2.1 Standard
Effort to update and revise the SAML 2.0 standard within the OASIS SSTC. The work at the SSTC has essentially been put on hold due to lack of volunteers to work on it. Politically it would be quite difficult to make a lot of the sorts of changes that would benefit the project, particularly substantive changes to the conformance criteria since it would be impossible for most vendors to meet and none of them would ever want to do the work necessary to change that.