I want to set httpOnly on a NewCookie created by Jersey.
I am using the following library for Jersey:
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-core</artifactId>
<version>1.19.4</version>
</dependency>
This uses javax.ws.rs:jsr311-api:1.1.1 which doesn't seem to support httpOnly in NewCookie.
Which Jersey library should I use with Tomcat if I want to have a httpOnly cookie?
You need to use JAX-RS/Jersey 2.x For that, use the following dependency
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.32</version>
</dependency>
If you need support for JSON/POJO mapping, add the following
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-jackson</artifactId>
<version>2.32</version>
</dependency>
You should also remove any dependencies you currently are using that are for Jersey 1.x. Leaving them may cause some conflict and cause your app to not work. If you find out you need any other features for Jersey that require other jars, make sure you use the same version.
Note: If for any reason, you must stick with using Jersey 1.x, a cookie is sent simply by sending a Set-Cookie response header. When the browser sends it back to the server, is in the form of a Cookie request header. So you could use cookies without needing the actual NewCookie and Cookie classes that JAX-RS 2.x offers by simple working with headers. See Using HTTP cookies.
Related
I’m learning how Spring Cloud works and using one of most popular technical stacks for it: Eureka, Zuul, Hystrix, Ribbon, Feign. Except of registry, config server and gateway my services have the following dependencies with Spring Cloud version 2.2.1.RELEASE:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
<version>${spring-cloud.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
<version>${spring-cloud.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
<version>${spring-cloud.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
<version>${spring-cloud.version}</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
<version>${spring-cloud.version}</version>
</dependency>
I do authorization with JWT on gateway and want to use the same Authorization object on other services. Obvious way for doing it is to transfer my JWT with a header but I’ve read in docs that Hystrix can propagate the whole security context with just one property hystrix.shareSecurityContext=true. I’ve tried to do it with Feign Client and Zuul, but SecurityContext on requested service contains just anonymousUser.
I spent two days for understanding how it works but I didn’t. In logs of Feign I don’t see any headers with something like Principal.
So here is my question: is it possible to transfer security context with Zuul and Feign if second service runs in other docker container or on other server? If not what is the best praxis for transferring data about authorized user?
Thanks!
It has been 8 months since you posted the question but I will answer it anyways.
As you know, services are distributed in nature and so they may not share the JVM or even they may not be developed in java at all. The purpose of JWT token is to secure such distributed services so whatever communication happens between them regarding Security, happens through authorization header only. In authorization header one service passes the JWT Token (bearer only) to other service and that service validates the token , reads information from it, and so on.
The hystrix.shareContext has another purpose however. In Spring when the application context is created, by default it doesn't pass it to Hystrix Thread. To make it available to Hystrix, this property is set to true which essentially changes concurrency strategy of hystrix. So, it is passing Security context to "Hystrix's thread" which is part of the same service and not other service.
Hope this solves your query.
I am developing the backend of an Angular + REST APIs application, the application needs some sort of session management (user is authenticated first using OTP then I need to keep track of any of his subsequent requests) ... I saw two examples for managing session with REST , first is using JWT + OAuth2 which I think is somehow over engineered as OAuth2 is not designed as I understand to be used within the same application (resource and authorization server are both within the same application) ... the other example uses redis and I can't introduce it to my current application ... actually what I need is something simple as storing the session in a static map-like structure that I always refer to (and moreover it would be nice to update the token with every client call to the backend, same like OAuth2 but simpler) ... I also checked the spring boot dependencies concerning sessions, all I found name external resource to be included like
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-jdbc</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-hazelcast</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-mongodb</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-core</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-redis</artifactId>
<version>2.0.2.RELEASE</version>
</dependency>
And I have a restriction not to add any external caching dependency like hazelcast ... also for a jdbc-session management, it will really affect performance to go to database with every client call
I'm using Camel 2.13.3 and trying to establish a connection via AMQP to a remote ActiveMQ instance.
According to the Camel AMQP docs is should be sufficient to add the following dependency
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-amqp</artifactId>
<version>2.13.1</version>
</dependency>
It then indicates that you should configure the jms component to use a connection factory supplied by the QPID project. The docs page uses org.apache.qpid.amqp_1_0.jms.impl.ConnectionFactoryImpl, and the results of other google searches indicate that org.apache.qpid.client.AMQConnectionFactory could be used.
However, the org.apache.qpid dependencies do not appear to have been added to the project and, unsurprisingly, I get a ClassNotFoundException when I run it.
I considered downloading the qpid dependency separately, but their web site seems to indicate that the qpid client project has been deprecated and replaced by something else ( QPID Messaging API if I remember correctly )
Can anyone point me in the right direction?
should be sufficient
The Camel docs you linked to does not state that. It just says this dependency is needed, doesn't say anything about additional dependencies. Just looked inside the jar you're using, and it does not contain qpid-client classes. You should add that dependency to your pom as well. For AMQP 0.x, there is a good chance you'll need JMS spec dependency as well:
<dependency>
<groupId>org.apache.qpid</groupId>
<artifactId>qpid-client</artifactId>
<version>0.32</version> <!-- replace with appropriate version -->
</dependency>
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-jms_1.1_spec</artifactId>
<version>1.0</version>
</dependency>
If you're using AMQP 1.0,
<dependency>
<groupId>org.apache.qpid</groupId>
<artifactId>qpid-jms-client</artifactId>
<version>0.3.0</version>
</dependency>
I'm trying to use Swagger to document my Rest API. I want to make use of #BeanParam annotation, however Swagger interprets the bean model as a single body. I've changed my swagger dependency to swagger-jersey2-jaxrs_2.10 but that made Wildfly unable to start cause of WELD-001408 error (as in first link below). I have read a lot of stuff, but nothing seems to solve my problem:
https://developer.jboss.org/thread/240847
https://github.com/swagger-api/swagger-core/issues/446
https://groups.google.com/forum/#!msg/swagger-swaggersocket/K5TFkxIcRQs/A34nupqPTTcJ
I've tried by changing dependencies in my pom.xml according to linked threads, now it looks like this:
<dependency>
<groupId>com.wordnik</groupId>
<artifactId>swagger-annotations</artifactId>
<version>1.3.12</version>
</dependency>
<dependency>
<groupId>com.wordnik</groupId>
<artifactId>swagger-core_2.10</artifactId>
<version>1.3.12</version>
</dependency>
<dependency>
<groupId>com.wordnik</groupId>
<artifactId>swagger-jersey2-jaxrs_2.10</artifactId>
<version>1.3.12</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers.glassfish</groupId>
<artifactId>jersey-gf-cdi</artifactId>
<version>2.14</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>2.14</version>
</dependency>
Moreover, I have a custom servlet for Swagger:
public class SwaggerServlet extends HttpServlet {
private static final long serialVersionUID = 4104485315753399385L;
#Override
public void init(ServletConfig config) throws ServletException {
super.init(config);
BeanConfig beanConfig = new BeanConfig();
beanConfig.setVersion("1.0.2");
beanConfig.setBasePath("/CityAlertsWeb/service");
beanConfig.setResourcePackage("pl.cityalerts.web.controllers");
beanConfig.setScan(true);
ClassReaders.setReader(new JerseyApiReader());
}
}
Is there any way to make #BeanParam work in Swagger with Resteasy?
Should I add any other dependency?
With such a config I'm getting:
...
Caused by: java.lang.RuntimeException: Unable to instantiate ContextResolver
at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1607)
at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1310)
at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1232)
at org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:531)
at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:338)
at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:241)
at org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap.contextInitialized(ResteasyBootstrap.java:28)
at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:187)
... 7 more
Caused by: java.lang.IllegalArgumentException: Unable to find a public constructor for provider class org.glassfish.jersey.media.multipart.MultiPartProperties$Feature$MultiPartContextResolver
at org.jboss.resteasy.spi.ResteasyProviderFactory.createConstructorInjector(ResteasyProviderFactory.java:2184)
at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2173)
at org.jboss.resteasy.spi.ResteasyProviderFactory.addContextResolver(ResteasyProviderFactory.java:1072)
at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1601)
... 15 more
Thanks
Even though RESTEasy 3.X has been officially released about a year and a half ago, it is still fairly uncommon, at least in our experience.
Swagger-core comes in several flavors, as a Play module, Servlet, and JAX-RS. When it comes to JAX-RS, there's a basic JAX-RS implementation for JAX-RS 1.X and then there are specific implementations for Jersey 1.X and Jersey 2.X.
The Jersey 1.X and 2.X implementations include support for file uploads in those libraries as, unfortunately, file uploads are not part of the JAX-RS specification and end up being implementation-specific.
However, another difference in the Jersey 2.X specific implementation is the support for JAX-RS 2.0, which includes the #BeanParam support. At the moment, there is no general-purpose JAX-RS 2.0 module.
From the original link, it seems there's a conflict between JBoss/WildFly and loading the Jersey dependencies, which the Jersey 2.X flavor pulls in. Based on the interactions in the comments, the solution is to exclude (<exclusion>) the org.glassfish.jersey.media:jersey-media-multipart dependency (which is indeed the one for file upload support) and adding it again manually in the main pom.xml. While not an elegant solution, it works as a workaround.
I would also suggest opening an issue about it in the swagger-core repository. I imagine JAX-RS 2.0 adoption will grow over time and we should give it proper support.
I'm trying to send a request to an existing webservice. This webservice is not governed by me. The security policy of this webservice requires me to send my complete certificate chain in my SOAP request. My certificate chain contains 3 certificates. There are no issues with the setup of the certificate chain, as I'm able to test it's validity (and have done so).
The security configuration for this setup (= sending the complete certificate chain in the request), is:
<xwss:Sign id="signature">
<xwss:X509Token
certificateAlias="alias"
keyReferenceType="Direct"
valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1" />
</xwss:Sign>
I'm trying to achieve this through Spring-WS. Spring-WS uses spring-ws-security for security. Spring-ws-security delegates to xws-security.
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws-security</artifactId>
<version>2.1.0.RELEASE</version>
<exclusions>
<exclusion>
<groupId>org.apache.ws.security</groupId>
<artifactId>wss4j</artifactId>
</exclusion>
<exclusion>
<groupId>com.sun.xml.wsit</groupId>
<artifactId>xws-security</artifactId>
</exclusion>
</exclusions>
</dependency>
Xws-security comes in 2 flavors:
<dependency>
<groupId>com.sun.xml.wsit</groupId>
<artifactId>xws-security</artifactId>
<version>1.3.1</version>
</dependency>
and
<dependency>
<groupId>com.sun.xml.wss</groupId>
<artifactId>xws-security</artifactId>
<version>3.0</version>
</dependency>
The first one is used by Spring WS Security. The second is legacy.
Applying my XWSS configuration in xws-security is done in a class called BinarySecurityToken. BinarySecurityToken has a field called
valueType
The JavaDoc of valueType says it has support for X509PKIPathv1 (among others). However, it does not, as stated by this setter:
protected void setValueType(String valueType) {
if (!(MessageConstants.X509v3_NS.equals(valueType)||MessageConstants.X509v1_NS.equals(valueType))) {
log.log(Level.SEVERE,"WSS0342.valtype.invalid");
throw new RuntimeException("Unsupported value type: " + valueType);
}
this.valueType = valueType;
}
The class MessageConstants does not (even) have a static for X509PKIPathv1. When I run my code, I get the expected result:
Unsupported value type: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1
I was able to look at the source code of the legacy com.sun.xml.wss.xws-security:3.0. Despite my efforts, I have not found the source code of com.sun.xml.wsit.xws-security-1.3.1. However I believe the code is the same. I tried both libraries and both give me the same exception. I tried it, using the default spring-ws-security and using explicit dependency declarations to both libraries (one at a time).
My questions:
Has anyone been able to use xws-security for generating an X509 signature with a valueType of X509PKIPathv1 and a keyReferenceType that is Direct?
Do other xws-security implementations exist that offer this? Or should I look at a completely different approach like Wss4j?
I have considered re-writing BinarySecurityToken, but that would probably also imply rewriting the X509 signing of SignatureProcessor in DSIG.
Interesting problem you got there.
As far as I could tell with my Google-fu, there exists support for #X509PKIPathv1 in some projects (e.g., Oracle's XMLSec or Open SAML), however it is not widespread and even application like Soap UI don't support it for SOAP-WS.
Not only that, but other languages/frameworks have the same lack of support, like Delphi and .NET, IBM JRE.
What you could do, based on this SO and especially this SO is implementing your own WebServiceTemplate / WebServiceMessageSender.
The valueType can be #X509v3, #X509PKIPathv1
That is found here
XWS-SecurityIntro4
Have you tried those values specifically instead of a URL?
This pull request will enable the ability to use X509PKIPathv1.