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.
Related
I've been scavenging around the internet for information about multiple security configurations regarding combining oauth and basic authentication.
I'm not sure it's really what I want, but I decided to do some research to figure out weather it was a good idea or not.
The question is really simple. Can you combine Oauth authentication and basic authentcation in your spring boot application. So that some endpoints uses one type of authentication and other end points uses another type of authentication.
and does it make sense to do so?
The idea behind it is that I want to have heavy(oauth authentication on my endpoints if another party is calling my application) however if i'm calling my endpoints through a frontend application that I control. Should that then still use Oauth, or would basic authentication be alright?
to sum up. Is it possible to have "/getCustomers" secured by oauth, and "/ping" completely open or with another authentication type.
I hope this makes sense, I kinda trying to figure out what I want with this and if it even makes sense.
to sum up. Is it possible to have "/getCustomers" secured by oauth, and "/ping" completely open or with another authentication type.
To sum up, yes you can.
You can configure multiple entry points with same http element, you can configure different http elements, and you can even configure several WebSecurityConfigurerAdapter according to spring security reference documentation.
https://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#multiple-httpsecurity
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.
Well first i would like to mention about the architecture a little bit.
We have a UI application that uses a REST api for all the operations and use cases. UI application uses credentials to call REST api, since there are other non-UI application consuming same services.
We do authentication and authorization on REST api application using Spring Security. In fact whole application uses Spring portfolio from top to bottom.
For authentication and authorization of operations on UI application we also use Spring Security. We protect urls and display the currently logged in user only the operations that he is authorized to do.
Here is the new requirement: Some logged in users see a resource with restrictions. That mean same resource is shown with fewer fields or fewer updatable fields.
Exploring around, we narrowed down to two methods:
Use different representation for each restricted access. Based on some HTTP header set and known by client.
Use different resources for each restricted access.
If the resource-representation combinations are too much, different resource object may be less maintainable. An automated HTTP-header based restrictor aspect can be implemented. Also client have provide some header and this add minor complexity to the client.
If combinations are not too much, a new resource is created for each restricted access. Client have to call the right one at the right time. This approach can reveal hidden domain concepts as new resources and design may look more clean.
What are your thoughts? Which approach would you take?
From your architecture, I am guessing that you have the security filters setup already (I believe it's called OncePerRequestFilter in Spring?). The way I have approached this in the past is use my security filters to get the "Role" of the client (assuming you can have roles assigned for each client which map to specific permissions/restrictions on each resource object). Now based on the "Role" I have custom JSON serializer/deserializer strategies (I used GSON for this inclusion/exclusion type adapters. You can read more here (Gson custom seralizer for one variable (of many) in an object using TypeAdapter) ) that will take care of what resource fields should/should not be populated/serialized. This way, you will continue to use the same resource object and TypeAdapter for each resource object which will determine the serialization/deserialization of the resource object based on the role of the client.
One more idea that comes to my mind is method interceptors (Spring AOP). Although I have never tried it with method interceptors, I think it should still work in the sense that you will intercept the method right BEFORE it returns (and after the business logic is done) and look at the role of the client making the request. Based on that role, you can determine what fields to null out (most serializers (atleast gson) do not serialize null fields) and not serialize, before converting it to json (or whatever your return type might be) and sending it over to the client
I hope this helps.
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!
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.