I finally found some thing to write another post on the things I learned from Ayende. This is the third one in the series. This time I will deal with Rhino Security. Ayende showed us what it could do and in my opinion it is the solution to the requirements of our customer.
Today we took some time to do try out some stuff and integrate Rhino Security in our project. While he was in Belgium Ayende added a small console application to test some stuff with Rhino Security. We reused that one to get a feeling how it works.
After you've created a new console application, the first thing you'll need is a windsor.boo file to configure Windsor
The "RhinoSecurityFacility" is the main player here. You need to tell it whether it should use a separate schema to create its tables or just use a prefix. Next to that you also need to tell the facility which class is your "User" class. Rhino Security does not contain a "User" entity and that's a good design decision but of course it needs to know your "User" entity.
"User" needs to implement "IUser" and looks for example like this:
We also added a simple business entity, being an Account (as in bank account):
Let's get started now. First we need to get the database schema in place. That's something NHibernate can do for you of course:
where CaptureConfiguration looks like this:
Ok, when that's done, we can really start with defining things. Let's start with creating two operations: /Account/Delete and Account/Name. In fact the last one will be used to define security on the property "Name" of the "Account" entity.
btw, when you create the operation "/Account/Delete", Rhino Security will automatically create the parent "Account" operation. You don't need to do that yourself.
To continue the exercise I need a entity group: Strategic Partners and a user group Management.
Define user groups and entity groups
In the first permission we tell the system that we deny access to the property "Name" of "Account" for the specific user instance but only when it concerns accounts of "Strategic Partners". In the second permission we define that the usergroup "Management" can delete accounts. You immediately see that you can create an extremely flexible security model with this. The only thing we still need to do is to create some sort of user interface so that an administrator can setup these rules.
Now we are at the point where can actually verify the set permissions. The cool thing there is that you also ask "Why" something is allowed or not:
And the result looks like this:
Permission for operation '/Account/Delete' was not granted to user 'Bart' or to
the groups 'Bart' is associated with ('not assoicated with any group') on 'Accou
nt: my account' or any of the groups 'Account: my account' is associated with ('
not assoicated with any group')
To get the information above, you have to give the system some info about "Account".
One last thing. You can also add security to a query.
Rhino Security will automatically add security to the query and it will generate a query like the one you see in this post from Ayende.
I think this should get you started with Rhino Security. In the next post I'll discuss how you can integrate this with ASP.NET MVC. That's in fact really easy.