beeekind
commented
8 years ago Preamble: I only just started implementing action control lists for my own app.
My understanding is that yes, the data store being used for your ACLs (mongo/redis) is usually separate from whatever store you're using for your user/account model. The important point here is that the ACL is being used in your controller layer (assuming traditional MVC) in order to govern your control flow based on a high level authentication/authorization abstraction.
A.k.a. user y has access to resource x, therefore allow him to delete the resource using controller z.
Which would mean that to implement ACL's to an existing app with a prepopulated database would require some kind of initialization step. Like iterating over all users and giving them the desired permissions. Finally you would modify your controllers (again assuming MVC) to do the necessary addUserRoles / removeUserRoles when certain endpoints were hit in your API.
I think the initialization step would best be done by a small script that read the database and applied the rules to your ACL.
Let me know if any of that was unclear or needs better explanation.
It's not clear to me-- is the backend datastore for acl intended to operate potentially in parallel with another datastore being my primary user store , or is it intended that the acl backend operates directly on my primary user store?
In my case, my application is using SQL (Sequelize, to be precise). So I'm assuming I could use the memory or REDIS backend, and then at application start make calls to acl.addUserRoles() for each of my users in the SQL db to load acl? Then make calls to acl.addUserRoles / acl.removeUserRoles as users are modified during run time? Is this an intended pattern of usage?
Thanks.