We're developing a Java SE application that is to be deployed at corporate customer sites. Using http the application needs to access the Internet from time to time and does so using URL.openConnection(java.net.Proxy) which in effect means HttpURLConnection.
We are looking to give the application user the same experience that comes with the major browsers meaning that if the major browsers (IE, Firefox, Chrome) can pass through a given proxy then so should our application.
We are assuming that corporate proxy servers in this day and age use some form of promptless authentication (NTLM, SPNEGO). To this end we end have two concrete questions:
Can HttpURLConnection pass through a proxy that requires NTLMv2 authentication ?. Looking through the JDK source code it seems there's support for NTLM but nowhere can I find any documentation as to what version of NTLM is supported. I've trawled through all release notes since JDK5.
Can HttpURLConnection pass through a proxy that uses SPNEGO-Kerberos authentication ? (without requiring changes to customer's desktops, e.g. forget about registry changes).
The target desktop platform for our application is Windows 7 (or later).
The JVM used is Oracle Java v7 or later.
In general there's no room for making changes to our customer's desktops for the sake of our application. It won't happen if it's a scenario that the major browsers can handle without changes. So we need to assess what Java can do for us. We are using a third-party library for some of the comms and this library in turn uses standard JDK classes (e.g. URL.openConnection()). We are aware that Apache HttpComponents Client (formerly Apache HttpClient) is an alternative and we are willing to rip out this third party library to be able to replace with Apache HttpComponents Client if that solution is truly better in terms of being a able to pass through a proxy.
First one, yes. Custom code from Sun which calls SSPI via JNI will react on NTLM on Windows only.
Second, no. This is a MS resctriction. Unless you code a SSPI JGSS bridge. You maybe could swap the Authenticator for a custom one.
Related
I'm upgrading java xmlrpc from 2.0.1 (org: xmlrpc; module: xmlrpc) to 3.1.3 (org: org.apache.xmlrpc; modules: xmlrpc-client, xmlrpc-server, xmlrpc-commons) in preparation of a migration to JDK 11. Because this project has been split into separate modules for client and server and, I have to fix about three dozen compilation errors. Most of these aren't a big problem. However, I've run into a bit of a roadblock in that there are a number of classes related to secured XMLRPC connections that have been removed in version 3.0:
org.apache.xmlrpc.secure.SecureWebServer; // including setParanoid(boolean), acceptClient(String) and addHandler(string, Handler)
org.apache.xmlrpc.AuthenticatedXmlRpcHandler;
org.apache.xmlrpc.secure.SecureXmlRpcClient; // including setBasicAuthentication(username, password)
We use these in the following ways:
We have a SecureWebServer class that extends from the Apache SecureWebServer, though I don't know if we need this anymore because it appears like the only reason we overrode this was for improved shutdown logic, which seems to be improved already in the 3.1.3 release.
We have a custom Handler class that extends from AuthenticatedXmlRpcHandler. This handler uses a custom ValueProvider for additional logic related to Timestamps and other types that weren't supported in 2.0.1. I don't know if we need this ValueProvider anymore either.
We have a client/server architecture and allow our users to optionally encrypt the communication between the server and the client. Because of this, we have a bunch of logic to configure a SecureXmlRpcClient if necessary.
I've tried to find a migration guide for migrating from 2.X to 3.X versions, and while the Apache site on XMLRPC does contain explanations to some extent, it's not quite the same as a migration guide. Best I can tell, you should now use a config class? It's somewhat confusing, and I'm wondering if it's still necessary to use separate secure and insecure classes.
The above might be more detail than is necessary for the question, which is: How do I handle the removal of separate servers and clients for secure xmlrpc calls in XMLRPC 3.0? Like, do I still need to create separate secure and insecure clients and servers in code, or can everything now use the default XMLRPC server and client with no differentiation between secure and insecure servers and clients?
Like, do I still need to create separate secure and insecure clients
and servers in code, or can everything now use the default XMLRPC
server and client with no differentiation between secure and insecure
servers and clients?
Yes you still need the separate implementations. In 3.x it is up to clients to provide secure set up.
There are couple of ways
On server side you will need to override createServerSocket to substitute for secure SSLServerSocket similar to what 2.x had.
On client side you have initialize with SSLServerSocketFactory on the XmlRpcCommonsTransportFactory to create ssl factory.
Basic Auth can be configured using XmlRpcHttpClientConfig.
Alternatively on server side you could use the full blown servlet container like tomcat or jetty which comes up its own ssl factory.
For client side you can use Httpcient to cover ssl.
You can find some details on how to configure the XmlRpcServlet and client
https://ws.apache.org/xmlrpc/server.html
https://ws.apache.org/xmlrpc/client.html
I feel I should offer some explanation of why I want to implement what seems like a bad solution....
I'm a systems admin, not a java programmer, and have inherited a large and diverse estate of applications running Java 1.7 in Tomcat.
While I am keen to get these all upgraded, this requires the time and cooperation of the development team. My biggest concern (rather topically) is removal of SSLv3, TLS/1.0 and TLS/1.1 from the network. SSL termination for incoming connections is handled by proxy so I can (in principle) stop exposing the vulnerabilities in the services there, however that will break the integration between components running in seperate JVMs and communicating via HTTPS (e.g. CAS authentication).
(yes I could run separate internal/external proxies or use direct addressing bypassing the proxy....but this seems even more of a hack)
Which brings me to my question....
Does BouncyCastle only provide ciphersuites or does it provide TLS?
If I install bouncycastle as a provider will these older java applications be able to make HTTPS client requests using TLS/1.2 or are further code changes required?
BouncyCastle provider will allow you to use ciphers not supported by the jvm. However, depending on your jvm version, the tls 1.2 protocol might not be supported. It appears java 7 should be able to support it.
Either way, to enforce the use of tls1.2, you need further configuration, but not necesserally code changes. You servers must be configured to use it exclusively (configuration may be vendor-specific). Your clients may be configured to use tls1.2 only as well (using -Dhttps.protocols for instance).
See https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https for more information.
I am currently tasked to build some kind of healthcheck-application, which is later to be included in a jboss environment. But first things first. I need to access 3 different types of databases: MS SQL relational, TM1 and MS SQL Analysis Servies. While the first two seem to be manageable, I have encountered a problem trying to access Analysis Services through java. Most commonly, the olap4j library seems to be used, but this is based on the msmdpump.dll, tunneling the response through the IIS. We cannot use this approach, since the IIS is not in use and we do not have system access to the Analysis Services Server.
In short words: How to access Analysis Services in Java without using msmdpump.dll? We need to send simple querys in either MDX or XMLA. Both client and server are using Windows Server 2008 R2. The Analysis Services version is 2008 R2 as well. Analysis Services is provided to us as a service, we do not have access to the system itself.
It seems to be an option to use a powershell script to access Analysis Services and to call this script through java. But I would rather avoid this approach if there is a better option.
Thanks for any help!
I do not think you can avoid the msmdpump.dll in IIS if you want to call Analysis Services from Java.
The Analysis Services server itself uses SOAP structurally but a Microsoft specific binary SOAP format (see http://sqlblog.com/blogs/mosha/archive/2005/12/02/analysis-services-2005-protocol-xmla-over-tcp-ip.aspx for some details). This communication protocol is understood by the ADOMD.NET client driver and msmdpump.dll and nothing else. Thus you can can use write your application in .net or any language capable of interfacing with .net - or you can use any environment on the client that can send and receive http requests via msmdpump.dll hosted in IIS. Actually, msmdpump.dll does nothing else but a translation between TCP using binary compressed XML and http using uncompressed standard XML (and translating between the http authentication mechanisms and integrated security which also can be difficult to implement in Java).
As far as I am aware, Microsoft claims some rights on their binary protocol, so you may even violate their rights in case you would try to develop a tool yourself that directly talks to AS from Java.
Thus the only way to not use msmdpump.dll in IIS as a proxy between you Java application and the AS server would be to develop your own proxy in .net that would more or less implement what msmdpump.dll does already: translate between TCP using binary compressed XML and some other protocol that you define between your .net component and your Java component, probably just exchanging the XMLA request and the XML answer. Or you could implement a more high-level API between ADOMD.NET and your Java application. But there would be no way around some .net development in this case, which I would not think to be worth the effort and complexity.
I am trying to build a web application that will use an LDAP server on an Apache Tomcat 7.0 . Looking over the internet i have not find sufficient articles to justify why use one rather another server.
So I have turned to the more experienced guys here that have sufficient experience with more than one LDAP server.
My requirements are: To be free, easy to install and use (good gui) and sufficient API's so that i will be able to insert users, groups, perform lookups etc from a java based application. It should also provide a good level of security.
Thank you in advance for your attention
I will recommend going with openLDAP as server, UnboundID as LDAP SDK, JXPlorer or ApacheDirectoryStuido as GUI control over the ldap - this covers probably all of your requirements.
All of the above software is free:
openLDAP is probably the widely used LDAP server, if you don't count ActiveDirectory. It's well documented and can be easily supported.
the UnboundID lib is the best I have experience with, and in my opinion - most friendly and feature rich lib for LDAP out there at this moment. Check out this feature comparison matrix.
the UI tools differ in complexity - JXplorer is the simpler one.
There's plenty of LDAP servers around. I am using OpenDJ, that has been developed on the older OpenDS, and I have never had problems on both.
If you like Apache you can use Apache Directory, but perhaps the most famous around is OpenLDAP.
Concerning the API for accessing to the directory using Java, this is not a feature to be looked for in a particular LDAP server implementation, because it's standard in Java SDK: the magic word is JNDI:
JNDI does for LDAP what JDBC does for Oracle -- it provides a standard API for interacting with naming and directory services using a service provider interface (SPI), which is analogous to an JDBC driver
(source: LDAP and JNDI: Together forever, I recommend to check out this excellent tutorial)
On a Windows environment, you can also consider using Lightweight Directory Services, a small and free (as in beer) LDAP server.
Pros:
Installation is pretty straightforward
Multi master replication out of the box
It can chain authentication requests to Active Directory, usign the userProxy or userProxyFull object class.
Administrator accounts can be Windows domain accounts
Cons:
Be prepare to implement password policy yourself. It relies on the effective machine password policy, which might be more strict in a production environment for your administrators than for your users.
Ties that part of your infrastructure to Windows.
I would like to use cookie in my java application. Looking at the Java API it seems there is no support of cookie in java.net package. The only support I found is about servlet, i.e., java.servlet.http.Cookie.
The only (minimal) support I found is in class java.net.CookieHandler, but it seems to be quite complex compared to java.servlet.http.Cookie management.
Thanks,
Giuseppe
Using URLConnection you can get/add cookies by using the headers and adding request property "Cookie" respectively. This is native to Java SE. A 3rd party library that's also good is Apache's HttpClient/. The class you mention java.servlet.http.Cookie is only available to web-apps deployed in a Java EE Application server.