I have a question about object decoupling and who should be responsible for some of the business logic I am trying to implement.
I am working with an expanded security model based on a rights-based approach whereby a user is a member of a set of security groups each with various rights assigned (either allow or deny). The approach is very similar to the way Windows security works. However, we want our framework classes to support both simple and complex models - i.e. role-based or rights-based security. To do this, I need to be able to check both the list of groups and the list of rights for a user when a security check is performed. In other words, when we make a call such as:
AuthorizationRules.AllowWrite("PropertyName", "Role");
I would like to be able to specify either the role (group) OR the right. This will free the developers using the framework to implement the security check using either method.
The question I have is where it is best to put the logic required to assess whether the security check passes or fails?
We already have created a SecurityManager class which manages all of our settings, etc. that govern how security is applied. Initially, we created a static Authorize method that accepted an IPrincipal object and the role/right being checked. In this method, we would search to see if the argument passed was a role (group) by checking the user's Groups collection for a match. If not, we would then look in the user's Rights collection. This method was used in lieu of any direct calls to IsInRole() in our code, including the RolesForProperty class.
However, this approach limits us to ONLY using our custom objects and doesn't seem consistent with the standard approach. I am wondering if it would be better to implement this logic within the IsInRole method and include it in our custom principal object rather than externalize it in the SecurityManager class. Or, is it better to leave IsInRole() synonymous with IsInGroup() and not mix the rights-based stuff here?
My thought is that to truly decouple the SecurityManager from the custom principal object, it must not assume anything such as the existance of a Rights collection and only work with the IPrincipal/IIDentity interfaces. If that's the case, the we only have IsInRole() to work with and the logic should all be placed in this method within our custom principal.
Any thoughts?
I'm not sure the correct answer to this question; I just have a few ideas. Very curious to see what others have to say.
My tendancy would be to stick to the IPrincipal/IIDentity interfaces and perform the rights check within your custom principal object. Your pricipal could have a configuration setting (perhaps read from the .config file or set as a static property by the business objects) that would switch the IsInRole method from evaluating roles vs. rights.
Actually, having the switch might not even be necessary, since, once you went down the rights-based security path in a given business object library, there would be no need to check for roles anyway (since you could always create a right that would perform the necessary security check). It might make more sense to just implement a RightsPrincipal and be done with it.
~pete
I have IsInRole in my custom Principal.
But I also have a finer grained collection of permissions which is accessed through HasPermission.
I spoke with Rocky about this and he agrees that restricting the call to IsInRole is too limiting. He said he would investigate adding a Delegate so that you can replace the call to IsInRole with something that matches the Delegate. This way you can use his entire framework to support a call to HasPermission.
I assume he means version 2.2 or later.
Joe
Copyright (c) Marimer LLC