We Keep Coding

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

NTLM authentication with Java outside Domain

My question is simple, the answer might be complicated though.
Can NTLM authentication be done outside a network from a tomcat server using Java code to do the authentication? If so, what sort of certificate/trust exchange is required? What other requirements are there? Would it depend on the setup of the server needing to be authenticated against?
I can't find this exact question anywhere and am hoping for some general info on this, not a specific implementation, although that would be cool to see.

Not aware of NTLM, but common approach is to use LDAP AD.
Spring security has a good support on LDAP authentication: http://docs.spring.io/spring-security/site/docs/3.0.x/reference/ldap.html
You need to be familiar with your organization's AD structure. Below is sample configuration from JIRA LDAP AD setting which roughly highlight configuration item required to setup LDAP authentication

I found that the answer to this is to use something like SAML or OAuth to authenticate outside the network/domain. Working on implementing SAML.

REST HTTP Authentication - How?

So, I'm developing a REST webservice using RESTeasy and Google App Engine. My question isn't related to GAE, but I mentioned it just in case it matters. It happens that naturally I need to secure my resources and my own users (not Google's).
Securing a REST webservice seems like a very controversial subject, or at least a very 'liberal' one. REST doesn't impose any standard on this matter. From what I've researched on the web and literature, there are at least 3 approaches that I think might fit in my application:
HTTP Basic (with SSL)
HTTP Digest (with SSL)
OAuth
OAuth seems like the most complete approach. But I don't think that such a complexity is needed because I will not need to authorize any 3rd party applications. It is a webservice to be consumed by my own client applications only.
HTTP Basic and HTTP Digest appear as the most simple ones on the web, but the fact is that I've never found a concrete implementation of them using RESTeasy, for example.
I've found this page and this one in RESTeasy's documentation. They are indeed very interesting, but they tell little or nothing on this subject (HTTP Basic or Digest).
So, here I am asking:
How do I secure my WebService using HTTP Basic or Digest in RESTeasy?
Perhaps it is so simple that it isn't worth mentioning in the documentation or anywhere else?
Also, if anyone can provide me some insight on the matter of securing RESTful webservices, it could be helpful.
Am I choosing the right approaches?

The simplest way to secure a REST API is to use HTTP Basic authentication over SSL. Since the headers are encrypted there is not much point of using Digest. This should work great as long as you can keep the password secure on the client(s).

I've managed to accomplish this by using RESTeasy's Interceptors.
Basically the requests are intercepted by using a listener like class. In this class I inspect for the request's HTTP headers and then the normal Basic-Auth process goes on.
Useful links:
http://en.wikipedia.org/wiki/Basic_access_authentication
Passing parameters in the message header with a REST API
http://www.alemoi.com/dev/httpaccess/ (the Servlet part)
I hope this helps anyone.
Thanks.

you will definitely face a security risk when using any authentication method without SSL.
but if you did use SSL, you will usually suffer from a poor performance.
Oauth is actually a solution to allow 3rd party to obtain access to your webservices.
due to the limited selection, my solution to a current webservices that require authentication used the combination of SSL+basic

You might look at using OAuth 2. It is significantly simpler then OAuth 1 and is actively being used on large REST API by Facebook and Google.

Secure Java Web Services

I am trying to figure out which framework/API would be best for implementing my web services (Java EE). The data being passed back and forth between client and web container needs to be super-secure, and so I'm even thinking of encrypting my data before it even gets wrapped up in a SOAP (or the secure equivalent to SOAP) message, regardless of what security services the framework provides me with.
I see there is the so-called XWS-Security but it seems that it is for securing legacy JAX-RPC services. I'd like the framework to be standards-compliant (WSS/OASIS, etc.) and neither deprecated or deprecating (current; compatible with the upcoming Java 7 release, etc.).
Is JAX-WS and JAX-RS secure by default? If not, is there a compatible "secure wrapper" framework that can be used to adapt an existing JAX-WS web service to implement a secure framework?
Any thoughts or suggestions greatly appreciated!

If you just want to secure the content then use transport layer security, such as HTTPS. This will automatically encrypt WS request/responses and prevent evesdropping and malicious modification.
If you want to do any authentication/authorisation you might want to get the caller to sign the request too.

You should do two things, first secure the transport using SSL. If you control both the clients and the server then you can require 2-way SSL which would ensure that only trusted clients can connect.
Second you can implement WS security protocols. Web service security standards tend to deal with three things: Authentication, Digital Signatures and Encyption/Decyption (from the Spring-WS docs):
Authentication. This is the process of determining whether a principal is who they claim to be. In this context, a "principal" generally means a user, device or some other system which can perform an action in your application.
Digital signatures. The digital signature of a message is a piece of information based on both the document and the signer's private key. It is created through the use of a hash function and a private signing function (encrypting with the signer's private key).
Encryption and Decryption. Encryption is the process of transforming data into a form that is impossible to read without the appropriate key. It is mainly used to keep information hidden from anyone for whom it is not intended. Decryption is the reverse of encryption; it is the process of transforming of encrypted data back into an readable form.
There are a number of protocols/standards for each of these functions, and
there are a number of Java OSS projects that implement the various security protocols/standards in a reasonable, usable ways.
In particular I'd look at Sun's XWSS and APACHE WSS4J. Spring WS has implementations of both of these APIs, they also do a good job of describing the various components: http://static.springsource.org/spring-ws/sites/2.0/reference/html/security.html

How to secure Java webservices with login and session handling

I'd like to secure my (Java metro) webservice with a login.
Here's how I'm planning to do that:
Steps required when calling a webservice method are:
call login(user,pwd), receive a session token
1.1 remember the token
call servicemethod (token, arg1, arg2...)
webservice checks if the token is known, if not throw exception otherwise proceed
logout or timeout after x time periods of inactivity
my questions:
1. what's your opinion on this approach? does it make sense?
2. are there any libraries which take the burden of writing a session handling (maybe with database persistence to survive app restarts)
(the solution should be simple and easily usable with Java and .NET clients)
thanks!

This is feasible and I've seen web services using a similar approach. But I wouldn't implement my own custom solution. Instead, I would use a Security Token from the WS-Security specification and, more precisely a Username Token (you get this from WSIT which is part of Metro and is thus interoperable with .NET clients). Have a look at this article for an introduction.
Update: More pointers:
Implementing the WS-Security UsernameToken Profile for Metro-based web services
What's New in Web Services Enhancements (WSE) 3.0
WebService Authentication with UsernameToken in WSE 3.0
Implementing Direct Authentication with UsernameToken in WSE 3.0
I can't say that I found WS-Security very friendly but, still, my experience is that using WS-Security takes less time than implementing a custom solution, is more secure and scales better (checking the database at each call has a cost).
Edit:
Corrected the first two links, because they were dead. Couldn't find one for the third but I think the second should cover that.

Don't immediately jump into implementing this yourself from the ground up. Many J2EE containers / Java frameworks offer support for login / access control. Take a look at the documentation for the framework you are currently using.
Another simple alternative is to implement access control in a front-end webserver; e.g. Apache HTTPD acting as a reverse proxy for Tomcat.

I've thought about trying out Apache Shiro, I can't really say if its any good. Looks good though.