We Keep Coding

Migrating Apache xmlrpc from 2.0.1 to 3.1.3 - How to deal with the removal of the SecureWebServer and related APIs?

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

Limiting Wildfly 14 Two-Way SSL to specific clients

We're maintaining a Java application with a JAX-WS SOAP API for external systems running on WildFly 14 application server. The external systems currently connect using common one-way SSL. Our goal is to switch communication to mutual authentication, so two-way SSL.
Not all of the external systems can make the switch at the same time though, so simply enforcing two-way SSL is not an option. We need to migrate them step-by-step during a transition phase. That why I've been wondering: Is there a possibility to enable two-way SSL on a WildFly HTTPS interface for specific caller IPs only?
I have based my tests on the official documentation on setting up regular two-way SSL. Following these steps, every caller needs to provide a client certificate. Modifying that example configuration to use want-client-auth instead of need-client-auth softens the checks to support two-way SSL but not require it. Unfortunately that is not enough in our case, because it does not imply guarantees about whether a particular external system is consistently using two-way SSL or not. A system could send some of its requests providing a client certificate, and some without. In other words, business requires a way to say "From this day on, external system Foo may only use the API with a client certificate. All the other external systems are unaffected, for now."
To implement this - preferably without application code changes -
I've been reading the documentation of the new WildFly security module Elytron. It seems quite extensible, but details on custom components are sparse and I haven't found an extension point that sounds like it would help in my case.
The only solution approach I have right now is configuring a separate set of socket-binding and https-listener for Wildfly, similar to what is described here. That means we would have two HTTPS ports: One with one-way SSL, and another one with mandatory two-way SSL. As external systems are completing their migration steps, they switch the port used for invoking our API. Forcing them to only use the two-way SSL port from then on would require specific firewall rules, but should be possible.
So, this solution is rather simple in technical implementation but leads to overhead for re-configuring the external systems and adapting firewall rules. That's why I'd be happy about any suggestions for a solution that is more elegant, or hints how to use Elytron for that.
Thanks in advance!

I think you came to best conclusion. Elytron does not have possibility to choose SSL Context based on client parameters (What would that be? Client IP address? That can change when behind the load balancer.)
So I think only way is to have different SSLContext configured on different ports (or hostnames).
Regarding extending server. I guess SSL handshake is very early step and after that different customisation points take part. I thought about some Undertow custom handler, something similar to [1], but as I said that would be too late.
[1] http://undertow.io/undertow-docs/undertow-docs-2.0.0/index.html#redirect-handler

Java proxy authentication (with HttpURLConnection)

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.

which free LDAP server to use?

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.

Best Java supported server/client protocol?

I'm in the process of writing a client/server application which should work message based. I would like re-use as much as possible instead of writing another implementation and curious what others are using.
Features the library should offer:
client and server side functionality
should work message based
support multi-threading
should work behind load balancer / firewalls
I did several tests with HTTPCore, but the bottom line is that one has to implement both client and server, only the transport layer would be covered. RMI is not an option either due to the network related requirements.
Any ideas are highly appreciated.
Details
My idea is to implement a client/server wrapper which handles the client communication (including user/password validation) and writes incoming requests to a JMS queue:
#1 User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2 User polls Wrapper which polls JMS
Separate processes will handle the requests and can reply via wrapper to the clients. I'd like to use JMS because:
it handles persistence quite well
load balancing - it's easy to handle peaks by adding additional servers as consumer
JMSTimeToLive comes in handy too
Unfortunately I don't see a way to use JMS on it's own, because clients should only have access to their messages and the setup of different users on JMS side doesn't sound feasible either.

Well, HTTP is probably the best supported in terms of client and server code implementing it - but it may well be completely inappropriate based on your requirements. We'll need to actually see some requirements (or at least a vague idea of what the application is like) before we can really advise you properly.

RMI works nicely for us. There are limitations, such as not being able to call back to the client unless you can connect directly to that computer (does not work if client is behind a firewall). You can also easily wrap your communication in SSL or tunnel it over HTTP which can be wrapped in SSL.
If you do end up using this remember to always set the serial version of a class that is distributed to the client. You can set it to 1L when you create it, or if the client already has the class use serialver.exe to discover the existing class's serial. Otherwise as soon as you change or add a public method or variable compatibility with existing clients will break.
static final long serialVersionUID = 1L
EDIT: Each RMI request that comes into the server gets its own thread. You don't have to handle this yourself.
EDIT: I think some details were added later in the question. You can tunnel RMI over HTTP, then you could use a load balancer with it.
I've recently started playing with Hessian and it shows a lot of promise. It natively uses HTTP which makes it simpler than RMI over HTTP and it's a binary protocol which means it's faster than all the XML-based protocols. It's very easy to get Hessian going. I recently did this by embedding Jetty in our app, configuring the Hessian Servlet and making it implement our API interface. The great thing about Hessian is it's simplicity... nothing like JMS or RMI over HTTP. There are also libraries for Hessian in other languages.

I'd say the best-supported, if not best-implemented, client/server communications package for Java is Sun's RMI (Remote Method Invocation). It's included with the standard Java class library, and gets the job done, even if it's not the fastest option out there. And, of course, it's supported by Sun. I implemented a turn-based gaming framework with it several years ago, and it was quite stable.

It is difficult to make a suggestion based on the information given but possibly the use of TemporaryQueues e.g. dynamically created PTP destinations on a per client basis might fit the problem?
Here is a reasonable overview.

Did you tried RMI or CORBA? With both of them you can distribute your logic and create Sessions

Use Spring....Then pick and choose the protocol.

We're standardizing on Adobe's AMF as we're using Adobe Flex/AIR in the client-tier and Java6/Tomcat6/BlazeDS/Spring-Framework2.5/iBATIS2.3.4/ActiveMQ-JMS5.2 in our middle-tier stack (Oracle 10g back-end).
Because we're standardizing on Flex client-side development, AMF and BlazeDS (now better coupled to Spring thanks to Adobe and SpringSource cooperating on the integration), are the most efficient and convenient means we can employ to interact with the server-side.
We also heavily build on JMS messaging in the data center - BlazeDS enables us to bridge our Flex clients as JMS topic subscribers. That is extremely powerful and effective.
Our Flex .swf and Java .class code is bundled into the same .jar file for deployment. That way the correct version of the client code will be deployed to interact with the corresponding middle-tier java code that will process client service calls (or messaging operations). That has always been a bane of client-server computing - making sure the correct versions of the respective tiers are hooked up to each other. We've effectively solved that age-old problem with our particular approach to packaging and deployment.
All of our client-server interactions work over HTTP/HTTPS ports 80 and 443. Even the server-side messaging push we do with BlazeDS bridged to our ActiveMQ JMS message broker.