IdP / OpenSAML patches next week

[Vlad Mencl]

Hi Scott,

Thanks, this is very helpful.

In particular thanks for pointing out the distinction between Java 
Platform and Execution Environment.

I see that 
https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/1161266638/Product+Platforms
explicitly lists Java 21 as supported execution environment for Java 17 
Platform.  That's exactly the answer I was after.

Sorry about the confusion: where I said we were running Tomcat 10, I did 
mean 10.1.  Should have been clearer.


I have now checked the changelog for Servlet API 6.1 - at
https://jakarta.ee/specifications/servlet/6.1/jakarta-servlet-spec-6.1#change-log

 From 6.0, the only change that could have issues with backwards 
compatibility is #443 - dropping support for SecurityManager.

But for deployments not using a SecurityManager, 6.1 should be 
backwards-compatible with 6.0, so I take it as justification why IdP 
5.1.x works with Tomcat 11.


Thanks for your help!

Cheers,
Vlad



On 07/05/2026 01:05, Scott Cantor wrote:
>> I understand that for IdP 5.2.x, I'll need Tomcat 11.  (It surprisingly works with Tomcat 10, but I want to stay within the official recommendations).
> 
> Tomcat 10 is EOL. Tomcat 10 (and 10.1) claims not to support Servlet 6.1, so I can't speak to why their documentation is wrong. It's possible the incompatible changes are in Servlet 6.0, which Tomcat 10.1 does support.
> 
>> (1) Does the IdP support Java 21?
> 
> Yes, allowing that we only promise support for Debian's Java to members.
> 
> https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/1177321655/Java+Distributions
> 
>> I can see IdP 5.1.x works with Java 21, but I'm asking for confirmation.
> 
> Java support is by "platform", which is a designation we use for the core Java compatibility, what we build it on and target, and the page defines what the Java 17 "platform" supports. All 5.x releases would use that platform, we would never change the platform in a minor release.
> 
> Ideally the same would be true of the Servlet API version, but unfortunately Spring has made that impossible for us unless we start issuing major updates a lot more often, to tie in the Servlet API version into the platform designation.
> 
> We may ultimately have to do that. For a long time, the Servlet API was pretty frozen so nothing using just that API was all that impacted by Java EE changes. That has not been the case of late. I don't know if it's going to stop changing or not.
> 
> I can say that while the IdP is "mostly" insulated from these issues (which is likely why it tends to work on "whatever" to a point), changes to the Cookie API are a problem for us (and it has changed recently) and the SP plugins will be *very* impacted by any changes because we have to directly implement the interfaces, so any changes to them will break compatibility every time.
> 
>> (2) Does IdP 5.1.x work with Tomcat 11?  I'm trying to see if I can isolate the upgrade steps.
> 
> IdP 5.1.x assumes Servlet 5.0 compatibility. Going by their documentation, the assumption would be that they have no actively supported container that actually supports that, but the obvious candidates would be 10.1 or 11.
> 
> Jetty uses "personality modules" to directly support each Servlet API version explicitly, so there are no ambiguities as to what they support or don't support.
> 
> We're just guessing with Tomcat, we no longer explicitly test it.
> 
>> In IDP5 SystemRequirements, I see (for IdP 5.0.x-5.1.x):
>>
>>> Tomcat 10.1 (apparently NOT Tomcat 11)
> 
> That was a guess because 10, which is the one I'd have assumed directly supports the proper Servlet version, went EOL. If 5.2 runs on Tomcat 10.1, then I can't really imagine 5.1 wouldn't run on 11, but I simply don't know.
> 
> With Jetty, they explicitly did NOT include Servlet 6.1 support in 12.0, so we had to require 12.1, and I know for certain IdP 5.2 just didn't run on 12.0. That sort of thing is why I simply assumed Tomcat wouldn't just accidentally "work" when it wouldn't be expected to, but that hasn't been the reported experience.
> 
> -- Scott
> 

-- 
Vladimir Mencl
Lead Software Engineer

Research & Education
Advanced Network NZ Ltd

E  vladimir.mencl at reannz.co.nz
www.reannz.co.nz