I am using the OpenSAML Java library to process the SAML token that comes from an IDP. The OpenSAML library is using a dependent library bcprov-jdk15xxx.jar which is non FIPS compliant. My requirement is to use FIPS compliant libraries in my application. Is there a way to make OpenSAML FIPS compliant? I found one bc-fips-1.0.0.jar, but its not working.
Thanks, Mounika
You can register any JCE provider, like bouncy castle and OpenSAML will use it. Also give a higher priority to JCE lib. Can you provide the sample code you are using?
Related
What is the difference between spring-security-oauth2 and spring-security-oauth2-core in spring?
Is spring-security-oauth2 substituted by spring-security-oauth2-core?
spring-security-oauth2 release link :
http://repo.spring.io/release/org/springframework/security/oauth/spring-security-oauth2/
spring-security-oauth2-core release link
http://repo.spring.io/release/org/springframework/security/spring-security-oauth2-core/
Yes there is a big difference. spring-security-oauth2 (Spring Security OAuth Project) is no longer being actively developed.
Moving forward, it will be implemented in Spring Security 5 (in spring-security-oauth2-core). It's pretty confusing because many tutorials use the previous Spring Security OAuth (#EnableResourceServer, #EnableAuthorizationServer, and #EnableOAuth2Sso annotations usually give it away).
The first link is related to Spring 4 and it's matching Spring Security versions. You can verify this in the pom.xml files.
The second link is related to Spring 5 and Spring Security 5. Not only is this directly apparent from the version you see mentioned in that link but you can find the dependency directly named in the Spring Security 5 documentation.
The difference is described in the spring git repository
https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide
it is the old library: security/oauth/spring-security-oauth2/
As you see, the library is in the 'oauth' group of spring-security.
I don't recommend using the old library as a client because there are many unresolved issues including the issue about the storing of clientContext (the library use proxy instead of the plain entity for that reason you will have issues when you use MA with distributed cache ). Also, it doesn't allow to use several OAuth2.0 providers simultaneously (only one).
At the same time, that library provides a significant advantage, to use Authorization Server that doesn't implement in the new library.
I have a RESTful web service application in java deployed on google app-engine which uses jersey 1.18.6.
I want to use postmark java client to send transactional emails from it.
When I integrated it, i was seeing the following exception:
javax.ws.rs.core.Response$Status$Family.familyOf(I)Ljavax/ws/rs/core/Response$Status$Family
From what I could find, I think this error was because of there were two different (and probably incompatible) version of jersey being used ,1.18.6 for jersey-server, jersey-guice and jersey-bundle and 2.25.1 for jersey-client (by postmark).
Then I tried to make the jersey version 1.18,6 throughout, so in the my main project pom, while including the dependency for postmark, I excluded the jersey-client (by added exclusions header) and separately added jersey-client dependency in my main project .
But then I got the following error:
java.lang.NoClassDefFoundError: javax/ws/rs/core/MultivaluedHashMap
This is I think the class MultivaluedHashMap is present only in jax-rs 2.x versions (which is compatible with jersey 2.x versions)
So my questions are:
Is there a version of postmark java client library which uses jersey 1.x instead of jersey 2.x?
If no then what options do I have other than migrating my main project from jersey 1.x to jersey 2.x. I don't want to do that since we will have to migrate not just the jersey dependencies but I think some other things like guice, shiro etc. which would be time consuming. Also it doesn't really seem optimal to modify multiple existing dependencies just to include one additional module.
There isn't. The very first commit of the project's pom.xml already used Jersey 2.25.1
as Mureinik mentioned above, when we worked on the library, our plan at Postmark was to use newer library versions, since they are better options in long run.
On our Github page Rupert made good suggestions, from which I find separate ClassLoader a good choice. I will play a bit with the library code in next couple of days on compatibility, however we are always in favour of using newer libraries for our codebase.
please check out my latest comment on Github issues page for possible solution for using older Jersey version https://github.com/wildbit/postmark-java/issues/11
It should be pretty easy to port the library to Jersey 1.x by porting only the HttpClient class on your side.
I am trying to make sure I am using spring-boot and Jackson in a safe way. There is a deserialization bug in some versions of Jackson (source: https://github.com/FasterXML/jackson-databind/issues/1599).
By default Spring Security does not perform deserialization using Jackson, so this is an explicit choice of the user (source: https://pivotal.io/security/cve-2017-4995).
If Jackson is used to perform deserialization, versions 2.7, 2.8, 2.8.9 and 2.7.9.1, as well as 2.9.0.pr3 are patched (source: see cowtowncoder commented on Apr 13, https://github.com/FasterXML/jackson-databind/issues/1599) and not vulnerable to the bug.
Is it safe, then to perform deserialization using the version of Jackson that is part of spring, spring-boot, or Spring Security?
Every version of SpringBoot uses a vulnerable version of the Jackson API, since there really is no version that is not at least partially suceptable to attack. It can happen if you allow untrusted and third party data to be de-serialized into generic collections(Map<>, List<>. etc). Even if you are adding generics to these structures in you code, those generics are compile time only, and cannot enforce typing in the JVM runtime.
If you are accessing an external restful api, then you will have to implement your own typing. If you are using RestTemplate, this will have to be manually set on the object mapper it uses.
FYI: SpringBoot also uses a vulnerable version of logback. Just update to the latest version by explicitly including it in your build.
I'm writing a web application and wanted to ask if it is possible to use Atmosphere Framework without using Jersey. Do equivalent annotations of e.g. #Produces exist in Atmosphere?
Yes you can use the #ManagedService annotation provided out of the box by the framework: https://github.com/Atmosphere/atmosphere/wiki/Getting-Started-with-the-ManagedService-Annotation
Does Jersey got any extensions to support frameworks like Shiro, Guice for example? Or do you use them seperately, independent from jersey?
How does it look for other JAX-RS frameworks. Restlet, RestEasy - do they provide any extensions or is it done seperately as well?
I already know that they got their own implementation of OAuth instead of cooperating with other OAuth framworks.
Regarding Restlet Framework, we offer an extensive set of extensions summarized here. It is however generally easy to do your own integration with other libraries. Regarding Guice, there is already an extension in the Restlet Incubator, see specifications here.
The dependency page of the Jersey docs specifies there are extensions for Guice:
Jersey's runtime dependences are categorized into the following:
Core server. The minimum set of dependences that Jersey requires for
the server.
Core client. The minimum set of dependences that Jersey requires for
the client.
Container. The set of container dependences. Each container provider
has it's own set of dependences.
Entity. The set of entity dependencies. Each entity provider has it's
own set of dependences.
Tools. The set of dependencies required for runtime tooling.
Spring. The set of dependencies required for Spring.
Guice. The set of dependencies required for Guice.
I have not tried integrating Jersey, Guice, and Shiro, but I don't see why you couldn't do it.