Refer to Running the client with SSL/TLS. This explains a scenario where server does a client authentication. I am using Spring Integration to process TLS connections. My spring-context file is:
<bean id="sslContextSupport"
class="org.springframework.integration.ip.tcp.connection.DefaultTcpSSLContextSupport">
<constructor-arg value="file:keystore.jks"/>
<constructor-arg value="file:truststore.jks"/>
<constructor-arg value="keystorepass"/>
<constructor-arg value="trustpass"/>
</bean>
<int-ip:tcp-connection-factory id="crLfServer"
type="server"
port="${availableServerSocket}"
single-use="true"
so-timeout="10000"
using-nio="false"
ssl-context-support="sslContextSupport" />
My Server is accepting SSL connections and processing with certificates installed on my server and client.
I am not sure whether the above spring configuration is setup for client authentication or not. is the client authentication done at the SSL transaport level or in the Application code?
The Spring Integration DefaultTcpSSLContextSupport is fully based on the SSLContext sslContext = SSLContext.getInstance(protocol);. So, what you see in the standard Java SSL/TLS documentation is applied here as well.
Since that your <int-ip:tcp-connection-factory> produces type="server", that is definitely the case of
the server does client authentication
All the hard SSL work is done in the SSLContext layer, not in the TcpNetServerConnectionFactory, if that is the question.
In other words: it doesn't matter that it is Spring Integration or not. Everything works the same way as in any other Java application which users standard SSL/TLS approach.
Related
In one of the projects I worked on the architect used Spring WebserviceTemplate in most of the backend services and its definition in xml config is like:
<bean id="someservice" class="org.springframework.ws.client.core.WebServiceTemplate">
<property name="messageSender">
<bean class="JmsMessageSender">
....
In this configuration, the JmsMessageSender (org.springframework.ws.transport.jms.JmsMessageSender) extends WebserviceMessageSender and its underlying infrastructure is Solace the message broker.
As I understand that the webservice is for synchronous communication, the above should be using the JMS request/response model only - there is no way to use Spring's WebserviceTemplate for JMS's asynchronous model.
Is it correct? However if we start a new project for a similar purpose, wouldn't it be better to use the more simple and elegant RestfulTemplate+Json+Jackson, as opposed to SOAP+JAXB solution as above?
I am using Spring, Spring Security, CAS login and Maven in my web application.
At the time of CAS (central authentication service) login I need service URL in config file.
Can I get server URL or base URL of my application in Spring Security XML config file without hard code on any other place?
If I understand the Spring Security Reference right, you have to write the URL into the configuration:
<bean id="serviceProperties" class="org.springframework.security.cas.ServiceProperties">
<property name="service" value="https://localhost:8443/cas-sample/j_spring_cas_security_check"/>
<property name="sendRenew" value="false"/>
</bean>
If I understand ServiceProperties#getService right, it don't support relativ URLs.
Represents the service the user is authenticating to.
This service is the callback URL belonging to the local Spring Security System for Spring secured application. For example,
https://www.mycompany.com/application/login/cas
In general, you don't know the URL until you get a request, see ServletRequest#getLocalName:
Returns the host name of the Internet Protocol (IP) interface on which the request was received.
I have a .net 4.0 web app which needs to connect to a customer's web service, written in Java (it has cxf in the service endpoint)
Their service endpoint is https, and ultimately I will need to supply an x509 credential, but not yet.
They do not allow discovery, they dont expose a mex endpoint, they have supplied us with a wsdl and xsds, and I've managed to create a client proxy.
I'm struggling to set the right wcf client configuration. What I have so far is this: (names changed for obvious reasons).
<system.serviceModel>
<bindings>
<basicHttpsBinding>
<binding name="CUSwsBinding" />
</basicHttpsBinding>
</bindings>
<client>
<endpoint address="https://customer.com/cxf/customerMaintenance/"
binding="basicHttpsBinding" bindingConfiguration="CUSwsBinding"
contract="CUSCustomer.Customerxxx" name="CUSCustomerWS" />
</client>
</system.serviceModel>
When I try and execute, it says the basicHttpBinding extension is not recognised. I see there are some bindings that only are supported in .net 4.5, however my manager has Fear, Uncertainty and Doubt, and our web app has to stay on 4.0
Not an expert in WCF, so any help welcome.
As someone suggested, one can create an instance of the proxy class:
var client = new proxy.ClientClass();
At this line it throws a Configuration binding extension 'system.serviceModel/bindings/basicHttpsBinding' could not be found.
The endpointaddress needs to be in config, as its currently pointing at a test environment, will be poiting at production
I have a REST service I've set up using OSGI (running in Karaf).
<jaxrs:server address="http://localhost:9001/rest" id="myFileService" >
<jaxrs:serviceBeans>
<ref component-id="FileServicesImpl" />
</jaxrs:serviceBeans>
</jaxrs:server>
When I browse to http://localhost:8181/cxf, if lists my services, and I can successfully connect to my service at http://localhost:9001/rest . If I go to http://MyMachineName:8181/cxf, I get the service list, but if I go to http://MyMachineName:9001/rest the address is not found.
For what it's worth, when I browse to the /cxf link using MyMachineName, it still lists the endpoint as localhost.
Is there a way to configure the endpoint address in the blueprint config so that it responds the both localhost and the machine name? Or to just specific the port? Or do I have to hardcode the machine name or incorporate it into a config file and force it to the machine name?
You have two options here. The first is using http://0.0.0.0:9001/rest as url. This will tell cxf to bind to all ip adresses the server has.
The other option which I prefer is to just user /rest as url. In this case cxf will bind to the OSGi http service which is implemented by pax web in karaf. So you can setup the port and eventually https settings on the pax web level.
I have a question about Spring Security HTTPS redirect strategy.
First of all, the configuration:
Spring 3 Java Web App
tomcat after apache connected with jk
Spring Security 3
Using a configuration where the client connects directly to tomcat (i.e. no jk), I see that the https is managed using secure port redirect by configuring the security.xml file as follows:
<http>
<intercept-url pattern="/secure/**" access="ROLE_USER" requires-channel="https"/>
...
</http>
now, here's the question: using tomcat after apache (with jk) the secured section is on a different host so that I have the following
http (not secured host): www.myhost.com
https (secured host): ssl.myhost.com
I'd like to know if is it possible to configure spring security to redirect to the secured host in case of https is required.
I see that there's a port-mapping configuration availbale, but I don't see something similar for the host.
<http>
...
<port-mappings>
<port-mapping http="9080" https="9443"/>
</port-mappings>
</http>
Thanks in advance.
PS. the twofold hosts configuration is imposed by the hosting service.
The implementation of the default behavior is a simple redirection to the same URI with https prefix, which is done in RetryWithHttpsEntryPoint invoked by the SecureChannelProcessor. You could easily implement the desired behavior by writing your custom AbstractRetryEntryPoint that not only changes the protocol, but also the host name.
Once you've implemented that class, configure the ChannelProcessingFilter with it, based on the sample given in its javadoc: http://static.springsource.org/spring-security/site/docs/3.1.3/apidocs/org/springframework/security/web/access/channel/ChannelProcessingFilter.html