We Keep Coding

Set Proxy Username and Password in java code

I develop a code to access a SOAP-Server via proxy and regarding to the description here I can set a global Proxy. Although my question seems Naive but I have not find any guide how to set Username and Password for this proxy setting in my java code?

you can at runtime get the System's properties and set all what you need to configurate the proxy...
Example:
System.getProperties().put("http.proxyHost", "myProxyURL");
System.getProperties().put("http.proxyPort", "myProxyPort");
System.getProperties().put("http.proxyUser", "myUserName");
System.getProperties().put("http.proxyPassword", "myPassword");

After some days I found the solution in my case and I try to explain it here.
It is important to know which kind of SOAP Client service you have wrote. In my case I used CXF 3.1.7 to generate Java code. To be more explicit I had a WSDL file and Generated the code via wsdl2java plugin in maven with the mentioned version.
In the level of the WebService the follwoing can be done in code to enter the proxy Setting
private void setProxySetting(EventPortType port) {
try{
Client client = ClientProxy.getClient(port);
HTTPConduit http = (HTTPConduit) client.getConduit();
http.getClient().setProxyServer("***host***");
http.getClient().setProxyServerPort(80);
http.getProxyAuthorization().setUserName("***username***");
http.getProxyAuthorization().setPassword("***password***");
}catch (Exception e) {
logger.error("Please Enter your proxy setting in MyClass class", e);
}
}
The port is comming from the Service Level that I got like this
EventService es = new EventService();
EventPortType port = es.getEventPort();
setProxySetting();

Java Web service client can't connect to BPEL webservice when SoapUI can

I am experiencing the following error and after extensive research on the matter with a few similar issues, none seem to help.
My error:
com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.net.ConnectException: Connection refused: connect
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:121)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:142)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:83)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:211)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:124)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
at com.sun.proxy.$Proxy33.onboardPerson(Unknown Source)
at com.paychex.corp.fileloader.FileloaderMain.callWebService(FileloaderMain.java:202)
at com.paychex.corp.fileloader.FileloaderMain.main(FileloaderMain.java:104)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:411)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:525)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:208)
at sun.net.www.http.HttpClient.New(HttpClient.java:291)
at sun.net.www.http.HttpClient.New(HttpClient.java:310)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:987)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:966)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1031)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:109)
My client is generated from wsimport using the WSDL file that IS visible from the active service. Code connection sample: URL and service name, etc are correct, can't list for security
URL url = new URL("http://correctserviceurl?WSDL");
QName qname = new QName("http://correct servicelocation","nameofService");
CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService(url, qname);
//CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService();
CorporateEmployeeOnboardingProcess process = service.getICorporateEmployeeOnboardingProcess();
OnboardRequestType onboardRequest = new OnboardRequestType();
/**
* TESTING SECTION FOR PROCESS CALL
*/
//create necessary complex types:
GregorianCalendar gregorianCalendar = new GregorianCalendar();
DatatypeFactory datatypeFactory;
datatypeFactory = DatatypeFactory.newInstance();
XMLGregorianCalendar testDate =
datatypeFactory.newXMLGregorianCalendar(gregorianCalendar);
testDate.setYear(1991);
testDate.setMonth(4);
testDate.setDay(3);
AssignmentComplexType testAssignment = new AssignmentComplexType();
testAssignment.setHiringManagerID("123445");
//set person to send
person.setSSN("333-33-3333");
person.setFirstName("testFname");
person.setLastName("testLname");
person.setDOB(testDate);
person.setHireDate(testDate);
person.setAssignment(testAssignment);
/**
* end testing section of the person creation
*/
onboardRequest.getPerson().add(person);//add a person to the array of people for the request
ServiceResponse response = process.onboardPerson(onboardRequest);
As stated SoapUI can send this same test information and get a perfectly valid request from the service. All information the same. I have been digging around for awhile and confirmed that there is no proxy, both are same bit (32/64 in this case both 32), service name and WSDL are correct and objects are named properly, etc. I did further debugging trying to get around this awful error code that has seemingly no usable information and using wireshark compared the SoapUI request to the java request to find that SoapUI was using POST and the java client was using GET which has me leaning on this right now as the source of the generic refused connection error.
The service is using BPEL to run and was created using BPEL so all code was basically generated. I will be looking at the Get/post find as of now but wanted to get this out there as I am doubtful it could be the cause.
Any help is greatly appreciated. Let me know if I forgot any key information I might be able to share.
EDIT
I wanted to add that I am able to access the endpoint URL in the web browser from the machine that I am using to try and connect to the BPEL service. It seems the issue is solely with the client generated from the WSDL stubs I got using wsimport for the service's WSDL.
Edit 2: Development/Progress
The issue seems to be that the client is sending the response to local host even after setting up the qname to the correct address. I am now trying to figure out where this local host is being set. Any ideas on this development would be greatly appreciated.

It's been a while, but I believe this line: URL url = new URL("http://correctserviceurl?WSDL");
Needs to read: URL url = new URL("http://correctserviceurl");

K! This one was an issue with BPEL I believe. Quite frustrating. Apparently after initializing the service in the following lines:
URL url = new URL("http://serviceaddresshere?WSDL");
QName qname = new QName("http://servicelocationaddress","NameOfService");
CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService(url, qname);
CorporateEmployeeOnboardingProcess process = service.getICorporateEmployeeOnboardingProcess();
BPEL gets the request with the service WSDL and the CORRECT address. However, BPEL seems to think "O? you want this service, here you go I'll give you that, only the WSDL you want is wrapper, so here's the REAL WSDL." In plain english, you get back the BPEL WSDL that it thinks is for the service, and this has the Localhost address in it. Now I tried changing the address in this WSDL but BPEL through errors up the wazzoo. So the work around was adding in this line after the process variable is make: (AKA THE FIX)
((BindingProvider) process).getRequestContext().put(Dispatch.ENDPOINT_ADDRESS_PROPERTY, "http://the serviceaddress");
Bassically you set the endpoint AGAIN after you make the process, because BPEL overwrites what you sent it the first time. This is of course a sort of work around, but the process now works good. If you can think of a way to bypass this work around and dynamically fix the service so we don't have to keep changing the service WSDL when we move ti to new enviornments like Dev, etc. I am all ears. Thanks and as always I will read comments for suggestions. =)

You can use bpel configuration plans to switch between environments.
Configuration plans are the recommended option to use for making composites environment specific.
Efficient use of configuration plans can greatly reduce the work required per process.
A configuration plan can be generated from the composite.xml file.
Please consider this link:
http://biemond.blogspot.com.br/2010/02/web-service-references-and-soa.html

How do I specify url in JAX-WS call and avoid initial network connection?

I'm using JAX-WS standard stuff with wsimport http://localhost/Order.wsdl to generate client stub classes.
The live web service is on a different host, so I need to supply a url when I make the service call. My approach so far has been like this (classes below are generated from wsimport):
1. OrderService s = new OrderService (
new URL("https://live/WS/Order"),
new QName(...));
2. OrderServicePort port = s.getOrderServicePort();
3. configureHttpCertificatesStuff(port) // Set up ssl stuff with the port
4. port.placeOrder(args); // The actual ws call
First: Is this the correct way of specifying the url?
Second: It seems the constructor in line 1 actually makes a network call to the new URL! This results in an exception (due to https not being configured), so I never get to the next line.
Background: I am implementing two-way ssl auth as outlined in this question. This means I need to configure ssl stuff in the port before the service call. I can't have the constructor make any connection before I've configured the ssl layer correctly for obvious reasons...
Update:
Apparenty the url is to the WSDL, not the endpoint when using jax-ws standard. This tripped me up. Loading the WSDL directly from file solved that problem.
Setting the endpoint url is done like this:
BindingProvider b = (BindingProvider) port;
b.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpointUrl);

One solution would be to have your build process arrange for the WSDL file processed by wsimport to become a class path resource for your app. There are any number of ways to do this, but lets assume you take a JAR-per-service approach. So, you'd run Order.wsdl through wsimport and take the resulting classes, like OrderService and OrderServicePort, and stuff them into order-service.jar. The other thing you could do would be to stuff a copy of Order.wsdl into that same JAR at META-INF/wsdl/Order.wsdl. Assuming that JAR file is then part of the class path for your app, you can get the WSDL's URL by doing:
URL wsdlLocation = Thread.currentThread().getContextClassLoader().getResource("META-INF/wsdl/Order.wsdl");

"Exception javax.xml.ws.WebServiceException: Unsupported endpoint address" trying to call web service using JAX-WS 2.1

I'm trying to call the web service here: http://publicbetawebservices.hotel.de/V2_8/FreeHotelSearchWebService.svc?WSDL
I've generated proxy classes using wsimport with JDK1.6.0_29. My wsimport command line is:
wsimport.exe" -keep -B-XautoNameResolution -d E:\mapov\mapov-dev\shared\hotel_info\ http://publicbetawebservices.hotel.de/V2_8/FreeHotelSearchWebService.svc?WSDL
I'm using the following code to attempt to call the service:
QName qName = new QName("http://webservices.hotel.de/V2_8", "FreeHotelSearchWebService");
FreeHotelSearchWebService service = new FreeHotelSearchWebService(new URL("http://publicbetawebservices.hotel.de/V2_8/FreeHotelSearchWebService.svc"), qName);
IFreeHotelSearchWebService sws = service.getBasicHttpBindingIFreeHotelSearchWebService();
String version = sws.getWebservicesVersion();
System.out.println("Hotel.info web service version: " + version);
However I get the following exception:
Exception in thread "main" javax.xml.ws.WebServiceException:
Unsupported endpoint address: at
com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:148)
at
com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:134)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641) at
com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600) at
com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585) at
com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482) at
com.sun.xml.ws.client.Stub.process(Stub.java:323) at
com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:161) at
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:113)
at
com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:144) at
$Proxy42.getWebservicesVersion(Unknown Source)
In most examples I've seen the generated code includes a getPort() method but that hasn't been generated for this class. Is my code wrong or do I need to run wsimport differently? I've also tried calling the FreeHotelWebService constructor without the parameters which yields the same exception.

Reanimating an answerless question basing on Justin's and Tug's Blog:
JAX-WS: How to configure the service end point at runtime?
When deploying your Web Service client you often need to change the endpoint of the service that has been set during the code generation. This short post explains how you can set change it at runtime in the client code.
You have two approaches to do that:
set the endpoint in the Port using the BindingProvider;
get the endpoint URL from the WSDL itself at runtime;
Use the Binding Provider to set the endpoint URL
The first approach is to change the BindingProvider.ENDPOINT_ADDRESS_PROPERTY property value of the BindingProvider (Port) using the following code:
try {
EmployeeServiceService service = new EmployeeServiceService();
EmployeeService port = service.getEmployeeServicePort();
BindingProvider bp = (BindingProvider)port;
bp.getRequestContext().put(
BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"http://server1.grallandco.com:8282/HumanRessources/EmployeeServiceService");
Employee emp = port.getEmployee(123);
System.out.println("Result = "+ emp);
} catch (Exception ex) {...
Use the WSDL to get the endpoint URL
Another part is to set the WSDL when you are creating the Service. The service will be using the value that is located in the WSDL port -SOAP Endpoint-. This is simply done using the following code:
try {
EmployeeServiceService service =
new org.demo.service.EmployeeServiceService(
new URL(
"http://server1.grallandco.com:8282/HumanRessources/" +
"EmployeeServiceService?wsdl"),
new QName(
"http://service.demo.org/",
"EmployeeServiceService"));
EmployeeService port = service.getEmployeeServicePort();
Employee emp = port.getEmployee(123);
System.out.println("Result = "+ emp);
} catch (Exception ex) {...}
Note that, in Glassfish, like lot of Web Service environments the WSDL can generate dynamically the Endpoint URL based on the URL used to get the WSDL. With this approach you can also dynamically change the Soap endpoint (if compatible with the network configuration of the production environment.)

Simple Kerberos client in Java?

Applications such a Google's Chrome and IE can transparently handle Kerberos authentication; however I can not find a "simple" Java solution to match this transparency. All of the solutions I have found require the presence of a krb5.conf file and a login.conf file which nether of the above apps seem to require.
What is the best way to build a Java application with Kerberos SSO capabilities that just work?
[update]: to be clear I need a CLIENT side solution for creating tickets not validating them. Also, it seems that SPNEGO is the default "wrapper" protocol that will eventually delegate to Kerberos but I need to be able to handle the SPNEGO protocol as well.

There is now a simple solution for this using the Apache HTTP Components Client 4.5 or greater. This is still marked as experimental in 4.5 so your milage may vary, but this is working fine for me in an enterprise context.
In addition to the HC 4.5 client jars you will need to have the httpclient-win, jna and jna-platform jars on your classpath, as provided with http-component-client. You then construct a Kerberos enabled HC-client as follows:
CloseableHttpClient httpclient = WinHttpClients.createDefault();
Or using the builder:
HttpClientBuilder clientBuilder = WinHttpClients.custom();
Which can then be customised as required before building the client:
CloseableHttpClient client = clientBuilder.build();
This solution works without any external configuration, and most importantly solves the issue where the in-built JRE mechanism breaks for users with local Admin rights on Windows 7+. This is possible because the Kerberos ticket is being retrieved directly from the SSPI API via JNA, rather than going through the GSSAPI provided by the JRE.
Example code from the http-components team
This was all made possible by the good work of Daniel Doubrovkine Timothy Wall
and Ryan McKinley

Adding to David Roussels answer on url specific http based kerberos authentication:-
The reason why your code works is because your target SPN(server side principal) is configured to with HTTP/serverhostname.realm.com#DOMAIN.COM. In that case it will work because you are not explicitly setting the token. URLConnection internally sets a token with that SPN
1 Perform steps(from my previous answer) to get a subject
2 Use gss api init sec context to generate a context token. There are numerous tutorials out there for this step
3 Base 64 encode the token
4 Attach the token to urlconnection:-
URL url = new URL("http://myhost/myapp")
HttpURLConnection urlConn = (HttpURLConnection)url.openConnection(); =
urlConn.setRequestProperty("Authorization", "Negotiate " + encodedToken);
5 Implement a priviledged action:-
//this internally calls the getInputStream
public class PrivilegedGetInputStream implements PrivilegedExceptionAction<InputStream>
6 Wrap the whole thing in Subject.doAs
//use prev answer instructions to get subject
Subject.doAs(subject, new PrivilegedGetInputStream(urlConnection)

Oracle has an example using Java's SaslClient. I'm not a Java programmer, but when I pointed this out once to someone who is, they were able to make it work pretty quickly. It may still require a "conf" file somewhere (n.b. Kerberos uses environment variables, often starting with KRB5_, to know where to look for such files). Also note that Kerberos itself does not include a transport of any kind--your app needs to know how to send and receive the Kerberos payloads the way the server expects (and this is different depending on the server you are trying to authenticate with).
Edit: you edited your question, so here's a link related to SPNEGO in Java which might be of some use:
http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/lab/part5.html

You don't actually need to do anything. In Java 6, on a Windows client machine you can do this:
new URL("http://myhost/myapp").openStream();
And negotiate authentication just works. At least it does for me. And the server I tested on only supports Negotiate, not NTLM auth.

Ok if you want to avoid using a login.conf file you need to code differently:-
//define your own configuration
import javax.security.auth.login.Configuration;
public class CustomLoginConfiguration extends Configuration
//pass certain parameters to its constructor
//define an config entry
import javax.security.auth.login.AppConfigurationEntry;
private AppConfigurationEntry configEntry;
//define a map of params you wish to pass and fill them up
//the map contains entries similar to one you have in login.conf
Map<String, String> params = new HashMap<String, String>();
//define the configuration
configEntry = new AppConfigurationEntry(
"com.sun.security.auth.module.Krb5LoginModule",
AppConfigurationEntry.LoginModuleControlFlag.REQUIRED, params);
//implement getappconfig method
public AppConfigurationEntry[] getAppConfigurationEntry() {
return new AppConfigurationEntry[] { configEntry };
}
Now once you are done with this definition you can use this in you use this to fetch tickets from kdc
//get ticket in login context
LoginContext lc = null;
lc = new LoginContext("lc", null, callback, new CustomLoginConfiguration(argumentlist));
lc.login();
Now from here on you can fetch jaas subject and can basically do a ton of authentication stuff.
In case you need further pointers just leave a comment.

You can use system properties instead of config files to specify the KDC hostname and service name, but those things (at least) are mandatory....
Waffle will actually give you the information you need to set most of the properties, even if it won't get you a ticket. Look at the WindowsAuthProviderImpl class (the Waffle.chm help file shows the API).
I use JAAS do obtain a service ticket from Active Directory in two steps:
Use Krb5LoginModule to retrieve the cached TGT and add it to the Subject.
Use the Subject and GSS-API to retrieve a service ticket from the KDC.
There's a lot of good information and example code at The Java Way of Active Directory.

I created a small tool to simplify connecting with httpclient to kerberos, you might want to give it a try.
https://github.com/DovAmir/httpclientAuthHelper
DefaultHttpClient httpclient = new DefaultHttpClient();
AuthUtils.securityLogging(SecurityLogType.KERBEROS,true);
CredentialsUtils.setKerberosCredentials(client, new UsernamePasswordCredentials("xxx", "xxx"), "domain", "kdc");
client.executeMethod(httpget);

Use WAFFLE

Here's a good blog post on having a java client to use with Kerberos
http://sachithdhanushka.blogspot.com/2014/02/kerberos-java-client-configuration.html