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.
Related
I have been working on an app where the front-end (React) and back-end (Micronaut) are separate. They currently communicate via REST use Micronaut's built-in JWT authentication. I'd like to use something like Auth0 or Keycloak to avoid having to implement user management code.
Is that possible given the separation of my front-end and back-end? If so, are there any resources I can use? I haven't found many concrete answers to that question, but have been looking into OAuth's Client Credentials Flow. Is that what I want in this case?
Auth0 has documentation on how to do authentication through their authentication code flow which can work well for REST APIs. It uses jwts, but gives you an easy way to verify the jwts and get the token info using their get user info api.
If this is not what you’re looking for, I would recommend checking out the Auth0 authentication API docs. It walks you through setting up many different kinds of complex authentication flows and (in my opinion) makes them pretty easy to implement. Hope that helps!
I am trying to authenticate users with a REST service I built using drop wizard. From previous questions I found great example of authenticating with openID on github: https://github.com/gary-rowe/DropwizardOpenID
However, I don't want to deal with openID at the moment and simply want users to 1. Signup, 2. Signin
My questions/confusions are:
For Signup: I'm thinking about sending users's username/password as a POST request with the credentials as either form parameters or part of JSON body. However, isn't there a security risk here of sending password in plain text?
For Sing-in I'm thinking about using Authenticator in Dropwizard.
I don't want to store passwords in plain text. What strategy should I follow after I get the users' password in the POST as plain text? I'm looking for some java libraries that can assist in password salt and MD5
Thanks for the shout out for the Dropwizard OpenID project. Glad it was able to get you started.
If you want a pure web form type approach, take a look at another of my projects MultiBit Merchant which provides multiple authentication methods (web form, HMAC, cookie).
You'll need to dig around to really see it working since this project is not designed as a demo as such and is very much a work in progress.
After loading the project, look for WebFormClientAuthenticator which will get you in the right area.
The general principles involved with Dropwizard authentication are discussed in this blog article. Although it targets HMAC you can easily adapt it for web form or cookie using the source code referenced earlier.
It's all MIT license so just use it as you need.
Looking at the docs, we can see that Dropwizard supports a standalone OAuth2 implementation:
http://dropwizard.codahale.com/manual/auth/#oauth2
OAuth2 has several advantages, many of which can be read about here: OAuth 2.0: Benefits and use cases — why?
Things to note:
when dealing with authentication, you should always host over HTTPS to ensure transport encryption
Dropwizard claims their OAuth2 implementation isn't yet finalized, and may change in the future. As a fall back, they do support Basic auth as well, which when used over HTTPS would be still reasonably secure.
Implementing this does not involve using any third party "social" authentication services such as Google or Facebook.
I've found a good example about authenticating WCF services with custom username/password (A simple WCF service with username password authentication: the things they don’t tell you). This fits what I need... partially, I guess. It uses wsHttpBinding and Message as the security mode.
The WCF service I need to build will have Java clients, and my question is if the example from the link above works with Java ("interops" well). Or should I go with basicHttpBinding, securing the connection at transport level (https)?
Thanks
WCF implements lots of Web Service protocols:
http://msdn.microsoft.com/en-us/library/ms730294
Although complicated solution is not necessary the best one.
Go ahead with basicHttpBinding and Transport security if it fits all other requirements you have.
There is good all-in-one article that describes configuration:
http://www.remondo.net/using-ssl-transport-security-wcf-basichttpbinding/
transport security will almost always be better for interoperability. Having said that username security is also pretty safe, especially if it is under ssl and not use message level certificates. Even if there are certificates it is possible to interop with the axis2 or wsit java frameworks. it may be challenging though, so if you will have many arbitrary clients and want them to interop with your service without any special guidance you may want to avoid it.
BTW basicHttp and wsHttp are both capable to do either message or transport level. basic is a little easier for interop since it does not use ws-addressing.
One desktop application needs to get some services from server.
For example sending some parameters and receiving some result.
Imagine implementing a solution by Java Servlets, in a way that the app sends the parameters to the servlet (POST) and receives the result in XML.
Does this approach have any security issue in compare with web-services (Soap / Restful) ?
Thanks and sorry if the question is a bit general.
I don't think so. But personally I would still go over REST, mainly because it would be easier to maintain and update if needed. Also probably easier to test and implement.
As long as your solution has suitable authentication (username/password) and takes place over SSL, it's no less secure than Web Services/SOAP. And indeed you might find it a simpler solution to implement.
The security issue is the same for both solutions because it's http but I won't do the post thing because it's not structured properly, meaning it's client dependent and not using a standard. If you don't like XML, you can try JSON.
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.