We were looking to use Apache CXF framework to implement REST services. We would like to provide federated access to the rest services via SAML. The identify provider will a rest service (back ended by a DB) that would accept a user/pass and return a SAML assertion.
What would be the best practice in achieving this?
Best practice is to conform to the SAML v2 Web Profile. But the problem there is that the Web Profile relies on sessions, typically managed by cookies. Sessions are a stateful artifact that are contrary to REST.
So, rather than using SAML, perhaps you should consider something like OAuth 2, which is a bit friendlier to HTTP and REST, since it can (by design) use the actual HTTP headers as part of its transaction and not rely on sessions.
If you are willing to be a little loose in your definition of "RESTful", you may want to look at this:
http://cxf.apache.org/fediz.html
This is CXF's implementation of the SAML standard.
Or, follow the directions here to do it with CXF without the Fediz plugin:
https://cwiki.apache.org/confluence/display/CXF20DOC/SAML+Web+SSO
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!
As per the title, I am wondering what are some best practices for Web service user authentication and session management, mainly for backend implementation, especially using Java (J2EE).
Has anyone published anything on the subject? What kind of security considerations should one keep in mind when working with user authentication? What kind of design patterns are related? How should sessions be managed? What does a well-designed architecture look like?
Are there existing systems that could be used as good examples, or even bad examples?
As the Java EE specifications for web services actually consist in exposing a stateless session bean as a web service, you won't be able to implement session management without a "home-made" solution such as including a user token in each of your request.
Not specifically REST but we use same authentication mechanism for standard webservices as for any other web container request. Means send basic authentication data to backend. Over SSL. Never had any issues.
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.
In what contexts is it better to use one over the other and why?
Thanks!
JAX-WS is an API for SOAP-based WS, and using it for RESTful WebServices is not the best way to go about things.
So if you're looking to implement a RESTful WebService, use JAX-RS .
I feel like Web services are mostly tied for UDDI type applications. REST is just a plain evolution to make stateless http protocol to stateful thing by using http method communications for doing CRUD operations. Like mapping operations to methods GET, PUT, POST and DELETE.
Web Services are into coding for Airplane ticket reservation systems, Online banking, payment gateways, etc. Where there are a set of standard systems expose their API in some definitions. The JAX-RS is for providing some light weight layer for resources...
Jax-WS supports both SOAP and ReST, however if you need the features of the WS* protocols, JAX-WS is the right API. Due to this JAX-WS is somewhat complex to use in comparison to ReST.
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.