Hello
I'm wondering if I'm missing out on something very obvious, or if I'm the only one looking at this as a issue.
The issue I'm talking about is the the handling of roles as strings.
The question is:
How do you handle roles in code, do you actually write stuff like this:
AuthorizationRules.AllowRead("Manager")
or do you have something to help you, like this
AuthorizationRules.AllowRead(Roles.Manager.ToString())
Some more example and background:
In my point of view, a role is typicall used as a bridge between what is presented to the user, to select between, and hardcoded checks peformed in the application code.
(in this case I'm not considering dynamic configuration between autorization rules and roles)
If I have 8 different classes, with 5 properties each, and I want to activate access to these properties based on 3 different rules. That should be something like 8 classes * 5 properties * 4 access types = 160 authorization rules.
I would bet that somewhere in the 160 methods you would find something like this:
AuthorizationRules.AllowRead("Mangaer")
How to know the roles that the system is expected to know about is another part of the same.
Again, simple in a small system, but when you get a large system this have to be important issues, or?
Best regards, TEK
![Smile [:)]](/emoticons/emotion-1.gif)
The one beeing so lucky to have the solution ported to VS 2005 :-(
Thanks for the answare, it's absolutly a way to go.
Are roles in resources still the way to go with csla 4.x to avoid typos?
If there was one area I wish some love would be devoted to it's the roles system which is quite primitive for any substantial application.
After having published and maintained a large csla 1.x based app for many years now and reading all the latest info to migrate to csla 4.x I'm seeing so many improvements that dovetail with my real world experience, unfortunately roles are a glaring standout of lack of any real modernization or jive with real world requirements for a large complex application.
I realize the coupling with the way .net does security guiding the string role checking; it's just typing manual strings over and over thousands of times which screams out for improvement. Not to mention the issues with having to actually release a new version of our software to add a new role and manually, laboriously adding it to all the business objects (hundreds each with dozens of properties).
It should not even be used in the sample projects, it could give less experienced programmers the crazy idea that they should actually do it that way. ;)
That being said we're going to find a way to work with it because we want to use the stock CSLA this time around since most of the modifications we made over the years are now baked in, just consider it Rocky.
The role concept comes from .NET and Windows, so it isn't something I can unilaterally change - at least not without entirely discarding every aspect of .NET and Windows athorization.
However, CSLA 4 has a completely open model for authorization rules. While the rule implementations provided in CommonRules are based on roles so they work with .NET/Windows, you can implement your own authorization rule types that use any scheme or model you come up with.
The concept that's been floating around for a few years now, and is implemented in WCF (as an option) is claims-based authorization. One of the primary reasons CSLA 4 has this completely open authz model is so people can implement claims-based rules.
I understand that and it's nice to have an open system.
My main concern with it is in line with the original topic of this post which is avoiding typos. I'll look into using resources as you suggested years ago.
What I'm saying is that neither you nor I can change how Microsoft implements the role concept in Windows or .NET. And that implementation is string-based.
If you want to avoid strings, you should avoid roles. To avoid roles you need to invent some other system. The CSLA 4 authz rules system allows you to invent other systems in a way that wasn't possible before CSLA 4.
Copyright (c) Marimer LLC