I've been recently working on a project management program (getting there)..and have started to wrestle with the security model. Basically it uses a standard gacl (general access control library) library (open source) that tries to deal with every likely possibility. The gacl idea is to allow modules to be defined and within each module 5-7 permission layers that can be set per user and/or group - for both access and denial of access - I know confusing. For example:If you have an application with a Company module and user contact module and within each you can Create/Update/Delete (CrUD) and View then you have 2 modules x 4 actions x 2 possible settings (allow/deny) = 16 take that and multiply by the number of users - say 100 - and you get 1600 table entries for the security module (roughly speaking). Where the general idea of having a generic approach makes sense, the problem comes into play when you start to scale. I've seen similar modules used to support a 20 module system for 100,000 users producing 160,000,000 records in the security database.....basically killing the system.
The basic argument for using a generic gacl is that it provides a consistent framework and reduces code support and issues - and it's made to accommodate all potential needs.
Here's my issue with this:
- there are always exceptions (what if there's a single field in a module that needs special security handling? for certain users? for certain data? (a bank system that does not allow tellers to cash out accounts for consumers with an 'interesting' criminal background)
- it really doesn't scale well
- it's so complex that handling it and implementing the model (each module would need it) takes time/effort and potential coding mistakes.
My advice - understand the needs and data prior to implementing an overly complex generic approach - YOU CAN'T ACCOMMODATE EVERY POSSIBILITY SO DON'T TRY - make the solution specific to the need.
(image from: exploring geometries)
No comments:
Post a Comment