Finer granularity with security permissions

[wjstarck]

I was thinking about the way security currently is implemented in OD last night as I was working on setting up security for the Anesthesia module I am working on.

Currently, it's "all or none", in that permissions are allowed or denied based on who is logged in at any given time. In the Anesthesia module anyways, there is a need to allow or deny certain *actions* on the form (eg., a non-admin should be able to fill out the majority of the form, but should not be allowed to say, delete medications that have already been administered).

I was thinking that it would be helpful if we could implement something that behaves like Linux administrative privileges work. So, in routine day to day operations, employees with non-Administrative security status would be logged in to the workstations. When a security-Admin level privilege is required for an action, OD would present a username/password dialog box in place of what shows currently. This allows the task to be completed, but then leaves the prior state of the form with the rights of the logged in user.

I would think this would be helpful in other areas of OD as well. I know in my practice I often walk up to a workstation and I want to do something simple (such as run a Query). Currently, I have to log out the current user, log myself in, etc. It's a bit tedious.

I've made a working model that I can commit to the repository if you'd like so you can see it in action. If you think it would be a useful addition, I don't think it will be that hard to make it functional...

[jordansparks]

But then you end up with just "admin" vs "non-admin". That's hardly granular. Permissions should be more like on Windows, where you assign whatever permissions you want to whatever groups you want. That would leave you the flexibility to set up "admin" vs "non-admin", and it would allow a different office to set up three levels, perhaps "admin", "management", and "regular user". So I absolutely do not like that part of your suggestion. On the other hand, automatic prompting if you attempt an action that requires different privileges does have some merit. It's not that it's tedious to login under a different user; that's only one extra mouse click. The tedious part is that you have to log back in under your regular user when you are done.

Let me suggest a few alternatives, though. Swipe cards and fingerprint readers. Both of those would reduce the tedious nature of logging in and out. They are both planned. And we could even move to a system where optional secure "passwords" replaced the username/password combos that we currently use.

To immediately address your complaint about permissions in the anesthesia module, you can simply use admin permissions for certain actions. Although we use the admin permission sparingly. You might instead use the setup permission, which is more widely used for such things. You also have the option of adding more granularity simply by adding more permission types. You have to put some though into it. If a user does not have permission for a button, you have a choice of hiding the button, disabling the button, or notifying the user once they click the button. When you check for permission, you have the option of doing it silently, or of notifying the user of failure. So there is plenty of flexibility there. If you really want to get fancy, I see no reason why you couldn't implement user switching within your own form just like you describe. Just "remember" the current user. Prompt for admin password. Then use the code in FormLogon.butOK_Click() to switch the user. When done, switch the user back. Should work just fine, and it won't mess up the rest of the program.

I would rather not touch our current security model. The next major improvement I would like to see is to let users set their own passwords. But that's not urgent.

[wjstarck]

But then you end up with just "admin" vs "non-admin".

Good point.

You might instead use the setup permission

Excellent suggestion - I hadn't thought of that. That's probably the route I will go. Thanks.