We are building an application using CSLA. One of the executives has very negative feelings about role-based security, insisting that it does not work well in practice. He wants each new user to have permission settings customized to them.
Our feeling is that this can be accomplished by setting up an individual custom role/permissions for each user rather than use generic roles. This should accomplish his goals while still maintaining the flexibility for customers that might prefer to use roles as they are generally implemented in order to reduce administration of permissions. I.e., customers that might prefer managing permissions on a handful of roles rather than on hundreds of users.
I am wondering if anyone has faced this scenario and what their solution/thoughts are on it.
Phil S:
I would argue role based security is an implementation detail. Which is why you are hired as the software expert, implementation is "your" responsibility.
The executive wants a secure application, and granular control of permissions. That is the "feature request". Your executive is stepping out of his/her area of expertise and probably job description.
You "could" design the app with role based security and just present per-user roles in the management UI....
Yes! Yes! Yes!
Never, ever, ever, discuss technical implementation details with a user. Never!
Discuss objectives, goals, risks, rewards, costs, and time required. Use those factors to determine the business parameters that define success. Focus the user on the results to be achieved, the results to be avoided, and the time, cost and quality parameters that govern your choice of technical solution. If you frame the discussion correctly, most users are extremely competent at giving you good business decisions on these matters.
Implementation details are your job and your competence.
While you are at it, never discuss technical implementation details with another developer if they are "someone who can say NO" unless they:
Why? Because many developers are not competent to discuss the matter and asking people to make decisions on a subject they are not competent to decide upon is stupid.
I use a mixture of roles and permissions in a large Web app. We assign permissions to roles and then check permissions everywhere in the app. The Identity class has a method named HasPermission(perm As String) which does the same sort of thing that IsInRole does.
From an administrative perspective you could have a Sales group and then apply permissions to that group. If they need a new permission then everyone gets it when it is applied to the group. If the Sales Mgr is the only that needs a new perm then he will have to be added to a new group and the perms from the original group will have to be added to his new group plus the new perm that only he can have.
Joe
I must admit to having concerns about dropping roles altogether and only allowing a permissions-based architecture. In a previous position I had responsibility for a project to build an application to facilitate SOX audit requirements for security permissions on every application and resource (servers, printers, workstations, remote access, etc.) within the company. This included perms, temps, contractors, consultants, part-time, and ex employees.
This was particularly complicated by an aging mainframe with a 60's-era OS that used a permissions-based approach for security. (Unlike virtually ALL modern applications, which use RBAC... of which I have not been able to identify a single exception, although I have tried.)
Needless to say, all normal work in the company came to a grinding halt during this process. And the initial results of the audit were an eye-opener.
So my goal is to satisfy the requirement without being backed into a corner should it be determined down the road that this requirement is just too much to manage. My sense as expressed above was that it could be done by treating roles in a degenerate way (i.e., 1 role/permissions/user) and it appears this is the case, although not pretty.
My real concern now is security in general for many of our clients, who will not be particularly computer savvy as a matter of industry culture. It strikes me that they may need handholding (or at least consulting) no matter WHAT we implement as they may potentially open security risks for themselves without even being aware of it.
This aspect, it seems, is more of a process and procedure issue rather than a technical one.
We recently started an app where the client wanted control over the permissions for users. Not sure how well this will work out, just thought I'd throw out what we're doing.
We have a long list of permissions that the user can't modify. We allow them to create/modify roles and assign permissions to those roles. Then they assign role(s) to users.
When a user logs in, we load the permissions for whatever roles the user has. In the code, we still use User.IsInRole(), but you think of it as User.HasPermission().
Actually this is possible (and to some degree better than ASP.NET Custom Roles and Authorization).
although I do not agree with what ajj3085 said, some real world scenarios defines roles and permission on a per group membership and per user role depending on the need and flexibility of a system.
User definitions would be more easier to maintain in the long run as opposed to a heirarchial inherited role based authorization where a granular access is not possible (ex. specific UI objects attached to roles and authorization, users attached to those roles instead of group of users attached those roles and inheriting from a base role would be more flexible).
Copyright (c) Marimer LLC