OpenMRS uses Role-Based Access Control (RBAC) where privileges & roles authorize access to service methods. You can restrict who can access a method, but you can’t control which data can be seen by someone with access to the method. Relationship-Based Access Control (ReBAC) provides access control to specific instances of data.
Watch @szrrizvi’s presentation about Relationship-Based Access Control for OpenMRS:
Have you guys consider also Spring Security? Spring Security provides lots of APIs and services to do authentication and authorization, it is also very extensible. So we could use ReBAC to implement to do a better integration between OpenMRS and Spring Security
Great point, @marioareias. Our initial RBAC was in place before Spring Security was so well established. It would be awesome if upgrading our RBAC could open the door for ReBAC. But I wouldn’t want to tie ReBAC to a conversion to Spring Security if it became a blocker. Worth investigating.
As I mentioned in the talk, I would be more than happy to assist in any way I can.
The version I created had core changes to the system, but it appears that most of the changes can be done through a module. So, it might make sense to create a module version of this. Possible leverage the diff in some way.
@burke I was thinking about the emergency case “break glass” situation. One possible solution would be to create special Actions that allows a user to generate all the required relationships to access the patient’s files. However, this would require something to prevent abuse of the feature (for example, a log report that is used to verify that each invocation was legitimate).
Exactly. Good idea! This ability to “break the glass” would be audited (could even send notifications to admins) and could be limited to people with the correct RBAC privilege to break glass.
Just wondering if there had been any progress on this topic? Last time we left off discussing “break the glass” scenarios and strategies. Also we were discussing that my implementation would need to be rewritten as a module, and this could be a Google Summer of Code project.
Unfortunately, no. While ReBAC would be a nice feature to have, there are many implementation questions yet to be answered and, more importantly, implementations are not currently asking for or prioritizing such a feature. As we discussed, this may be, in part, due to the idea of ReBAC is too abstract for implementations to appreciate. You could request a devtest machine by emailing helpdesk at openmrs.org to reserve a server, load a working demo onto it, and then we could either ask implementers to try it out or solicit some imlementers to do some use case testing with you.
Cheers,
-Burke
FYI – Summer of Code takes place annually (as long as Google keeps up the nearly 10-year pattern of hosting it). Project ideas and organization applications occur in the Jan-Feb timeframe, student applications occur in the Spring (March-April), and work occurs May - August.
Great work! I haven’t been able to attend the design call. But I went through the presentation and this is something that I was planning to do and feel lucky that I came across this post.
I have a request to make. Would you be interested in making this functionality a module soon? I would be literally glad to help you with that as this is useful to me. I guarantee that it wont be a lot of work and I can guide you through all the steps.
Secondly, I wouldn’t want to lessen your chances of doing this project/work as a Google Summer of Code project. But, converting this to a module will be a task but a minor initial task. For the whole May - August work period you need to come up with new features/improvements to the module and propose them in Jan-Feb period and if you need any help I would be glad to be of assistance.
I have serious doubts about how a module can intercept all the DAO methods of core to add the REBAC security constraints. It seems doable in the core itself though, but doesn’t seem easy.
As all of out DB access is through Hibernate, ideally Hibernate should provide hooks to apply the security. But if not a possible solution is to create wrappers around Hibernate objects (session, query, criteria …).
In my current project we use a naive approach of this kind of security (we call it instance security). Basically there is a table that holds all the authorizations about objects (stores its PK and the command allowed). Then there’s an API that returns a subquery (in HQL or SQL dialect) that must be manually add to the query. Only a few entities have this kind of security, so it’s not a lot of work. It’s a custom RBAC implementation, not general by any means.
@maurya Unfortunately with my current workload I am unable to create this project as a module. What I was thinking was that if this task becomes a Google Summer of Code project, I can help out as a consultant. If you would like to perform this yourself, I can help you out with conceptual issues.
If you do want to see this as a working model, I have uploaded the code for my project on Git.
I am new here in openMRS community. I have started studying about security mechanism access control of openMRS, which is RBAC. Current all the security policies are hard coded into the code. I am still working on getting start with the policies distributed in openMRS application. I came across this thread to find the conceptual details of security architecture of openMRS. Since openMRS cannot be deployed in countries where data protection laws are quite sophisticated like in Europe. My idea is to make openMRS policy flexible by introducing FLASK (Flux Advanced Security Kernal) which is used by SELinux. Once openMRS is policy flexible then it will bel easily injected with customized real world policies and will be quite easily deployable in countries where data security is important.
Can someone direct me to documentation or provide me with documentation on data access security to the patient record or other data in OpenMRS? A small project group are outlining a possible implementation project using OpenMRS in Tasmania. Several Qs have been about data security and access rights/privileges. Terry