I am in the process of interfacing to a RESTful API for a proprietary server running internal to my organization. We are using HiveMQ and I have created a simple plugin based on the incredibly useful documentation over at the HiveMQ website.
I have also reviewed the Caching and Non-Blocking philosophy so understand I need to take those into consideration when writing my plugin code.
Our RESTful API has implemented the Spring Security Remember-Me Auth and our HiveMQ plugin will use the 'valid' response to provide user Auth in HiveMQ.
My question is are there any recommended Java RESTful clients that interface with HiveMQ best? Obviously I've searched around and know there are various options. I'm hoping someone with more experience with HiveMQ can provide insight as to what has/hasn't worked better/worse than others.
Cheers!
In theory, all of the HTTP clients for Java should work in an authentication plugin. I know of Apache HTTPClient and Netty that they work perfectly for such tasks. I've created an example plugin on Github to show a proof of concept with Apache HTTPClient. Although the API is a bit clumsy, HTTPClient is rock solid (and threadsafe!).
As you already stated, proper caching is very important when you want to scale with the mechanism. Blocking is not a problem in the AuthenticationCallback, because HiveMQ needs to wait for the answer of the server which provides the restful API. I personally would use a small timeout, though.
I hope this helps for getting you started with the REST authentication. For more in-depth discussions about that topic, there is also a HiveMQ Google Group.
Related
I am about to start developing a REST service and security is an important aspect of this project but I can't find some definitive information on how to implement it. My service will be consumed by an Android App at first, but could be used by other platforms later. Controlling user access is critical, so Authorization and Authentication control of the REST services is very important.
Although I can find topics on how to make a secure REST API, like here, here and this big one here, to my surprise, all of them fail to point to a famous standard or framework or time tested solution, which usually is the "way to go" in securing software applications, where we avoid as much as we can to "roll your own security solution".
So far on my research I think OAUTH 2.0 (or even OAUTH 1.0) is the best way to go, it's a public widely used protocol and supports Authorization and Authentication and we can control the lifetime of keys and even have a special refresh key allowing the client to not store password information for acquiring a new key if needed.
I also think Apache Shiro is the best framework for Security, Authorization and Authentication in java, so it comes to a surprize for me when I can't find any integrations between Shiro and OAUTH 2.0...ok there is one that's 5 years old, and doesn't inspire much trust to me.
Even more curious is the fact that Les Hazlewood, the Apache Shiro PMC Chair, owns (ok, owned, he just sold it to Okta) Stormpath, a company made for Identity and User Management, so I would expect him to have provided some easy integrations between OAUTH 2.0 and Shiro, unless this would disrupt Stormpath business plan too much I guess (which I don't believe, since the Apache Foundation won't allow this kind of behavior).
So the final questions are:
1 - Are there any easy integrations between Shiro and OAUTH 2.0 or will I have to code my own?
2 - Does everyone implement their own OAUTH 2.0 solution for dealing with REST APIs access control or am I missing something?
I know the Buji project uses Shiro and supports Oauth2. I haven't used it, but you can check it out.
You definately don't need to code your own. There's some great java libraries and apps that you can use for oauth2 and you can choose from a low level library that you use to build your own oauth2 server up to a full featured standalone openid connect server.
Spring security provides oauth2 that you can use to embed an oauth2 server in your application. A tutorial is available at http://www.baeldung.com/rest-api-spring-oauth2-angularjs.
There's mitreid openid connect https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server, which has a war overlay that you can use to add a user and client admin app into your webapp.
Keycloak (https://www.keycloak.org/) provides a full featured standalone openid connect server.
I have a Jersey based server that I want to secure with OAuth 2.0. There are two paths that I've seen as common:
Oltu - Is compatible with Jersey and seems to be supported, although not as well as Spring Security. This 2012 question seems to suggest this is the way to go, but I want confirmation on a 2016 context so I son't implement something not as well supported anymore.
Spring Security - It seems to be very popular, but this path implies changing the server into a Spring based MVC. I don't know if that is something recommendable based on the benefits of using something as widely supported as Spring and the cost of the refactoring.
With support I mean a project that is in continous development, well established community with tutorials, materials and some libraries for clients (web, mobile, server) already available.
Which one is a stronger option? Is there another option or options?
In any case. Is there a good reference material or tutorial to start implementing this?
UPDATE
After few hours of reading and understanding about both the OAuth Providers I had mentioned, I feel Apache Oltu's documentation did not guide me much as there are key components that aren't documented yet, but an example gave me a better picture on how Oltu must be implemented. On the other hand, going through Spring Security's material I got to know that it can still be built on a non-Spring MVC based java project. But there is a limited exposure of implementations/tutorials on Spring Security on a non-Spring based project.
Another approach:
I came up with an architecture that might be more stable and would not care about the implementation details of the inner server(the one already implemented using Jersey). Having a server that is dedicated for security purpose (authorizing, authenticating, storing tokens in its own database, etc) in the middle that acts like a gateway between the outside world and the inner server. It essentially acts a relay and routes the calls, back and forth and ensures that the client knows nothing about the inner server and both the entities communicate with the security server only. I feel this would be the path to move forward as
Replacing with another security provider just means plugging out the security server implemetation and adding the new one.
The security server cares nothing about the inner server implementation and the calls would still follow the RESTful standards.
I appreciate your suggestions or feedbacks on this approach.
Apache Oltu supports OpenID Connect but its architecture is bad. For example, OpenIdConnectResponse should not be a descendant of OAuthAccessTokenResponse because an OpenID Connect response does not always contain an access token. In addition, the library weirdly contains a GitHub-specific class, GitHubTokenResponse.
Spring Security is famous, but I'm afraid it will never be able to support OpenID Connect. See Issue 619 about the big hurdle for OpenID Connect support.
java-oauth-server and java-resource-server are good examples of Jersey + OAuth 2.0, but they use a commercial backend service, Authlete. (I'm the author of them.)
OpenAM, MITREid Connect, Gluu, Connect2id, and other OAuth 2.0 + OpenID Connect solutions are listed in Libraries, Products, and Tools page of OpenID Foundation.
**UPDATE** for the update of the question
RFC 6749 (The OAuth 2.0 Authorization Framework) distinguishes an authorization server from a resource server. In short, an authorization server is a server that issues an access token, and a resource server is a server that responds to requests which come along with an access token.
For a resource server, API Gateway is one of the recent design patterns. Amazon, CA Technologies, IBM, Oracle and other companies provide API Gateway solutions. API Gateway architecture may be close to your idea. Some API Gateway solutions verify access tokens in their own ways (because the solutions issue access tokens by themselves) and other solutions just delegate access token verification to an external server (because the solutions don't have a mechanism to issue access tokens). For example, Amazon API Gateway is an example that delegates access token verification to an external server, which Amazon has named custom authorizer. See the following for further information about custom authorizer.
Introducing custom authorizers in Amazon API Gateway (AWS Blog)
Enable Amazon API Gateway Custom Authorization (AWS Document)
Amazon API Gateway Custom Authorizer + OAuth (Authlete article)
If an authorization server provides an introspection API (such as RFC 7662) that you can use query information about an access token, your resource server implementation may be able to replace (plug-out and add) an authorization server to refer to comparatively easily.
For an athorization server, gateway-style solutions are rare. It's because such a solution must expose all the functionalities required to implement an authorization server as Web APIs. Authlete is such a solution but I don't know others.
I think, it's far simplier to use the oauth connectors that are implemented inside jersey itself!
Have you considered using jersey own OAuth (already linked inside jersey) server / client ?
https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/security.html#d0e13146
Please take a look to :
16.3.2. OAuth 2 Support
hope helped. :)
I'm developing WebSocket messaging backend using Spring WebSockets, which uses SockJS + STOMP protocol. The reason why not to use plain WebSockets is because I will need to leverage security integration that SockJS provides in Spring WebSockets and also other neat features from SockJS, such as rooms, subscriptions, etc. I was wondering if this is a good option to use so that mobile (iOS and Android) and Web client apps can easily connect to the backend server and perform messaging. If yes, then what libraries I can use for iOS and Android.
On SockJS GitHub page they are also listing available client libraries, but no iOS nor Android. So, I'm wondering if SockJS is even worth to use just because of that.
I found that for iOS client Primus-Objc (GitHub page) library claiming that they can connect to native WebSockets, Socket.IO, SockJS or perhaps engine.io. is that a true statement? And event if that's true, what about the quality of that library?
And event if it is ok to use SockJS on the back, then would it be also possible to show an example code for iOS and Android so that I can perform a proof of concept on mobile devices?
If SockJS is not a good option for me, then would it be better than to build my messaging app with Socket.io + Node.js (using JavaScript). Socket.io seems to me have all needed client libraries for iOS (official library by Socket.IO guys) and Android (official library by Socket.IO guys).
Another option can be to use Netty-Socket.io library and build each endpoint manually without any help from Spring Framework (which I'm considering to use) but there is small challenge that I'll have to tackle, that is security. Somebody actually already tried to do it (the same author asking question on the official Netty-Socket.IO Github page) but looks like he didn't have a luck in solving it yet.
Maybe it's more than a year since the question was asked. But, because it's getting in the first results when Googling for SockJS+Android. So, I am posting my answer.
From my experience with a recent project I worked on, we were able to use a STOMP client - like the one here- to connect to Spring Websocket backend from native Android app.
And from the browser, you can still use SockJS client to gain across browsers compatibility to websockets with fallback.
A note to mention that when using only STOMP client to connect to native websocket the URL will be something like ws://mydomain/SockJSEndpoint/websocket,
and when using SockJS client from the browser the URL will be like http://mydomain/SockJSEndpoint.
Please find below useful references related to your requirement for both iOS and Android
http://www.elabs.se/blog/66-using-websockets-in-native-ios-and-android-apps
https://www.cometchat.com/blog/ios-android-chat-mobile-sdk/
https://github.com/elabs/mobile-websocket-example
We have tested them, both Android-client (link) was given by #Amr K. Ismail and
this iOS-client (link) are suitable with Spring-SockJS-Server which has STOMP.
SockJS may be interesting because it provides non-ws transports. Just using WebSockets may not be possible in all situations.
There is one cross-platform SockJs client of the OpenFL project:
https://github.com/jeremyfa/openfl-sockjs
Not tested how well it works, but at least for Android it's using JavaScript from inside WebView, so should be no different than JavaScript one. Again, it is not clear how tightly it is coupled with OpenFL, but the approach of using WebView and stock SockJS client could probably be re-used.
I spent many days and nights trying to find a proper Java framework that could connect to Microsoft Dynamics CRM which uses Negotiate/NTLM authentication. I tried all existing suggestions on Stackoverflow and other resources with JAX-WS, Axis2, CXF with various HTTP protocol handlers. No one of them worked as expected. The best approach currently is Axis2/commons-httpclient-3.1, where I can trace at least all three phases with NTLM digest, however the target IIS still refuses the authentication with 401 Unauthorized. Apache CXF — both with a built-in Java6 NTLM support and jCIFS, which some people suggested as a remedy, didn't work either as the former fails on the second 401 response (while it should have been send the third request, according to the protocol) and the latter one attempts to read the response code from an empty input stream and fails.
So, the question is whether anybody has succeeded to master an NTLM-protected SOAP web service from the Java 6 platform?
I was hoping somebody else would chime in, as my knowledge of this area is several years old now and perhaps not the best advice - in particular, I've only worked with commons-httpclient 3 and none of the newer packages that promise to do NTLM/NTLMv2 correctly.
As you've probably noticed, commons-httpclient 3's NTLM authentication code supports only NTLM, not the newer NTLMv2 protocol. My solution to this problem was to use commons-httpclient 3 and replace the NTLM authentication code with an NTLMv2 capable solution. Fortunately, the NTLMv2 specification is published by Microsoft. It's honestly not terrible difficult to implement but of course it's now something you have to maintain yourself which may not be desirable for a number of reasons.
I forgot so say that I did find a solution myself. The clue is to replace the standard Java protocol stack with Jespa+jCIFS and make some minor patch to work it with JAX-WS.
I'm having a lot of problems trying to implement an OAuth provider.
I would like to know if anyone has successfully used an Oauth provider using Java? I found a lot of libraries but all of them are really bad commented and I cant work with them. I'm accepting any documentation that explains how an oauth provider should work and/or how implement it.
Situation: I have some data in MySQL on my server and I would like to authorize a "rely party" to access over OAuth, but I'm not sure how to do it.
I assume you want to secure your server-side services with Oauth? You did not say what kind of server-side technology you are using.
For example for REST-based servers, both Jersey and Resteasy already have Oauth integrated.
Also, this seem to be a pretty complete servlet+JSP OAuth example: http://oauth.googlecode.com/svn/code/java/example/oauth-provider/
Here is a better alternative, It's in java and comes with demo dropwizard and Java EE applications
https://github.com/OpenConextApps/apis
ApiFest is an open-source project that implements OAuth20 specification final version (RFC 6749). The project is available at github and it is released under Apache License, Version 2.0. ApiFest is written in pure Java and uses Netty as a server. You can check the code - https://github.com/apifest/apifest-oauth20. You can take a look at the documentation on the site, too - http://apifest.com.