Hi Burke,
I was definitely expecting this response :) I am not suggesting that we
re-create a duplicate application-level privilege for Managing Concepts
necessarily. What I am suggesting is just an extension of what Dave and
Mark have already suggested - that our application should have a
different type of "privilege" that allows for showing / hiding or
enabling / disabling features, which is based on the granulariy of the
application and not based on the design of the API. And it should be
clear how to "customize" the features available by role using these
privileges without unintended side-effects.
The reality is that there is already an out-of-the-box mechanism for
bypassing privilege checking - it's called the "System Developer" role.
Many implementations use this role more than they should because they do
not trust, nor do they know how best to configure, what privileges they
need to use the application. Situations that Mark describes where one
part of the application bombs due to some privilege check that is
totally irrelevant or designed for a different purpose is not uncommon.
So many implementations just give out the System Developer privilege to
let their users get on with it and use the system, rather than
continually deal with this support issue.
Ultimately, what I am proposing is a solution that would make the System
Developer role more secure, by eliminating the automatic pass it gets on
the Application-level, while still supporting it on the API-level. So,
although I agree that this is not necessarily our strategic long-term
solution, I fail to see why it would be a bad idea, since it would make
the application more secure, not less secure, than it currently is, and
would provide infinitely more possibilities for implementations to
customize their UI experience for users in different roles.
Cheers,
Mike
On 05/18/2012 12:17 PM, Burke Mamlin wrote:
I agree that we need to improve privilege-handling, but I don't agree
that the best approach is to disable/bypass all API privilege checking.
Are you suggesting that re-create a duplicate application-level
privilege for Managing Concepts and bypass the existing privilege for
manage concepts? Should anyone using the application be able edit
users if they can find the right URL that lacks the application-level
privilege checking? I 100% agree with improving permission handling
to make things more manageable, but I don't agree with wholesale
bypassing of API privileges any more than I would propose solving a
Tomcat permissions problem by running it as root. API privilege
checking is there for a reason. And, while there are many cases where
application-level privileges are needed/justified, there are many
cases where separate application-level privileges would only be redundant.
Making the changes planned in the sprint, providing an easy mechanism
for granting all of the "Get" privileges (e.g., an out-of-the-box
role), creating some conventions for handling application-level
permissions, and having improved tools for troubleshooting privilege
problems should go a long way in improving the situation without
having to completely disable any API-level security.
-Burke
On Fri, May 18, 2012 at 11:52 AM, Mark Goodrich <mgoodr...@pih.org
<mailto:mgoodr...@pih.org>> wrote:
+1 for this. We also could provide a little bit of granularity by
also creating a role where every read-only API privilege check passes.
________________________________________
From: dev@openmrs.org <mailto:dev@openmrs.org> [dev@openmrs.org
<mailto:dev@openmrs.org>] On Behalf Of Michael Seaton
[msea...@pih.org <mailto:msea...@pih.org>]
Sent: Friday, May 18, 2012 11:27 AM
To: openmrs-deve...@listserv.iupui.edu
<mailto:openmrs-deve...@listserv.iupui.edu>
Subject: Re: [OPENMRS-DEV] Roles and Privileges
In this vein, here is a use-case I would like to suggest, based on
many of the great suggestions I've heard:
* Create 2 types of privileges - API-level and Application-level
* Provide a "System Developer"-like role in which every API-level
privilege check always passes, but which Application-level
privileges need to be set
* Re-factor our Web Application to refer only to Application-level
privileges
This would allow for implementations, if they chose, to
effectively turn off API-level privileges, but to still restrict
the types of activities that users could perform within the EMR
application. We can debate around the merits of turning off
API-level privileges, and whether or not they are necessary, but
this step would go a long way to have OpenMRS "get out of the way"
until better management of API-level privileges is supported.
I think the above could be done within a Sprint pretty easily, and
modules that currently do API-privilege checking would not be
impacted, but could migrate over to the Application-privilege
checking when appropriate
________________________________________
From: dev@openmrs.org <mailto:dev@openmrs.org> [dev@openmrs.org
<mailto:dev@openmrs.org>] On Behalf Of Mark Goodrich
[mgoodr...@pih.org <mailto:mgoodr...@pih.org>]
Sent: Friday, May 18, 2012 10:49 AM
To: openmrs-deve...@listserv.iupui.edu
<mailto:openmrs-deve...@listserv.iupui.edu>
Subject: [OPENMRS-DEV] Roles and Privileges
Yesterday I ran into a real-life roles and privileges problem very
similar to the example problem I gave a week or two ago. Sine
this the roles and privileges sprint is upcoming, I figured I'd
mention it here... I think we've already got these issues covered,
but wanted to reiterate since it is a good "real-life" example.
In the Provider Management module, the Provider Dashboard lists
all of the patients associated with a Provider. However, in the
functional specs for Provider Management, there is a requirement
to have a role for users who are able to manage providers but
aren't able to view patient data. For this role, the patients
associated with a provider should not be displayed, but, instead,
the dashboard should show the number of patients that a provider
has. But, in order for the Provider Management API to calculate
this information, this role would need to have the "View Patients"
privilege, or, at least, "View Relationships" privilege.
As was suggested earlier, one solution would be to give the user
the appropriate proxy privilege to do this calculation, but that
seems like a bad solution.
I'd actually be fine with giving this role access to the
getPatients and getRelationships API method, as long as there was
a way to do that without giving them access to patient information
via the web layer. It seems critical to me that API-level and
UI-level privileges be separated out. We have LOTS of privileges
in attempt to allow for fine-grained access control, but those
privileges are not always "grained" in a useful way.
Actually, from a web application level, I don't think that
API-level privileges are particularly useful, except last-resort
defense in the case that UI privileges aren't properly set up.
(However, I realize that they would be critical when using a web
services access model.) In fact, if I thought that the OpenMRS
web-level privileges were well enough defined, I'd almost consider
having an option/role that allows me to give a user all API-level
privileges when they access OpenMRS through the web app.
I just set up privileges for the Provider Management module
yesterday, and what I did was define a set of UI-level privileges
that I use to hide/display certain sections of the provider
dashboard. Then I created two separate, coarse-grained API
privilegs: "Provider Management API" and "Provider Management API
- Read-only" which I think should be sufficient for my use case.
It might be valuable to have a way to group privileges... say like
a "Patient Service API privilege group"? Of course you could do
this via a role, but a "Patient Service API" role doesn't seem to
be the way role was intended to be used.
And finally, a big +1 for creating a module that records privilege
checks to faciliate administration. Yesterday I had to use a
trial-and-error approach to figure out exactly what privileges
were required to access certain parts of the Provider Management
site so that i could define roles appropriately.
Take care,
Mark
________________________________
Click here to unsubscribe<mailto:lists...@listserv.iupui.edu
<mailto:lists...@listserv.iupui.edu>?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an
e-mail to lists...@listserv.iupui.edu
<mailto:lists...@listserv.iupui.edu> with "SIGNOFF
openmrs-devel-l" in the body (not the subject) of your e-mail.
[mailto:lists...@listserv.iupui.edu
<mailto:lists...@listserv.iupui.edu>?body=SIGNOFF%20openmrs-devel-l]
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an
e-mail to lists...@listserv.iupui.edu
<mailto:lists...@listserv.iupui.edu> with "SIGNOFF
openmrs-devel-l" in the body (not the subject) of your e-mail.
[mailto:lists...@listserv.iupui.edu
<mailto:lists...@listserv.iupui.edu>?body=SIGNOFF%20openmrs-devel-l]
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
-- OpenMRS Developers: http://go.openmrs.org/dev
Post: dev@openmrs.org
Unsubscribe: dev+unsubscr...@openmrs.org
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
