https://www.kb.cert.org/vuls/id/475445 has just been disclosed.
Is this impacting Spring Security SAML2?
I can't see the XML parser used on Spring Security SAML2 on the list of affected APIs.
Let us know.
I am the Spring Security project lead and I have verified that the exploit does not work against Spring Security SAML with the default settings. This was verified by a colleague as well.
If you change the default settings (set ignoreComments = false), your application becomes vulnerable.
Update: See https://spring.io/blog/2018/03/01/spring-security-saml-and-this-week-s-saml-vulnerability
Related
We are using Spring Security OAuth 2.5.x(now deprecated) and are migrating to Spring security 5.x.x. We are using ConsumerTokenServices.revokeToken method at the moment to revoke an existing token during logout or a manual refresh. How can this be achieved in Spring security 5.x.x? I have looked at the samples in here (https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide) but did not find anything specific to this.
I'm currently working through a spring application which is using stateless session and JWT based mechanism for authentication & authorizations.
A new requirement arrived: using CAS v4.0 SSO solution to replace the authentication system. I went through the CAS documentation and the spring security documentation and saw no sign of "stateless mode". Trying to set the spring security session policy to stateless is breaking my CAS integration.
My intuition would tell me to totally drop the JWT mechanism and switch on classic statefull based sessionid mode to avoid issues. Is there some resource trying to adress a CAS + stateless client? Has someone had experience with it?
I'm in the process of moving my application from Spring Security's CAS client to JASIG's Java CAS client. This was due to our security group adding some custom functionality to the JASIG version.
I've seen on JASIG's website the examples of how to configure the CAS client using Spring's configuration. I've used this example:
https://wiki.jasig.org/display/CASC/Using+the+CAS+Client+3.1+with+Spring+Security
I'm using STS and it complains about numerous lines being incorrect or deprecated. Also, when using the spring security CAS client I configured my roles as part of the <sec:http> block using intercept-url tags like this:
<sec:intercept-url pattern="/api/**" access="hasAnyRole('ROLE_OPERATOR', 'ROLE_ADMINISTRATOR')" method="GET" />
However, in the example the roles are configured in the FilterSecurityInterceptor bean and while it uses the sec:intercept-url tags the expressions don't work.
I believe the issue is that the example is from an earlier version of spring security but I'm using a newer version.
Does anyone know of an updated version of the configuration for the above sample? I know I need to upgrade my config from what the example shows but I'm not a full time security guy, just a developer tasked with doing this move, so I don't live an breath this stuff every day. Any help would be greatly appreciated.
My env:
Spring Source Framework v3.2.2
Spring Security v3.1.4
JASIG CAS Client v3.2.1
-Richard Ward
Spring session seems like a very interesting project but I have not been able to find much information on how to properly incorporate it in a spring security application. The readme on project github page has some information but I dont think thats applicable to spring security. Another example thats mentioned on the same page is to utilize this mechanism for REST access. Thats another use case that i think can benefit from an example. I would appreciate if some information on the subject can be shared. Thanks.
You can use Spring Session with Spring Security by simply ensuring to place the Spring Session Filter before Spring Security's filter. There is also an security sample project that demonstrates the use of Spring Session with Spring Security within the distribution. You can run it by cloning the repository and running the following:
./gradlew :samples:security:tomcatRun
The application will be available at http://localhost:8080/
I need to have certain URLs (actions) in my app where I receive Credit Card information be SSL/https. I'm using the new set of Grails security plugins, i.e. Spring Security Core, and Spring Security UI. These apparently replace the ACEGI security plugin, which I understand had some SSL configuration capabilities at the controller level.
Can you tell me what the current recommendation is for switching to https for certain controllers/actions? Do I need to resolve everything in Tomcat?
Thanks
See section "17 Channel Security" in the Spring Security Core plugin docs: http://grails-plugins.github.com/grails-spring-security-core/docs/manual/