Hi Cris, On Fri, 2021-04-23 at 09:31 -0400, Cris Rockwell wrote: > The OpenSAML library was selected because of the support the Shibboleth > Consortium has within higher education[0]. > My institution is a member of the consortium. I am confident about the > ongoing support the project has and the maintenance > it receives now and in the future. > > When it comes to using the OpenSAML library, it’s necessary to follow > the guidelines about obtaining legitimate versions of the artifacts[1] > That means using library artifacts provided by the Shibboleth > Repository, and not using the OpenSAML artifacts from Maven Central. > > It’s also important to use the library for all parts of the process > when it comes to SAML protocols [2] > This requires providing lots of dependencies, which the library > requires
First of all, I don't see the choice of external libraries as an issue, I am sure that you have chosen well. My only concern is that the recommendation of not having repositories and build repositories defined for artifacts deployed to Maven Central. The official requirements [3] state that: In addition we discourage the usage of <repositories> and <pluginRepositories> and instead publish any required components to the Central Repository. This applies for your own components as well as for 3rd party artifacts. The downsides to using a third party repository are: - if the Shibbboleth Maven repository is retired, our artifacts become invalid - some organisations have strict procurement rules and would require vetting additional repositories In the end, I don't think it's a blocker but we should avoid third party repositories if at all possible. However, I have filed a PR [4] that removes the extra Maven repository and the build still passes. If the repository is not actually needed, the whole discussion is moot :-) Thanks, Robert [3]: https://central.sonatype.org/publish/requirements/ [4]: https://github.com/apache/sling-org-apache-sling-auth-saml2/pull/1
