Shibboleth Project Roadmap for 2024-2027

After internal discussion and consultation with the Consortium Board, taking into account our current and projected budget, the project has laid out the following work plan for the next several years. This is presented in terms of a summary of proposed work items, identified risk factors (known unknowns if you will) that would impact our plan, and a more detailed explanation of the work items proposed and the estimated amount of time devoted to them. The time frame of 2024-2027 is a best estimate as to the length of time it will take to deliver on these priorities.

It is important to note that this is a summary of significant “new work”, be it brand new function or enhancements to existing material or software. It does not include the “keep the lights on” work, but those tasks occupy a substantial percentage of project time (varying with circumstances) that we factor into our planning. Small feature enhancements typically requiring less than 20-30 hours of time, and sustaining existing supported software are both part of that overhead.

Work Summary

The following are proposed as deliverables for this time frame:

• Support for Passwordless Authentication (i.e., FIDO, WebAuthn, Passkeys, etc.)

• Support for Verified Credentials (more speculative right now but will involve tracking active standards efforts and aligning to any emerging R&E profiles where applicable)

• Support for OIDC Federation in the OP and RP plugins

• Redesigned “V4” Service Provider

• Enhancing IdP Product Documentation and Configuration

• Identity Provider End User and Administrative UI Enhancements

Risk Factors

These are identified risks to our ability to deliver on the roadmap, excluding obvious/ongoing factors such as loss of staffing or funding:

• The current Service Provider (V3) is dependent on a number of libraries that are being nominally maintained and sustained solely by the Shibboleth Project. A catastrophic security issue in one of these libraries (or to a lesser degree in code of our own design) would potentially divert critical resources from the project and delay the work needed to replace the code base entirely. The scope of such an issue is difficult to predict, and could be very simple or very complex/widespread. It is unknown to what extent additional contributors could be found to work on the problem from outside the Shibboleth community (the current state of affairs has lasted almost a decade with no additional help forthcoming).

• Google and to a lesser extent other large technology companies have been engaged in early efforts to redesign much of the core behavior of the web browser around a new set of approaches to rein in the problem of malicious tracking. These efforts to improve privacy, even taken at face value, include some proposals that have the potential to undermine or outright prevent the use of many of the core standards and specifications we rely on today, including both SAML and OpenID Connect. There is a perception that new technologies built around wallets and verified credentials are being positioned as replacements. The time frame for the adoption, and specifically the requirement to use, these new approaches could create significant pressure on our community to migrate rapidly to new approaches, necessitating decisions about whether to rapidly invest in and build out new features or perhaps work with other software projects to shore up their capabilities to better meet our needs. For obvious reasons, were all of the existing protocols to sunset, our plans for the SP (see below) would likely change radically.

• Finally, much of our core technology stack relies on Java and the Spring Framework, both of which are open source but are also corporately-owned and subject to future changes that may not always align with our time frames and plans. Java itself is evolving much more rapidly than in the past, and so it is a larger task for us to maintain our software and upgrade these components in a timely fashion. To date, this has not caused significant trouble, but things could change.

Work Plan Summary

We have already begun work on some of these projects during the first half of 2024.

Description of Work Items

These are more detailed summaries of the work we have planned to provide additional context or relationships to other work.

Passwordless / WebAuthn

We are delivering two separate workstreams for this that are largely independent.

One is an extension to our Duo plugin that adds a passwordless mode of operation and was delivered via a plugin update in May of 2024. This was developed with substantial assistance in design and testing from some members.

The second is a native implementation of WebAuthn in a new plugin using Yubico’s Java libraries and supporting a range of deployment options and should be compatible with any FIDO 2 tokens. The enrollment and management back-end for this work will be the IdP’s existing StorageService interface as well as including interfaces allowing for alternative implementations that don’t specifically require that approach. Notably, supporting the StorageService model allows for simple testing via the “client-side” StorageService implementation included with the IdP, though of course this is not expected to be interesting for production use.

For the initial releases, we expect to deliver fairly bare-bones management capabilities for users and system administrators, suitable for basic use. More comprehensive UI support will be forthcoming in the larger, separate deliverable addressing a wider range of UI requirements later in the plan (see the Identity Provider User Interface work item below).

Service Provider Redesign

We will be working over the next few years to reimplement the Service Provider software as a plugin to the Identity Provider that relies on a much “thinner” native agent design that delegates most of the work into the plugin. We intend to build and support at least Apache 2.4 and IIS 7+ agents as are currently supported now, and will consider the support of FastCGI as a follow up if that proves necessary or at least of significant interest.

While the “hub” will be an IdP plugin, it does not follow that every deployment of it is expected to be operating as an IdP or running as part of an existing deployment of that software in an organization (though of course it could). Rather, it allows us to focus our work on building something that can be delivered and installed/maintained using our existing build, release, and update process to reduce cost and effort. We expect to be able to produce new delivery models for the IdP to operate as an SP hub “appliance”, possibly in concert with existing member partners that produce alternative packaging models now.

Agents will be designed around a self-contained build that does not include any non-native dependencies, to avoid repeating the “orphaned library” problems we have now and to simplify the build and delivery of the agents. Agents will rely on the IdP plugin in Java to perform much of the work currently implemented in C++, including parsing any XML configuration left, all security and protocol processing, and attribute manipulation. We would expect this to reduce the non-Java code footprint by at least an order of magnitude or two.

Agent-based configuration will be confined to the subset requiring “local agility” such as defining rules for specific content, session behavior, some amount of error handliing, etc. We intend to support a many-to-one relationship between agents and the hub, and will support remote use of the hub over HTTPS.

The transition to the new model will be at least somewhat disruptive and we do not expect every deployer today to be interested in this approach. Nevertheless it is the only practical option we have to deliver a working solution we can maintain. As the design is worked out in more detail, we will be able to produce preliminary guidance on what this will look like and what the migration path will be so that anybody considering alternatives can take that into account, but we fully encourage people to be exploring all their options at this obvious transition point with the software.

We do intend that the trade-off for making this transition will include many advantages that may offset the disruption, including:

• Near-future support for additional protocols such as OpenID Connect, verified credential technologies, and perhaps others, generally without requiring awareness by or modification to agents.

• Significantly less agent software “churn” than was historically true of the SP, and much less native attack surface.

• Vastly simpler agent configuration by migrating the most technically complex parts into the hub, including all of the SAML-specific or OpenID-specific aspects, including keys.

• Hub configuration that extends existing IdP configuration syntax (for better or worse, one approach is better than two). This also allows ongoing improvements to the IdP to be automatically applicable to the SP, increasing the value of that work.

• A documented, “as simple as possible” API for development of new agents by us or third parties for additional environments.

We also are open to discussions with stakeholders on requirements, as the level of experience with SSO is much more widespread than it was 25 years ago.

OpenID Federation

Alongside other enhancements, the next phase of work on the OpenID plugins will include implementing support for OpenID Federation. This will be impacted by any community-specific profiles that may emerge from our traditional “market” in research and higher education, as implementing all of a complex specification was not a productive use of time in the SAML realm. Adoption will depend greatly on what others implement, so that will impact the scope of our work.

A major goal for this work will be to explore ways of achieving some degree of harmony between the SAML and OpenID metadata support, due to the extensive support and reliance on SAML metadata today for configuring our software behavior. Ideally we would support those features interchangeably whereever possible.

Verified Credentials

Regardless of the outcome of the aforementioned browser privacy initiatives, there is substantial interest (if not yet widespread uptake) of long-incubating concepts around digital wallets and credentials that are held by client devices but issued by authorities and verified by relying parties. Our initial goals are focused on understanding the space, and understanding the role the browser vendors (who unfortunately also control all of our popular platforms) are playing and the role they are allowing third-parties to play in this ecosystem. With that understanding, we can work jointly with the community to understand what kinds of new capabilities we can offer. This is the most “speculative” part of our work plan, not so much because the technology is itself all that speculative but because of the lack of deployment experience to guide us.

Our primary role is expected to be an issuer (and perhaps verifier) of these new forms of credentials, and not as a source of a digital wallet, but as “server-based” wallets are likely to dominate for lots of practical reasons, we won’t rule that out at this stage.

We would expect to be in the proof of concept or prototyping stages by the middle to end of this work cycle, and if it proves fruitful this would likely be a substantial focus of work in the future. This may also be an opportunity to attract interest from others working on this problem and willing to avoid re-inventing the wheel by partnering with us.

Enhanced Product Documentation and Configuration

The feedback from our surveys and from members has indicated a need to improve our documentation, and to focus more on concepts, introductory material, and examples, rather than being as focused on reference material. Part of this work will include up-to-date guidance on best practices with the software in terms of how to best manage it and which approaches to focus on. Eliminating older approaches is not the intent, but rather to de-emphasize them in the documentation and produce better examples that focus on how best to do things in the future.

Part of this will likely include continued work to simplify the configuration process through a variety of means, which is a natural feedback loop with improving the documentation. This will include continued adoption of techniques we’ve already been using and new approaches we have not explored as much to this point. This will likely include addressing the problem of understanding, reporting on, and possibly manipulating the large set of properties that have accumulated over the years as we’ve shifted a great deal of historically XML-based configuration to properties.

Notably, the Service Provider redesign and alignment with the IdP in many areas provides an obvious opportunity to start from scratch to some extent with the SP documentation to ensure it meets the same goals.

Identity Provider User Interface

A number of newer (and some older) features in the software are in need of “completion” through the introduction of new user interface components either within, or alongside, the IdP. A non-exhaustive list of some of these needed capabilities include:

• End-user reporting and review of login activity, institutional data, etc.

• End-user privacy/consent review and management

• End-user and administrative enrollment and management of WebAuthn/Passkey credentials

• End-user and administrative review or management of account lockout state

Much of this work will also require new documented interfaces for accessing or updating data managed by the IdP, which has generally been left as an implementation detail in the past. The bulk of the work of course is the actual nuts and bolts of building a traditional web front-end to software that has studiously avoided taking on that task until now. Questions of how tightly to couple this work to the IdP remain, but it’s fair to say “loosely” is probably the preference, making this quite possibly a separate software package or an extension of an existing third-party project. There are existing third-party efforts in a similar direction, notably a pilot project in the EU that is a more tightly coupled design at this stage.