Tighter basic level security?

cfapress wrote on Tuesday, March 18, 2008:

I’m using PHPGACL for security in OpenEMR. It works nicely and I like the granularity.

Currently I’m doing an audit of what users can do at their various levels. I’m working from a recent check-out from the CVS code. So far I’ve discovered that if a person can log in but is not assigned to any ARO Group they can do the following:
- find a patient and view name, DOB, SSN, phone#, etc
- create a new patient
- add a patient transaction
- access files attached to a patient record
- run a full comprehensive report to view the patient’s data
- export a patient
- pop up an appointment list for anyone
- generate a letter with any provider’s name
- run an appointment report on anybody
- run an encounters report for anybody
- run a superbill report
- run an appointment-encounter report for anybody
- run a unique-seen-patients report
- run a patient list report
- run a prescription report
- add/edit the addressbook entries
- edit anybody’s appointments
- delete anybody’s appointments
- see patient notes

I’m sure there are a few other that have slipped through my fingers but here’s my point…

Shouldn’t a user be part of the ‘OpenEMR Users’ ARO Group at the very least?

I feel that a security check should be made for this basic level of security, if PHPGACL is being used. In my very specific case I have a collection of 160+ users but not all of them should be able to access all these features of OpenEMR. Yes, the simple answer is to prevent those people from logging in to begin with. But here’s the twist, in my case, I’m using Active Directory and adLDAP to authenticate my users. So anybody with a valid Active Directory account can log in to OpenEMR in our Agency.

Clearly I have some big security processes to sort out but the basic security level in OpenEMR needs to be scrutinized.

I’ll gladly step up and be the person to make the necessary code changes but I wanted to see what other OpenEMR users have to say.

Jason

sunsetsystems wrote on Tuesday, March 18, 2008:

This is definitely an unfinished area.  The ACL framework was put in but, as you see, is not comprehensively used.  It would be excellent if you’re willing to finish that.

Rod
www.sunsetsystems.com

cfapress wrote on Wednesday, March 19, 2008:

I have a strong vested interest in this software and I’ll spend some time working on tightening the security in a reasonable fashion. I’ll make all attempts not to break any existing security in place. However, I might discover there are security holes that need to be patched. After patching those holes some current users of OpenEMR may discover they cannot do what they used to.

I’ll try to write some good documentation to go along with the security. As time allows, of course.

Jason

bradymiller wrote on Friday, March 28, 2008:

hey,

With the cvs versions, we’ve made a couple changes in php gacl stuff. Discussion is here: http://sourceforge.net/forum/forum.php?thread_id=1844870&forum_id=202506

With the cvs version:
-you will be forced to place a user into an acl group if you create them in openemr
-also, if you go to the ACL admin section, it will highlight users that are not joined to any group
-all php-Gacl administration(changing users, creating/deleting ACL’s, editing ACL’s) can now be done in OpenEMR

In your case, you should be able to write a script which collects names from Active Directory and then checks the php-gacl database to ensure they are listed(if not, you could put them into a default group with very limited access).

I agree there’s a lot missing with the security(as you pointed out). We basically need a lot more new ACO’s created and placed to limit access.

If you do place any new ACO’s we need to ensure they get added to the following files to ensure we don’t lose track of any, and they works for new setups and upgrades(I have no problem adding these, just let me know):
acl_upgrade.php
acl_setup.php
library/acl.inc (just put in header comments for reference)

later,
Brady