Is the spring-security-saml extension still being developed/maintained? It has very good documentation and codebase but it looks like there is only one maintainer and recently all the activities has decreased. I mean the project looks like in a good shape, but it is based on older Spring releases and OpenSAML dependencies. I found other security frameworks (pac4j) being actively developed/maintained. Trying to determine if I can base a SAML 2.0 SP off the Spring project or i should go with something that is more actively maintained?
I'll most likely find time to update the Spring + OpenSAML dependencies, but cannot commit to a precise date, time is scarce.
Related
We are currently facing a little conundrum with Spring Boot that's actually not a rare situation:
Spring Security OAuth2 Client has a critical vulnerability that our production systems might be vulnerable to; the vulnerability is fixed in the latest patch release of Spring Security. Naturally, we want to update our production systems ASAP, but this means we need to override the Spring Boot (Gradle) dependency management system if we don't want to wait until the next Spring Boot patch release.
I know that this can be done quite easily, in this case e.g. by setting something like this in gradle.properties:
spring-security-oauth2-client.version=5.7.5
The problem with this is that this dependency is now pinned to a specific version; I need to remember to remove this property as soon as a Spring Boot patch release is available. This means extra coordination effort because we need to document this in our backlog, and even with good documentation on our part there is a risk that we forget to do it, which means the dependency will eventually be outdated - which is the exact opposite of what we wanted to achieve in the first place.
What I'd rather do is specify a minimum version of the dependency, that gets ignored if it is older than what the Spring Boot dependency management plugin's default version.
Can this be done? Or is there a better strategy to handle a situation like this?
This is possible using gradle's dynamic versions.
For instance, you can have:
dependencies {
implementation 'org.springframework.security:spring-security-oauth2-client:5.+'
}
But keep in mind that dynamic versions add nondeterminism to your build and can introduce unexpected behaviour changes to the system.
Using dynamic versions in a build bears the risk of potentially
breaking it. As soon as a new version of the dependency is released
that contains an incompatible API change your source code might stop
compiling.
References:
Version ranges in gradle
My company's Sonatype scan shows Spring-Web is vulnerable even for the latest version (currently 5.2.3.RELEASE).
It reads:
"Found security vulnerability CVE-2016-1000027 with severity 9.8".
I noticed CVE-2016-1000027 is added to the NATIONAL VULNERABILITY DATABASE
on 01/02/2020, and it is in regards to
"Spring Framework 4.1.4 suffers from a potential remote code execution
(RCE) issue if used for Java deserialization of untrusted data".
Is this an obsolete ticket or has it not be resolved after 4 years?
This issue is resolved from a Spring Framework point of view, see my latest comment summarizing the situation on that issue. Your application is only vulnerable if you're using HTTPInvokerServiceExporter or RemoteInvocationSerializingExporter and reading data from untrusted sources.
Deserializing Java code from untrusted sources is a well-known problem in Java (so, all Java applications and Frameworks!), and this feature might be removed in future Java versions.
Given the nature of this security problem (there's no way to "fix it" besides removing the classes, which will be done in the next major version of Spring Framework), contacting your vendor or your security team is the best course of action. The Spring team is happy to help the community with this matter by providing more context on that issue if needed.
I was trying to create a new Spring Boot project using start.spring.io. Searching for dependencies, I found that there was no AspectJ starter available. Has this dependency removed/deprecated from Spring Boot starters? Here is a screen shot:
I, however, was able to find the dependency on maven repositories website:
It was removed indeed. #jwenting explained in a nutshell why. This starer is required if you want to create your own aspect or if you want to use some advanced AOP mode.
Most users don't need it and whenever a library requires it, its starter brings it automatically. Having a dedicated entry was confusing as we saw a very large amount of users picking this up for no good reason.
Also, please keep in mind that start.spring.io is not an exhaustive list of what you can do with Spring. We're focusing on the getting started experience only and avoiding cases that could lead to confusion. This one is a good example of the latter.
it's an implicit dependency, meaning you don't have to include it because it's automatically pulled in by anything that needs it.
You can still add it explicitly, but there's no need to (and afaik it's never been needed).
I am working on bringing up a new team in the Spring Boot ecosystem. I love the Spring Initializr service. We have written custom Gradle plugins for unifying our build systems across many Spring Boot projects. I am looking to provide our team with an Initializr that will take advantage of our build tooling as well as inject some of our business practices into the scaffolding of the project.
With these goals in mind we have decided that extending the wonderful Spring Initializr and running a custom instance locally makes a lot of sense.
Unfortunately, it appears that the Initializr project has very little documentation about customizing it, beyond the basics of editing the YAML configuration and the Templates for the java files, it is difficult (for someone with no Groovy Templating experience) to figure out how to best extend the Initializr such that we maintain much of the functionality but can also extend the site and service appropriately.
We have built the github project from source, and published the artifacts to our local artifactory, and have successfully created our own project that uses those artifacts as a dependency and stands up a mildly customized service (basic HTML and Java source editing, simple YAML configuration).
Can anyone help with even basic resources for extending the functionality of the Initializr? perhaps a roadmap? a project specific forum? really any help is appreciated, my google-foo seems to be failing me.
I know this is a reasonably broad question, but I am failing to get in touch with the right people, or find the resources for this.
So the answer is indeed Gitter. Spring Initializr should be seen at the moment as a service and not a library. We do our best to make sure things are nicely separated but that's not the case yet for everything (read: designed for extension).
We have some plans to allow external components to customize how the project is generated. It would help if you could share your use cases on the gitter channel. Thanks!
Does anyone know what the state is of the Spring Integration Extensions at https://github.com/spring-projects/spring-integration-extensions ?
Some seem outdated with regards to Spring versions. And others, whilst updated, don't seem to have recent releases or snapshots available at http://repo.spring.io/libs-snapshot/org/springframework/integration/ .
For example I wanted to integrate with AWS, but cant find a release or snapshot for the latest version of Spring Integration. And SQS support has been "coming soon" for some time.
The outdatedness of those that do exist, and lack of clarity on what is intended, make me concerned to use any of them. Does anyone know what the Spring team's intention is with regards to the release cycle of these extensions? Are they viewed as incubators that will eventually move into Spring Integration core, or something else?
Cheers,
Menno
Spring Integration extensions are community provided, and they will constantly change according to the will of the community. Your best chance is to get in touch with the contributors of the AWS extension.
You should use them, once you understand what they are doing, there are no more guarantees than other Spring projects, only the fact that others are also using it.