Spring Security ACL based on MongoDB

[RovoMe]

Spring Security ACL is, by its current implementation, based on SQL databases which joins together all 4 tables (sid, class, object_identity & access_control_entry) on lookup time. Some projects (1,2,3) added support for MongoDB to avoid having to join these 4 tables on every lookup (if no cache hit was found) and utilize the flexibility of embedded documents.

A similar question was also raised on StackOverflow asking if there is a performance reason to support only SQL based databases but not NoSQL ones.

As I have also implemented a MongoDB based ACL Spring Security Service (3), I wanted to ask if there is generel interest to include this (or any of the other projects) into the Spring Security codebase. I am aware that some modifications to the code (to adhere to the general guidelines) has yet to be done, but before putting in more work I just wanted to make sure if there is general interest otherwise my time is probably better spent elsewhere :)

I've also ported the contact ACL sample (4) to use my MongoDB ACL implementation (3) in order to showcase its functionality on an existing sample that made use of ACL.

1 Implementation by Peter Arsentev
2 Implementation by Alex Czar (though forked from somewhere else I guess)
3 Implementation by Roman Vottner
4 Contact ACL Sample port to MongoDB ACL

[zendu]

Support for MongoDB is very much needed. I work on web app that uses only MongoDB. Getting a SQL server in each environment just for ACL is overhead.

[rlogiacco]

How come this is not yet part of the official Spring Security release? have you contacted anybody in the Spring community about it?
In case they are not willing to embrace this for whatever reason, can I suggest you release this independently, so that we can pull a dependency rather than building it locally?

[RovoMe]

@rlogiacco In order to include the code into the Spring Security codebase a bit of work has yet to be done actually. My current implementation is based of Spring Security 4.2.3 which Spring Security 5 being available for some month now. Though without any general interest of the Spring Security maintainers I'm not really sure if I should put in any more effort. Also I'm a bit unsure if using their namespace for releasing Jars is the appropriate way to go. I haven't looked at the other mentioned projects yet in what namespace they will provide these artifacts, my implementation at least currently defines org.springframework.security as group-Id and may thus clash with the official artifacts and lead to misunderstandings, though.

So without any official response I will keep it in the current state it is. You are of course free to fork your own version and release it.

[rlogiacco]

I would have rather preferred to have your name more prominent on it... If I'll fork and publish I'll have to use my domain (you are right about name clashes), which somehow will reduce your visibility, even if I'll do my best to give you all the credits you deserve... What if we go for a joint effort? Is that a viable alternative? I offer a domain name for publishing and help to release and test... Il giorno dom 13 mag 2018 alle 05:15 Roman Vottner <notifications@github.com> ha scritto:

…

@rlogiacco <https://github.com/rlogiacco> In order to include the code into the Spring Security codebase a bit of work has yet to be done actually. My current implementation is based of Spring Security 4.2.3 which Spring Security 5 being available for some month now. Though without any general interest of the Spring Security maintainers I'm not really sure if I should put in any more effort. Also I'm a bit unsure if using their namespace for releasing Jars is the appropriate way to go. I haven't looked at the other mentioned projects yet in what namespace they will provide these artifacts, my implementation at least currently defines org.springframework.security as group-Id and may thus clash with the official artifacts and lead to misunderstandings, though. So without any official response I will keep it in the current state it is. You are of course free to fork your own version and release it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4484 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMLMTLkJIZtkwZ0xHxWl7QvihzbxC3Iks5tx6U_gaJpZM4OsVON> .

[raman-nbg]

Is there any progress?

For an application that only uses MongoDB as database, a relational database is to much overhead. Especially the operating cost of a database "just" for ACL. Also the total complexity of a system increases with additional data sources (and also the total availability decreases). Providing a MongoDB as data source for this would help a lot.

[yuezk]

Hi, is there any plan on supporting this?

[raman-nbg]

You can find our custom implementation here: https://github.com/MLAide/MLAide/tree/master/webserver/src/main/java/com/mlaide/webserver/acl

Maybe you can adopt it for your needs.

[yuezk]

@raman-nbg That's very helpful, thank you very much!

BTW, I'm wondering why Spring Security won't support it officially, considering that the implementation is not that complicated.