Rhino Security implementation for use case "user can only see entities for customers assigned to him"

Question

We're building/designing next generation of our sales/ordering/CRM system which comprises of entities like customer (customer hierarchy in particular), order, promotion action, ... Each user of the system should have assigned one or more customers. Users should be organized in a form of organizational hierarchy. The system should control access to customer-related entities according to current user settings. The problem is that it should work in hierarchical way in both customer and user directions. That means that if user has assigned customer X from the hierarchy, he should be also able to operate with all childern of this customer. And in simmilar way with users - a manager should be able to operate with all customer-related entities which are allowed for his subordinates.

I'd like to use Rhino Security for restricting access to operations over entities in the system, but I'm not sure if it's suitable for this complex scenario. My current mind state is that it should be possible if I'm able to develop some background process (probably service-bus based) which would be able to generate entity groups for all new/modified entities. However this means that there will be quite a huge amount of entity groups without any good intent background. There won't be groups like "customers which don't pay bills" etc, but just groups like "customers for user X", which would contain all the allowed customers. There will be some other operations which would be controlled in much more Rhino Security-standard way like "only managers are able to invalidate a customer" though.

I'd appreciate any thoughts on this problem...

Answer 1

Rhino Security + ESB background processing is viable solution to my problem according to Ayende's reply to my question on http://groups.google.com/group/rhino-tools-dev/browse_thread/thread/223afddae5cfcd23/6df7f35f8eb29d49

Answer 2

Coming from a SharePoint perspective, which I know is not the case here, it would appear the best way to approach this is to create a custom security scheme that has xyz permissions. After which you would assign users to that group, to clarify it's the same as using a portal frame of mind. One central repository for data with multiple users being served up the appropriate information. Hope this helps.