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.