OpenSAML dependency is resolved from a 3rd party repository

[bclozel]

As of #10556, support for OpenSAML 3 has been removed.

Spring Boot is currently upgrading to Spring Security SNAPSHOTs and ran into a dependency resolution problem; Spring Security depends on org.opensaml:opensaml-core:4.1.1 but this version is not available on Maven Central. This dependency seems to be resolved on purpose from a 3rd party repository, https://build.shibboleth.net/nexus/content/repositories/releases/ (see d39f737).

All dependencies resolved by the Spring Boot build are constrained to Maven Central. We understand that this dependency is not published on Maven Central and there's probably a particular reason for that.

There are several ways to resolve this issue:

1. Spring Boot can selectively use that 3rd party repository, constraining it for the org.opensalm groupId and only in selected places. Is the Spring Security build ensuring that only this dependency is being resolved from the shibboleth repository? This outcome would not help users to upgrade as we can't declare an artifact repository for them.
2. Spring Security can downgrade to 4.0.1 and still remain compatible with 4.1.1; compatibility testing was performed already with 3.x so this could be a good middle ground where users would get a recent versions (a year old or so) without declaring a 3rd party dependency. This would make the upgrade experience easier.

[rwinch]

Spring Security should use the latest version of OpenSAML and bring it in by default, so it would seem that 1 would be the best option.

Shibboleth has documented their thoughts on Maven Central here https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/1123844333/Use+of+Maven+Central#Publishing-to-Maven-Central

[wilkinsona]

From the Shibboleth wiki:

However, Maven Central does require that all the dependencies of an artifact also be in Maven Central and that is currently not the case for some of the Shibboleth products. So, for now, the Shibboleth product artifacts will not be published to Maven Central.

If this is true, Spring Security will be unable to publish its spring-security-saml2-service-provider to Maven Central. However, Maven's documentation would suggest that the Shibboleth team are incorrect:

we do strongly encourage making sure all your dependencies are included in the Central Repository. If you rely on sketchy repositories that have junk in them or disappear, it just creates havok for downstream users. Try to keep your dependencies among reliable repos like Central, Jboss, etc.

Whether the Shibboleth repository is sketchy or reliable is obviously subjective. I think it could be argued that we won't be aligning with the spirit of the Maven team's guidelines by publishing something to Central that depends on artifacts that are only available elsewhere.

[stefanos-kalantzis]

any news here? why do we need to add a custom repo to use spring-security?

In maven world there's no good support for limiting/configuring which artifacts can be downloaded from which repo.

[ph33rtehgd]

I'm surprised there's been no comment on this. I understand that Spring does not control where the Shibboleth publishes their aritfacts, but having to add a new maven repository is disruptive in a corporate environment.

[flozano]

what's the alternative? it's not like there are a ton of SAML implementations in Java...

[ph33rtehgd]

what's the alternative? it's not like there are a ton of SAML implementations in Java...

Not sure, I'm not a SAML library expert. If that's the case and the issue isn't going to be fixed they could at least put out of a statement on it and close the issue. With the issue open it makes it seem like we're waiting for them to provide an update/fix to the issue.

[SpiReCZ]

Life has led me back into this topic. Hope something will be done with it.

[rwinch]

OpenSAML is the best Java based SAML library & will remain the implementation for Spring Security. It isn't in anyone's best interest to use older versions of jars, so we will continue to rely on the latest version of OpenSAML.

Those that wish to have OpenSAML published in Maven Central need to discuss it with the OpenSAML team because the Spring Security team has no control over this.

Users requiring SAML support will need to include the Shibboleth Maven repository. I have created gh-14286 to document this requirement.

[SpiReCZ]

I described my dissapointment in here: #14286

[wilkinsona]

Wouldn't status: declined be a more appropriate resolution? In my opinion, it's perfectly valid to wish that all of a project's dependencies were in Maven Central.

Those that wish to have OpenSAML published in Maven Central need to discuss it with the OpenSAML team because the Spring Security team has no control over this.

Given Spring Security's prominence, I think any request that comes from the Security team has the best chance of succeeding. I think it's also in the interests of the Spring Security project to have all of its dependencies in Maven Central as it makes the SAML support easier to use.

[dafriz]

An observation - OpenSAML 4.3.1 is on the JBoss Public repo and not on Shibboleth https://mvnrepository.com/artifact/org.opensaml/opensaml-core/4.3.1
https://mvnrepository.com/artifact/org.opensaml/opensaml-core?repo=shibboleth-releases

[wilkinsona]

As is often that case, that's a reflection upon how up-to-date the mvnrepository.com index is and not the availability of the artifact. As you can see from https://build.shibboleth.net/maven/releases/org/opensaml/opensaml-core/4.3.1/, OpenSAML continues to be available from the https://build.shibboleth.net/maven/releases repository.