By removing OpenSAML3 support in Spring Security 6 we need to make sure that the OpenSAML dependency versions are updated and are compatible with JDK 17.
See: - https://github.com/spring-projects/spring-security/issues/10556#issuecomment-1201699608
Comment From: marcusdacoregio
@phtyson can you help me understand how OpenSAML 4 is not working with Java 17 (based on this comment)? Our samples are running with Java 17 and Spring Security 6 and it seems to be working fine.
Perhaps a minimal, reproducible sample would be great to check that.
Comment From: leshalv
opensaml4 uses javax, while spring security6 uses Jakarta EE @marcusdacoregio
Comment From: leshalv
I think opensaml5 should work better with springsecurity6
Comment From: marcusdacoregio
@leshalv I did not find the OpenSAML5 general availability release, can you help me to find it and understand how it would work better with Spring Security 6?
Comment From: leshalv
@leshalv I did not find the OpenSAML5 general availability release, can you help me to find it and understand how it would work better with Spring Security 6?
opensaml5 It is still under development, snapshot, Since the opensaml5 is based on Jakarta EE, it is more suitable for spring security6.
Comment From: leshalv
Pac4j has already started to support opensaml5, which I think is helpful for upgrading reference. pac4j-saml-opensamlv5
Comment From: EugenMayer
Opensaml 5.0 has finally been released, see
- https://build.shibboleth.net/maven/releases/org/opensaml/opensaml-parent/5.0.0/
- https://shibboleth.net/sites/snapshot/java-opensaml/5.0.0/project-info.html
- https://git.shibboleth.net/view/?p=java-opensaml.git
I'am currently not able to find any changelog at all, would be nice if someone could add those to the list of assets to work through for an possible adoption here.
Comment From: GDeen
I don't see OpenSAML 5.0.0 in maven repository yet. I hope this gets available soon, as using spring boot 3 in combination with Java 17 and OpenSAML is an issue now.
Comment From: marcusdacoregio
@GDeen can you elaborate more on what’s the issue? Maybe with a sample?
Comment From: EugenMayer
@GDeen you will never see any opensaml release in the maven repo, since those are not release to mvn at all. Since Shibooleth took over the development and maintenance, it is published only on their nexus. https://build.jc.net/maven/releases/org/opensaml/opensaml-parent/
Should you still use the versions from mvn - be aware, those are not only massively outdated but have severe security issues. Use https://build.shibboleth.net/maven/releases/ as your upstream. To my knowledge this is the official way to consume opensaml libs. Not sure i can find this in the spring security docs somewhere though.
@marcusdacoregio i do not think there needs to be an issue. We should follow up on the openSAML releases just to ensure people can use the maintained versions. Surely 4.x will receive updates for some time, maybe a year or more. But the road to 5 should be paved and established before 4 gets EOLed - right?
Comment From: GDeen
Our issue is that spring boot 3 uses Jakarta EE over javax.servlet, see https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#jakarta-ee
OpenSAML 4.0 requires javax.servlet, see for example: AbstractHttpServletRequestMessageDecoder which requires you to pass a javax.servlet.http.HttpServletRequest
Comment From: wapkch
Hi @marcusdacoregio Considering the following scenario, there is an application needs both Spring Security SAML service provider 6.x and SAML IdP, SAML IdP implementations like Shibboleth IdP 5 or CAS SAML IdP 7 (Java 17 and Spring 6 baseline) need OpenSAML 5, but Spring Security SAML is not compatiable with OpenSAML 5, so it don't work. We truely encountered this problem now.
Comment From: marcusdacoregio
Spring Security has a lot of tests and samples that assert that it works with OpenSAML 4. You may be using other components of OpenSAML that tie you to the javax.servlet package. Spring Security doesn't use any of those components. If you encounter any issues related to that, please put together a sample and file a separate ticket so we can take a look at that.
Comment From: GDeen
We are indeed using other components of OpenSAML that tie us to the javax.servlet package. I do believe that this is a nuisance for many using OpenSAML though, because if in your application you wish to decode a SAML message using OpenSAML, then you may want to use org.opensaml.messaging.decoder.servlet.AbstractHttpServletRequestMessageDecoder or org.opensaml.messaging.decoder.servlet.BaseHttpServletRequestXMLMessageDecoder
However, these expect javax.servlet.http.HttpServletRequest.
As of Spring boot 3, we need to use Jakarta EE over javax.servlet, see https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide#jakarta-ee
We will, like others suggested, use OpenSAML 5.0 to tackle the issue (and hope/verify that it still works with Spring Security), but it would of course be nicer if OpenSAML 5.0 was supported by Spring Security.
Comment From: leshalv
Are there any updates planned at the moment? @marcusdacoregio
Comment From: OrangeDog
OpenSAML doesn't generally have release notes. The "changelog" for 5.0.0 is here but has no indication of what might be breaking.
I think you just have to email dev@shibboleth.net and ask. I already checked its (and announce@'s) archives.
Comment From: marcusdacoregio
Hi, @leshalv. There is no updates yet. I am not sure if we will update to a major version during a minor Spring Security version, we must see what it takes to do the update and if it will be transparent for users.
Comment From: OrangeDog
I had a look at compiling with 5.1.2:
The dependency opensaml-core is now split into -api and -impl.
Most of net.shibboleth.utilities.java.support has been moved to net.shibboleth.shared.
Apache httpclient has been upgraded to httpclient5 and is using the "classic" API.
The Spring configuration/factory beans (which I don't think Spring Security is actually using?) are moved to opensaml-spring.
Comment From: deanmaster
hi @jzheaux does this mean we are support both SAML4 and SAML 5 at the same time depending on the artifacts on the classpath?
Comment From: OrangeDog
@deanmaster https://github.com/spring-projects/spring-security/blob/main/docs/modules/ROOT/pages/servlet/saml2/opensaml.adoc
Comment From: deanmaster
thank you @OrangeDog
Comment From: MichaelVetter
@jzheaux It seems that OpenSAML 4 will be out of support soon: "EOL date for the V4 IdP (and OpenSAML of course) is September 1, 2024." http://shibboleth.net/pipermail/announce/2023-September/000301.html Wouldn't it be better to use OpenSAML 5 by default then? When is a spring security release planned that supports OpenSAML 5?
Comment From: deanmaster
not sure how to understand this message. I hope there is more clear statement that OpenSAML 4 is EOL which is in few days
Comment From: MichaelVetter
@deanmaster It is also mentioned on this page: "The Shibboleth IdP V4 software will leave support on September 1, 2024." https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631499/ReleaseNotes
Comment From: deanmaster
thank you, the biggest problem here is Spring Security 6.4.x does not have the release date yet so even we have OpenSAML v5, we can't use it.
Comment From: deanmaster
hi @jzheaux ,
Is there any chance that we can backport this feature in 6.3.x branch patch ? The main (big) problem for us is about EOL in 1st September and we only have 15% of 6.4.x finished that means integrate with OpenSAMLv5 seems to become unknown timeline. In case security alert happen with OpenSAML we have no chance to react with v4.
Comment From: EugenMayer
@marcusdacoregio i do not think there needs to be an issue. We should follow up on the openSAML releases just to ensure people can use the maintained versions. Surely 4.x will receive updates for some time, maybe a year or more. But the road to 5 should be paved and established before 4 gets EOLed - right?
This was so predictable a year ago ;/
Comment From: OrangeDog
Edit: ! DO NOT USE THIS !. It also pulls in management of Spring components, back to 6.1.11.
~~Although rather than the suggested method, this is probably better:~~
<dependencyManagement>
<dependency>
<groupId>org.opensaml</groupId>
<artifactId>opensaml-bom</artifactId>
<version>${opensaml.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencyManagement>
Comment From: EugenMayer
@deanmaster with spring boot 3.4 spring security 6.4.1 has been released - this should prepare the compatibility for opensaml 5.x i assume
Comment From: deanmaster
thanks @EugenMayer I think so too
Comment From: EugenMayer
I tried the integration with sb 3.4.0 and the upgrade is fairly straight forward and for us, everything is working
Comment From: deanmaster
absolutely great @EugenMayer I tried with beta before it's fine. I will do with 6.4.1 soon.