We are developing RESTful webservices using Spring MVC 3.x. I am wondering what is the best way to implement Basic Auth. Note that we do not want to use Spring Security. We just want to use regular Basic Auth.
Each request should be authenticated. No state maintained. Its regular u/p authentication and the credentials are validated against the database.
I was thinking of using Interceptors. So every request to the server will first go through the interceptor. Is this the best practice?
I am not sure about filters. Is this same as interceptors?
Any other better way to implement this? What is industry standard for this implementation?
What are the use cases for interceptors / filters, if these two are different?
Thoughts?
Thanks much!
Related
I am trying to implement a custom authorization scheme for an OData2 server which is exposed using the Apache Olingo JPA annotation processor; the authorization involves a basic user:operation pair to restrict query/update/insert/delete operations on the database; the idea is to secure the server layer (Tomcat) via username/password, and then propagating the user id to the OData layer to perform the permission check.
Has anyone implemented something similar? My current approach involves extending the ODataJPAProcessor and making the checks in the relevant methods (readEntity, updateEntity, etc.); however I am not sure if this would be the best way forward.
Any help would be greatly appreciated.
Regards,
-Eduardo.
On my project we used identity provider and JWT token. Token was validated and used in the exposed OData servlet and all the permission checks were inside the processors. We used a Decorator design pattern to wrap standard processors with the Secured ones and only the Secured ones were allowed inside OData handler.
I cannot guarantee that it is the best approach, but it sounds reasonable.
This question from 2 years ago - Using Spring Security ACL with Spring Data REST - talks about spring-data-rest and record-based authorization with Spring Security.
I'm asking again to see if there is any new solution, or anything in the pipeline.
Ideally I'd like to use something highly RESTful, e.g. Prevents HTTP method in spring-data-rest - examines how to implement the HTTP OPTIONS method and my aim would be to be able to plug in something to SDR that allows me to do the authorization verification based on authenticated user and the data from the model.
Again, hopefully someone out there, perhaps the Spring guys themselves, have a neat way of enhancing SDR, maybe with Spring Security using ACL http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#domain-acls
I've seen a bit of activity in this direction for CORS but I'm not doing any cross-origin stuff so I haven't been down that road.
I'm creating a web application containing RESTful webservices and I was wondering how I can properly integrate HDIV with this part of my webapp.
For now, I'm defining each webservice URL as startPage:
<hdiv:startPages>/ws/ws1,/ws/ws2,...</hdiv:startPages>
Is there a way to change that? does <hdiv:startPages>/ws/*</hdiv:startPages> or something like that exists?
You can use Java patterns to define start pages:
<hdiv:startPages>/ws/.*</hdiv:startPages>
Anyway, you can try Spring HATEOAS and Hdiv's experimental integration to securize the REST services.
I'm writing a RESTfull service using jersey and Spring 3 (including spring-security), and trying to figure out how to implement authentication and authorization.
I'm new both to jersey and to Spring so it's all a bit confusing...
Users and their roles are defined in DB. (and not defined in the web.xml or in tomcat-users)
Here are my thoughts about the Authorization part:
Since my service shouldn't necessarily serve web-apps, the authorization should be done on the REST resources (and not on pages) - how do i do this? i saw there's #RolesAllowed annotation but it seems too simple, i need more logic. i think i have to somehow activate spring security from there to use the authorization capabilities they offer.
Any suggestions as to how to do this?
For the Authentication part it seems i should use spring security's AuthenticationManager, and SessionManagement but i'm not sure how to connect it to the REST API:
1. how the API that gets the authentication request should look like?
2. if Spring handles my sessions, how can i add the authorization on my REST resources?
I'd really appreciate if you could help me clear up things...
Thanks!
Sorry, but if you're at that early stage with your Spring Security know-how I must suggest you work through the excellent tutorial first. I'm sure your questions will be answered automatically and you'll learn a lot of valuable stuff along the way.
We have a Spring web application created using Spring MVC 3.0 In the same application, we have created RESTful web services using Springs's REST API.
Now we need to secure those web services. How do we do this in spring? Can we use spring security for this? If not what are the other options?
Thanks.
It really depends on the level of security you want to impose. You could just use simple web.xml based access control with realms, usernames and passwords.
Security of your webservices is another matter. From the Spring Security FAQ:
Web applications are vulnerable to all kinds of attacks which you should be familiar with, preferably before you start development so you can design and code with them in mind from the beginning. Check out the OWASP web site for information on the major issues facing web application developers and the countermeasures you can use against them.
Spring Security is certainly an option. It is for the most part, easy (nowadays) to integrate with Spring and has a flexible authentication module.
You should also consider Apache Shiro. A comparison to Spring Security question has already been answered - Shiro vs. SpringSecurity and Shiro also integrates nicely with Spring.
There are also some other questions already answered on this topic - How to secure a service REST with spring3? and Looking for a Simple Spring security example
I do not think there is a definitive answer to the question in it's current form, but I hope this helps all the same.