I understand, to use Spring security ACL, we create 4 mandatory tables (acl_*) in database. When a new object is created the entry is made in table 'acl_object_identity' and the security authorization rules are in table 'acl_entry' such as which user/role can read/write an object. The rules are later validated when any user tries to get or update the object.
In most of the examples online, the entries in table are done through SQL, which will not be case always in production
Question is about insert?
I think at point (such POST method in controller) of object creation two things needed:
Check user is authorized to create object, which can be done using Spring security but not spring security acl
Insert entries in acl_object_identity & acl_entry tables. This is extra code (outside spring security acl code) and be done in (ideally) same transaction as insert of new object is done in DB
Once above two are done, the spring security acl is used while validating read/update (GET, PUT, DELETE, etc. on previously created object) requests.
Is my understanding correct?
I validated and the understanding is correct.
Check user is authorized in Insert (POST) operation. Make ACL entries
Check ACL entries for read/write (GET, PUT, DELETE) operations
Related
I have a simple CRUD application that provides REST API service.
Besides simple entity CRUD, it also applies ACL rules to the entities.
It is hard for me to decide where to put the access control logic.
I am tempted to using middleware to do access control (this is a go project), since I can "separate business code and authentication & authorization".
But the ACL rules I'm applying is a bit fine-grained. It is based on user (subject) and entity (object). The rule looks like:
subject, object, permission
user_a, entity_a, read
user_b, entity_b, write
So extracting it into middleware is painful because the object part sometimes comes from path variable, sometimes from request body. And after that middleware I still need to extract authentication info for other usage.
What's more, if I apply ACL before the request touching service layer, the API will become less RESTful.
For example, if the user requested an unexists resource, say /foo/1, where there's no entity record nor ACL rules for this resource. If the ACL rules applied before service code, missing ACL rule will produce a 403 instead of a 404.
So my question is is controlling access in middleware a common pattern but I'm not doing it correctly, or should I instead just put the access control part into my service?
Dears,
I am looking for the best practices on how to pass down user object to the microservices from API gateway. user object has many roles and it is pretty big, that's why I don't want to use HTTP headers. I can save the user in Redis by setting a unique id for the key and sending this unique key with a header, then in the custom filter (in microservice) I can get and set it to the security context, but I am not sure if is it the right way. I need your suggestions.
So, I would like to implement complex session management in my application. Essentially, I would like to store user sessions both in the postgre and Redis.
So, the algorithm should be the following:
A request is sent to the app, the application parses incoming request cookies and extracts a session parameter;
Spring server tries to retrieve respective session object by id from Redis
If the previous step succeeds, then the server verifies the session and lets the request pass through if the session is active and valid. Otherwise - unauthorized path.
If the session object isn't present in the Redis, then the server tries pulling a member session from the postgre. Does the same verifications and caches the response. If the session isn't valid or isn't present in RDBMS - go to the unauthorized path.
Is there any elegant way to implement the following mechanism using existing packages? Or will this require custom logic?
So, I watched this video - https://www.youtube.com/watch?v=TggWLDAXmb4
And I was able to get a gist of how basic security mechanisms work in Spring and implement the workflow described above;
Basically, you will need to have:
Custom security filter that will be preparing specific Authentication;
Custom authentication provider that will be performing authentication (checking session)
I'm currently trying to implemente some basic security structure to my Spring Boot project, but I can't find an really concrete answer to what is going on in the authentication process. Basically, I just followed this tutorial:
https://leaks.wanari.com/2017/11/28/how-to-make-custom-usernamepasswordauthenticationfilter-with-spring-security
An it seems to be using the default Spring Security protocols and stuff, i really only implemented a custom filter where my code checks MongoDB for an existing user, and the thing works as expected.
The thing is, Postman tells me that whenever I do a successful login I receive a JSESSIONID cookie, and this cookie is used on get requests, for example. If there is a SESSION ID, I assume that Spring somehow knows how to map ID to users, but how? I haven't set up any DB configuration for that, and Spring seems to store that state somewhere. How can I access it, or change to a DB on which access I have control of?
if you want to save sessions to database, you can add org.springframework.session:spring-session-jdbc dependencty. You can choose sql file from here for your database and create tables.
I used Spring and Apache CXF to create a REST webservices application. I'm using x.509 certificates to authenticate the users, and then a custom authorization service to get all of the user groups and details. I've implemented a custom UserDetailsService that extracts the user information and populates a UserDetails object. Part of the process of populating this object involves a request to the corporate authorization service. The authorization service is unfortunately a proprietary system, but at least they provide a Java API. The authorization service, among other things, returns a list of groups that the user belongs to.
I'm still in the development stage, but my observations so far seem to indicate that the UserDetailsService is called once upon initial connection. Then each request uses a cached authorization object.
So my question and potential problem are this... Corporate policy states that applications are only allowed to cache the users authorization details for a set period of time. So, how long does Spring keep these UserDetails objects cached before refreshing them? And, how can I control this cache time to make sure I comply with policy?
There was a ticket submitted for something similar to this request:
https://jira.springsource.org/browse/SEC-898
The advice in the ticket is to create your own filter than periodically sets the Authentication.setAuthenticated property to false, forcing a look up of the user. You might be able to achieve the same by setting a smaller session timeout