Last time I promised to cover security aspect of CRM.
Security means that Manager A can do something, while manager B can’t; Security means that these rules are set in easy way. Security means that all rules (allow/deny) works as planned. Security means that all rules can be viewed in user-understandable format.
Let’s continue discussing our manager-client company. Earlier we develop concept BusinessAction. Every action can be defined in such way. For example, we can define general actions like «Create», «Delete», and more specific like «Add client», «Create report on Client» etc. And we have to find way to specify for each UserInRole set of rules, and TargetPathes. TargetPathes in this case can be specific, like «Client with id=112″. And can be relative, like «all clients managed of this manager» or «all managers of department of this manager».
Entity RuleApply (id, user_in_role_id, target_path, action_id)
Target path should define how to find objects to apply rule to. Target path can contains conditions, and should be designed similar to SQL queries. But this isn’t sufficient (or complicated) when we want some advanced logic, we should seperate target_path and target_objects.
For example, target path can be «Managers firstlvl, Manager secondlvl, Clients clients where firstlvl.parent = our_ID secondlvl.parent = firstlvl.id and clients.owner = secondlvl.id and clients.age < 18″ and target object can be «secondlvl», or «firstlvl» or «clients» or even «clients.name, clients.phone» only. So this way we can set agile and strong conditions (SQL-like joins and where), and determine on which object this rule applied (SQL-alike select [table.*] from).
We adding one more property to Entity RuleApply:
Entity RuleApply (id, user_in_role_id, target_path, target_object, action_id)
Of course there should be «allow» and «deny» RuleApply types, and priority would be good one, so we need two more property:
Entity RuleApply (id, user_in_role_id, target_path, target_object, action_id, isAllow, priority)
Assuming we already have converter which convert target_pathes and target_objects to SQL queries, and can determine for each RuleApply objects which fit to conditions, our security model is full now.
To prevent security holes in security manager, we need to have 2 key features:
- Each request should be processed/executed with pre-calculated objects access context, so there will be minimal situation when user get wrong access using SQL.
- Every action should be logged in viewable format, so any wrong actions should be easily traced/fixed.
Well, that’s all. This secirity model is a similar to ACL model, and should work well as trusted and tested solution.
In next article I’ll give a few UML schemes about CRM classes and request lifecycle. Stay tuned!