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

[Filip Kinsky]

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...

[Bart Reyserhove]

Hi Filip,

We have similar requirements in our current project and we also thought of using Rhino Security in the beginning. After some discussions we decided to put it in the domain. I think in your case you also should be able to put it in the domain. By doing so you avoid having to create entities groups on the fly and it is in my opinion also way easier to unit test.

Best regards,

Bart

--

You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.
To post to this group, send email to rhino-t...@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.

[Filip Kinsky]

Thanks for your suggestion. What exactly did you "put in domain" and
how does it look like? I'd like to be able to append security
restrictions to NH queries like Rhino Security allows aside from
something like User.IsAllowedToPerformOperation(entity, operation).

> > rhino-tools-d...@googlegroups.com<rhino-tools-dev%2Bunsubscribe@ googlegroups.com>

[Bart Reyserhove]

In our case it was not desired to append security restrictions to NH queries. We needed to secure the list of employees, but the list only shows their names and everyone should be able to see all employees. We show them in different colors so that the users know which employees they can modify and which not.

We solved it in the domain by having a base class SecurableEntity and we derive the entities that need to be secured from that base class. The SecurableEntity class has a abstract HasRights method that accepts a User entity.

To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.

[Ayende Rahien]

a) RS is meant to be used in that scenario.
b) RS's entities & user groups are expected to be large.

I would actually reverse that and say that you have a user groups per
customer, instead of per user.
That way you can control settings at the customer level, not the user
level. This is often how this is done.

[Filip Kinsky]

I see.. Thanks for the reverse-tip - that's nice idea. So is otherwise
my security design concept right according to your opinion? I was just
little afraid of the security overhead - I should rather develop some
kind of prototype first.

[Ayende Rahien]

RS assumes that burden of security decisions, but it makes no attempt
to handle security management, that is why you have entity & user
groups.
So yes, your BL for security would be creating groups and adding /
removing to them.