Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document that Shibboleth Repository is Required for SAML Support #14286

Closed
rwinch opened this issue Dec 12, 2023 · 5 comments
Closed

Document that Shibboleth Repository is Required for SAML Support #14286

rwinch opened this issue Dec 12, 2023 · 5 comments
Assignees
Labels
in: docs An issue in Documentation or samples type: enhancement A general enhancement
Milestone

Comments

@rwinch
Copy link
Member

rwinch commented Dec 12, 2023

We should document that the Shibboleth Maven Repository is required for SAML support. Provide sample configuration for Maven and Gradle based projects with a link to https://shibboleth.atlassian.net/wiki/spaces/DEV/pages/1123844333/Use+of+Maven+Central#Publishing-to-Maven-Central to explain why it is required.

See gh-11966.

@rwinch rwinch added status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement in: docs An issue in Documentation or samples and removed status: waiting-for-triage An issue we've not yet triaged labels Dec 12, 2023
@marcusdacoregio marcusdacoregio self-assigned this Dec 12, 2023
@marcusdacoregio marcusdacoregio added this to the 5.8.9 milestone Dec 13, 2023
@SpiReCZ
Copy link

SpiReCZ commented Dec 13, 2023

I disagree about the issue #11966 being invalid. In the end it's the Spring project that has chosen to add dependency from other repository that breaks the maven central experience. So it's not really an issue of Shibboleth. If something is about to be done with this once and for all, who better to resolve it than someone from Spring. I don't really care if Shibboleth artifacts are added under another namespace or if someone pursues the Maven Central to transfer ownership of the current namespace and we can perhaps release only new version and migrate Spring to it.
But yes, it should be at least documented and perhaps having some runtime checks for wrong dependency since the issue really exists for a long time and you might encounter it by accidentally triggering some parts of the code that are not present in the central version of artifact.

@ph33rtehgd
Copy link

I disagree about the issue #11966 being invalid. In the end it's the Spring project that has chosen to add dependency from other repository that breaks the maven central experience. So it's not really an issue of Shibboleth. If something is about to be done with this once and for all, who better to resolve it than someone from Spring. I don't really care if Shibboleth artifacts are added under another namespace or if someone pursues the Maven Central to transfer ownership of the current namespace and we can perhaps release only new version and migrate Spring to it. But yes, it should be at least documented and perhaps having some runtime checks for wrong dependency since the issue really exists for a long time and you might encounter it by accidentally triggering some parts of the code that are not present in the central version of artifact.

And to your point, Shibboleth does state that they're not opposed to publishing their artifacts to Maven Central in the linked page of this issue. Spring is a pretty large and popular framework, given that maybe it will make them reconsider their stance.

@tomzeller
Copy link

tomzeller commented Feb 2, 2024

From the perspective of the Shibboleth project, the main blocker for publishing / deploying to Maven Central is indemnification :

https://central.sonatype.org/terms.html

Indemnity

You agree to indemnify and hold harmless Sonatype and its affiliates, suppliers, partners, officers, agents, and employees from and against any claim, demand, losses, damages or expenses (including reasonable attorney's fees) arising from your use of Central, your connection to Central, your violation of these Terms of Service or your violation of any rights of any third-party. Your indemnification obligation will survive the termination of these Terms of Service and your use of Central.

Producer Terms

https://central.sonatype.org/publish/producer-terms/#releasing-to-central

Indemnity for Submissions⚓︎
You agree to indemnify and hold harmless Sonatype and its affiliates, suppliers, partners, officers, agents, and employees from and against any claim, demand, losses, damages or expenses (including reasonable attorney's fees) arising from your Submissions.

We've asked for an exception to indemnification but it was not granted.

We would like to publish to Maven Central, but unfortunately do not have a good / legal solution.

@SpiReCZ
Copy link

SpiReCZ commented Feb 3, 2024

From the perspective of the Shibboleth project, the main blocker for publishing / deploying to Maven Central is indemnification :

https://central.sonatype.org/terms.html

Indemnity

You agree to indemnify and hold harmless Sonatype and its affiliates, suppliers, partners, officers, agents, and employees from and against any claim, demand, losses, damages or expenses (including reasonable attorney's fees) arising from your use of Central, your connection to Central, your violation of these Terms of Service or your violation of any rights of any third-party. Your indemnification obligation will survive the termination of these Terms of Service and your use of Central.

Producer Terms

https://central.sonatype.org/publish/producer-terms/#releasing-to-central

Indemnity for Submissions⚓︎
You agree to indemnify and hold harmless Sonatype and its affiliates, suppliers, partners, officers, agents, and employees from and against any claim, demand, losses, damages or expenses (including reasonable attorney's fees) arising from your Submissions.

We've asked for an exception to indemnification but it was not granted.

We would like to publish to Maven Central, but unfortunately do not have a good / legal solution.

This is one of these kinds of things where you cannot help the person or change their mind. It will result in perpetual stale mate where it's us Spring users who lose.

If it was up to me I would say not to use shibboleth implementation as it is pain in the ass dealing with all this. Adding shibboleth repo before central in nexus/artifactory is certainly a solution worth a big security risk. No one cares.. And if you are a company you shouldn't just add it as a repo in your project pom.xml since you use your own server.
Even though central might be flawed, it is how the things are, it won't change and just putting your mind to the wall won't help anyone. Other orgs/companies agree with indemnification why can't you? I tried to deal with this previously and all I see i distaste for central.

@ph33rtehgd
Copy link

I'm just a developer, so maybe the legalese is over my head...but why should Shibboleth need an exemption for indemnification for publishing to Maven Central? Again, I'm not versed in law, but basically what I get from this is you use and publish to Maven Central "at your own risk", and if something bad happens from it you can't hold Sonatype accountable for it. To @SpiReCZ 's point, I don't see this as being a problem for many other companies that publish to central, so I can't understand what makes Shibboleth special.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: docs An issue in Documentation or samples type: enhancement A general enhancement
Projects
Status: No status
Development

No branches or pull requests

5 participants