Share via

Roles, Privileges, and CRM Security

  • Article

 

One of the feature requests that we get on a regular basis, and a feature that a few enterprising ISVs have started to build, is the ability to have per-role UI. This also comes under the name “field-level security” – but only because hiding access to attributes in the UI is a possible, but insecure, solution to the problem. That is, one way to implement per-attribute security is to implement per-role UI. At the surface that makes a lot of sense, but there’s always something deeper than the surface that we need to worry about first.

Before we talk about why implementing per-role UI is only a surface-level solution, and an insecure one at that, it’ll help if we figure out what a role is in the context of MS-CRM. Believe it or not neither the platform nor the application really has any notion of a role. It’s a concept that was invented as a way to package privileges in a way that’s easy for administrators to manage. Current CRM builds have just over 320 distinct privileges. Managing these individually would be extremely difficult. So, the idea of a security role as a privilege container was created. As a side note, early V1 builds had 20 or more security roles, it wasn’t until the last minute that we trimmed that list down to a manageable 7.

So, what does this all mean? It means that the platform and application worry about what users can do by inspecting the set of privileges that the user has. If a service needs privilege X to continue, then that user better have a privilege X somewhere in one of the roles that are assigned to that user. Which raises another side issue: which direction is the assignment? Do we assign roles to users, or users to roles? If you’re a CRM administrator then it really doesn’t matter. You assign a role to a user. If you’re a CRM developer on the platform team working on V1 code, then you assign the user to a role.

“OK”, you ask, “what does this have to do with per-role UI?” Well, it has everything to do with it. The application loads the one form for the entity (ignoring the special forms like Quick Create and Print) but looking in the form cache. This is a very fast and very simple lookup (ignoring the organization- and language-specific stuff). We could add a second level to the map key, perhaps something like a role identifier. That wouldn’t be difficult to do. We look at the user and then grab the information about that user from the cache. Simple enough. Next we look at the cached user information. Hmm, there’s no role information in there (remember, I said that the application doesn’t really know about roles), so we’ll need to extend the cache to hold on to the users’ roles. It’s all just code and memory, so that one’s simple enough. But wait, isn’t it possible to assign a user to multiple roles? Sure it is.

That’s where the per-role UI falls apart. It’s entirely possible that a user has been assigned to multiple, overlapping roles. If each role has an associated UI, and those UI are different, then we don’t have a way to know which UI to load for the entity, because we don’t know which role governs the interaction.

One option is to introduce a new concept orthogonal to the security role. Well, it’s really not orthogonal because the management of security roles and these new “UI roles” would best be done in the same spot, by the same person, at the same time. If there were two places to manage this information, then we’d double the administrative work, and probably bury the support team. There are other things that we could do, like force a single UI role on a user. But what happens if you want a role that has the ability to set attributes on Create, but only read them for Update? Then you need two pieces of UI that are different. This just gets us mired into the per-process, per-user, per-document UI mess, which doesn’t seem to have an elegant solution… yet.

Comments

  • Anonymous
    February 03, 2005
    SAP Enterprise Portal uses a tabbed UI to provide per-role security. Within the context of a single tab the role security applies. If a specific screen is available within one role as read-only, it may be available in another role with change. This is not elegant either, but it does work
  • Anonymous
    February 03, 2005
    We had this very discussion in one of our API meetings yesterday. The first use case that was put on the table shot the whole idea down. Let's say I have a receptionist at a doctor or dentist office. This receptionist can see only the customer's name and maybe their phone number. So, we put those two things on the first tab, and all the rest of the interesting things on other tabs. That's fine for the receptionist because he or she only needs access to those two attributes. However, any other user with expanded rights needs to start clicking on tabs to find the information they're interested in. If you have lots of roles (receptionist, billing clerk, payables clerk, doctor, and so on) you really end up with lots of tabs, and as soon as visible attribute sets overlap everything falls apart.

    Like you said, it's not an elegant solution, and it does work. But, does it sound like something we'd want to put our customers through?
  • Anonymous
    February 03, 2005
    The comment has been removed
  • Anonymous
    February 04, 2005
    The concept would be useful for ISV config extensions, the ability to have a menu, toolbar or nav panel option available/not available would be useful, based on the users role.
  • Anonymous
    February 10, 2005
    There is obviously no clear cut answer on this. You could implement something where the rights per tab (dare I say also Sections???) included Read/Create/Update privilege. This could be interpreted in the XSLT to hide/display the tabs/sections as appropriate.

    Then, the other hitch (there's always a hitch when it comes to UI)...is to include some capabilty that makes the UI also tied to the Users department. Beyond just having visibility into fields, the question arises quickly about wanting an "optimized" form for a department. At a minimum, the ability to keep multiple "organizations" in the system with seperate forms would help.

    But, if security were to apply at the tab/section level, could we also then have the ability to have the same field present multiple times? This would provide an ability to "tailor" views to specific users.

    We still have the "multiple" access issue. If I have rights to all 5 versions of the general tab, which do I see? Or do you introduce the ability to have "versions" that are an implied hierarchy for the form. The "version" you get is the "highest" in the hierarchy that you have rights to.

    In any way shape or form, it translates to more admin on the security, but any type of field level security will have this.

    Any way, my $0.02.
  • Anonymous
    February 21, 2005
    A solution I have seen to this multi-role rights vs GUI issue in another CRM system, is to make the user select which (single) role to functions as in the application. The user can switch between different functions by selecting another role among the roles that the user has. Each role has a single associated GUI.

    Another way is to split the data/action rights from the GUI personalization ("UI roles"), and at run-time set fields to read-only and remove the actions in GUI that the user do not have data/action rights for. This provide a clear separation between privileges and personalization.
  • Anonymous
    February 15, 2006
    We have developed a complete solution for field level security for MSCRM 3.0.
    We are looking for MS CRM value added resellers to consult and market our add on under our partner program.
  • Anonymous
    March 14, 2006
    The comment has been removed