Under Review

Additional layers of access control needed for tech-savvy users

Currently if a user has access to the SugarCRM application they may also have access to a number of other ways to enter, edit, or delete data other than the SugarCRM application. For example APIs and Excel Plugin.

Working in a tech-savvy company like the one I work for, opens up all sorts of opportunities for accidental operations by the most well-meaning of users through APIs and other plugins. That kind of external access should be controlled.

For example, I may have a user with full read/write access based on their role. That same user could enter data in a dropdown via API with a value that is not defined in the dropdown or with a value that is not the DB value but the user-visible label for that dropdown item, which in some cases is an illegal DB value.

Or one could update data circumventing front-end controllers such as conditionally required fields.

Using the Excel Plugin or the APIs correctly requires an intimate knowledge of Sugar and its modules and should not be available to everyone.

Furthermore, the Administrator of the Sugar application needs to know who is doing what from where, and all it takes is for a tech-savvy user to read the API documentation and they can build just about anything to interact with Sugar.

Yes, there are Business policies in place, but that's not enough. You can tell them not to, but isn't it better to prevent them from doing it in the first place?

Yes, I can restrict what they can do using Roles, but that's not enough either: I may want them to be able to import, update, and delete from the interface but I don't necessarily want them doing it from an API or Excel-Plugin.

I would think it would be important to be able to control which users can access Sugar ONLY via the Sugar application interface, and only authorize specific users for external tools such as MS Excel plugin or API, and even in those cases possibly have some granularity as to what they can do with that access. Maybe you can read data via API but not write it, even if you can write via the Application interface.

Does this worry anyone else?